SQL Server Migration and Upgrade Checklist (video and eBook)


What could go wrong?

It’s time to upgrade your SQL Server! But do you know exactly what you need to do? We’ve got a checklist and video to help make your migration go smoothly.

You’ll learn what you need to script and document from your current instance, which settings you should change after your migration, required tests for new installations, and better alternatives to in-place upgrades.

Whether your SQL Server instance is hitting end of life or you’re planning an upgrade to the latest and greatest, our migration checklist will save you time and frustration.

Download the SQL Server Migration Checklist as an eBook from our free First Responder Kit.

Previous Post
Announcing Brent’s SQLSaturday DC Pre-Con: Performance Tuning When You Can’t Fix the Queries
Next Post
Introducing Our 2016 Scholarship Program for SQL Server Training

7 Comments. Leave new

  • Just to say thanks for this excellent piece – attended the Webinar, found this very helpful :).

  • Some other “goodies” I ran into when moving systems to a new server.
    Get the values of sys.configuration and sys.servers from the original source and compare it to the target b9oth before and after the migration. We just had some folks who hard coded the server name in their procedures. Given that the OS Team decided to go this time with a copy from sqlXX to sqlXX-new, and renaming the source to sqlxx-old and the target to sqlxx, it had a few issues. While I was in favor of migrating from sql11 to sql99 and a gradual migration, this was not deemed acceptable so the above issues surfaced.
    Also the testing of a new server tends to have people testing things that they don’t normally do. So it may already have been broken previously and never noticed. So a test plan/scenario/script would be a good thing if you can get it.

  • Christian Solje
    June 23, 2017 6:14 am

    The link for the ebook is broken

  • Waqqas S Khokhar
    June 4, 2019 2:13 pm

    The one item I was hoping to get detailed was the implications of blindly including/excluding the System Databases (master, model, msdb, etc) in the migration and whether they had to be restored in a particular way or order on the new server. My main motivation is to preserve each database’s backup history (but I understand the other System Databases may contain stuff I would like to hang onto as well.)

    • Waqqas – I generally don’t recommend including those in a migration. If you want backup history, just restore msdb under a different database name (like msdb_old) and you can query it if, for some reason, someone offers you a million dollar prize if you know the exact date/time that SharePoint was backed up in 2018. 😉

      • Waqqas Khokhar
        June 6, 2019 6:39 am

        Thanks for the super-quick response (in contrast, I took two days off after my last post.) I realize that hanging on to backup details is not a very common requirement, but in our environment we retain backups for a lot longer than most places, and the thought of querying the entire backup history in one place (Reports –> Backup and Restore Events) feels pretty exciting. We also migrate and upgrade a lot more frequently than any sane data shop. Getting back to technical details: if I was to backup and restore just msdb onto the new server right off-the-bat, is there any harm?


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.