In-Place upgrades

  • The company I work for is insisting on in-place upgrades to 2019. I've made all the relevant arguments and it's just where I'm at. I started with the dev environment and immediately ran into an error that I couldn't get around. It seemed like I needed to attach the iso for the old install media as well. Upon further research, these machines have already been upgraded in-place from 2008->2012->2016.

    Is this even possible? If I take it back to the decision makers that this isn't possible, I'll have to be armed with proof. Perhaps a link to an article with definitive statements about it. So far, everything I've found in my research just says in-place is a bad idea. I know that, and have made that argument. I need to either do it anyway, or prove why I can't.

  • What is the exact error when you try upgrading to 2019, Error log items etc will be useful?.

    I have done in place for one time which is not bad idea for me- just we mentioned in plan Backup all DBs inducing system DB's, Upgrade , Roll back plan as uninstall SQL (in this case may be 2019) and reinstall older version up to date patch and restore DB's and return it.

    Durai Nagarajan

  • I haven't done it, so there's that.

    However, based on the documentation, yeah, it should be possible. That's not saying it is. But it really should be.

    I'd suggest a few more, extremely cautious, tests to validate. Maybe it isn't possible for your servers, in their situation. You just never know how lots of stuff stacked up like this interacts.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Please do keep in mind, if in case of major DRP, starting from scratch, you could end up with a partially working engine if you just install the latest version ( and CU ) of your latest engine due to potholes that may have existed in your original version of the engine you are using. ( SQL 2008 ? )

    So in theory, you should be able to rebuild your environment starting with your first engine and configuration, and work from there on upgrading until your current version and only then restore all system and user databases.


    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

  • It's possible, done it a few times after testing. (without replication / availability groups ...). Can't remember needing old installation media

    • Take sql server offline
    • backup server (VM) (full restore of VM in case upgrade fails)
    • start sql server for upgrading
    • upgrade
    • verify
    • backup again if everything is ok
  • If these are physical machines, and they started out as SQL 2008 boxes, then it's time to upgrade not just the software but also the hardware.  There's no way a physical machine purchased for SQL 2008 is still in support.

    If these are virtual machines, then I would like to hear the argument against spinning up a new instance.

    The potential failure points for an in-place upgrade are enormous. I would make sure that you can restore the entire server to it's previous state before I started any upgrade.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:

  • What is the current OS on the server(s) - and was that performed as an in-place upgrade also?  The minimum OS to support SQL Server 2019 is Windows Server 2016.  Since these servers have gone through several in-place upgrades I would be surprised if it actually worked now.

    If the reason for in-place upgrades is because they don't (can't) update the applications and everything else connecting, there are other methods that can be used to solve that problem.

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs

  • A man named Paul once wrote "All things are possible but not all things are desirable".

    An upgrade in place should work, but scores about 9.9 out of 10 on a risk scale. Repeated upgrades in place simply increase the risk of it going wrong. The main risk is you get a failed upgrade and your SQL instance no longer starts. Unless you can revert to your original server image you now have a dead server holding all your databases.

    As a technician all you can do is advise management of the risks and do what they decide what should be done. Your managers are responsible to their managers for what they decide so will have to justify taking a VERY risky decision if it all goes wrong. Also, make sure your CV is up to date, if the SQL upgrade does go belly up you will find working elsewhere less stressful than your current job.

    Original author: 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • Hi,

    It is possible to do in place upgrade. What is the error you are receiving in DEV environment. You need to run upgrade advisor to get which components are not upgradeable automatically like some SQL Agent Jobs, SSIS packages or AG environments, some tasks may need manual intervention is needed.

    Here are the general steps for upgrading from SQL Server 2016 to SQL Server 2019 using an in-place upgrade:

    Back up your data:

    Before starting the upgrade process, it is important to make a full backup of your SQL Server 2016 databases to ensure that you can recover from any potential issues during the upgrade process.

    Check hardware and software requirements:

    Ensure that your hardware meets the minimum requirements for SQL Server 2019 and that your operating system and other software components are compatible with the upgrade.

    Check compatibility:

    Use the SQL Server Upgrade Advisor tool to check for potential compatibility issues with your existing databases and applications, and address any issues before proceeding with the upgrade.

    Upgrade the operating system:

    If necessary, upgrade the operating system on the server to a version that is compatible with SQL Server 2019.

    Install SQL Server 2019:

    Install SQL Server 2019 on the server, either as a standalone instance or as part of a cluster. You will be prompted to provide your SQL Server 2016 product key during the installation process.

    Upgrade the databases:

    Upgrade the databases on the SQL Server 2016 instance to SQL Server 2019 using the in-place upgrade process. This will automatically upgrade the database schema and data to be compatible with SQL Server 2019.

    Verify the upgrade:

    Verify that the upgrade was successful by testing the databases and applications on the upgraded SQL Server 2019 instance.

    Update the applications: Update any applications that use the SQL Server databases to be compatible with SQL Server 2019, if necessary.

    It's important to note that the upgrade process can take some time, depending on the size of your databases and the complexity of your environment. You should also test the upgrade in a test environment before upgrading production systems to minimize any potential downtime or data loss.

    Good luck with the upgrade.


  • Emperor100 wrote:

    Hi, It is possible to do in place upgrade. What is the error you are receiving in DEV environment. You need to run upgrade advisor to get which components are not upgradeable automatically like some SQL Agent Jobs, SSIS packages or AG environments, some tasks may need manual intervention is needed.

    Anything is possible, but not advisable.  These servers have already gone through 3 upgrade cycles.  I would not do an upgrade under there circumstances for any production machine.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:

  • This was removed by the editor as SPAM

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply