The Story
SQL Server has a 10 year life cycle. Five years in main support and then an additional five years in extended support. Major releases are now announced every two years on average, often with an R2 name change. With Microsoft's cloud first strategy, releases and new features become available in Azure first and then later in the on premise versions. With these new releases comes the rush to gain access to those new features but it also creates a never ending cycle of upgrades/migrations.
This is of course the responsibility of the DBA (Database Administrator). Whilst there were five years between the release of SQL 2000 and SQL 2005 the next version, 2008 was only three years apart. Since then there has been a new version every two years with the release of 2008 R2, 2012, 2014, 2016, 2017 for Linux and the current major release of SQL 2019 which provides a push for Big Data.
The Problem:
Getting stuck on an old version leaves you at risk to potential security vulnerabilities. The longer you leave it the harder it can be to finally make that move to the current version.
Patching SQL can be stressful if you do not have an adequate roll back plan and the skills to implement it so it gets pushed back and back until there are so many updates to apply you fear doing it at all.
We recently completed a large scale Database Patching Project with over 40+ SQL Servers across multiple versions of Windows and SQL Server. These had over time become out of date (and out of compliance) in some cases with years of missing security patches.
SQL Server is a fantastic way for bad actors to gain access to your network. Security patches are a fundamental part to any security plan
The Solution:
One of the main responsibilities of a DBA is the installation and continuous patching of your SQL Server Data Platform.
This was completed over several months to ensure that roll back processes and test plans were in place for each application. Some work was completed out of hours but the vast majority was completed in working hours. Each system once patched was moved into a BAU process which would manage any future patching to ensure that all updates are applied in a timely manner. SCCM was configured to be used as the total number of servers in the estate was over 200. SCCM allowed these servers to be scheduled for patching and to check compliance for those patches.
If you do not have an in house DBA then you need to find a service provider that can do this for you. Having experienced DBA's with the skills to patch and troubleshoot any performance problems post patching can be the difference between a successful patching project or having to roll back the entire system and try again later.