Given Microsoft’s recent announcement of SQL Server 2017 general availability, you somehow get an idea of the frequency of releases for future SQL Server versions. This translates to more database upgrade and migration work that SQL Server DBAs have to do. However, keeping up with the latest and greatest version is not practical from a business standpoint. What might end up happening is that there would be more frequent installations of service packs and cumulative updates to keep a specific version of SQL Server in a supported configuration.

In my online course Windows Server Failover Clustering for the Smart SQL Server DBA, I walk thru the process of installing service packs on a multi-instance, multi-node SQL Server failover cluster. The process is basically the same if you want to perform an in-place upgrade. Majority of SQL Server DBAs are mostly focused on the actual upgrade process. And, why not? This is where the real action happens. But from my experience, the actual upgrade process is just but a small portion of the overall activity. In fact, what happens before the actual upgrade process determines whether or not the upgrade becomes successful.

Here’s another thing that I observed in my experience: service pack and cumulative update installations are treated like normal operations tasks. That’s a huge mistake, especially if you do not have a high availability solution in place. I remember the days of installing service packs on a SQL Server 2000 failover cluster. I think I spent more time “hoping and praying” for the entire installation process to succeed than doing the actual work. Otherwise, I’ll be stuck with rebuilding an entire cluster.

Whether you are installing a service pack or upgrading from a lower version to a higher version of SQL Server, this video will show you the real secret to successfully perform these tasks.