Back in December of 2012, I wrote a fairly long article called Making the Case for a SQL Server Platform Refresh that made the argument that late 2012 was a good time to make a compelling case for a complete platform refresh, where you would get new server hardware and storage, with a new operating system, and a new version of SQL Server, all at the same time.
In January of 2015, I made a similar argument in this article, SQL Server Data Platform Upgrade in 2015, talking about the upcoming SQL Server 2016 and Windows Server 2016 (which were still called vNext at the time).
Now, in August of 2017, I think it is also a good time to be considering a complete platform refresh in late 2017 or early 2018, since we have new server processor families from both Intel and AMD (which require new model servers), we have the release of SQL Server 2017 coming pretty soon, and we also have a fairly major refresh of Windows Server 2016 (called Windows Server 2016 RS3) coming later this year. Once again the stars are aligned, and it just makes sense to start planning how to upgrade and consolidate your legacy database servers.
Upgrade in Place
There are several ways to actually conduct an upgrade and migration effort. One fully supported method from Microsoft is to do an “upgrade in place”, where you simply run the setup program for your new version of SQL Server, and it installs the new binaries for on top of your old version of SQL Server, and upgrades all of your databases to the new version.
Personally, this would not be my first choice for an upgrade and migration method, for a number of reasons. First, there is some risk that the upgrade in place operation will not succeed, or that your applications will have functionality or performance issues after an upgrade.
Second, you will have to take a fairly long outage during the installation process, that could have been avoided with other upgrade and migration methods. This is also a stressful upgrade method for you and your organization, since you are under time pressure to complete it, and you are not completely sure everything will work when you are done.
Finally, an upgrade in place means using your existing hardware and storage, with your existing operating system. This means you may be losing a lot of performance and scalability, and you may be paying much more in SQL Server license costs than necessary.
Complete Platform Upgrade
A much better alternative is to do a complete platform upgrade, using at least one new server (but hopefully as many as you need to upgrade and consolidate every legacy database server). With this method, you can take as long as necessary to prepare, patch, configure, and test the new server and storage, along with the new version of the operating system and new version of SQL Server, until you and your organization are completely confident about the new platform. Once you reach this point, you can then decide when to do the final production migration of your data, using a method (such as log shipping or database mirroring) that will let you take just a brief outage (probably less than a minute) to fail over to the new server.
Additional Resources
I have a new Pluralsight course, SQL Server: Upgrading and Migrating to SQL Server 2016 has just been published. This is my eleventh course for Pluralsight, but the complete list of my courses is here.
Building on this online course is a new three day class, IEUpgrade: Immersion Event on Upgrading SQL Server, taught by myself and Tim Radney. The first round of this course will be taught in Chicago from October 11-13, 2017.
Finally, I will be presenting a half-day session called Migrating to SQL Server 2017 at the PASS Summit 2017 in Seattle, WA from October 31- November 3, 2017.
Here is a link to the complete series about upgrading SQL Server.