Microsoft has announced a pretty big change for how they are going to service SQL Server, starting with SQL Server 2017. I am very much in favor of the changes in this new model.
Background
Historically, Microsoft has used a combination of General Distribution Releases (GDRs), Cumulative Updates (CUs), and Service Packs (SPs) to update major SQL Server releases (which Microsoft refers to as servicing SQL Server). When a new major version of SQL Server reaches the general availability (GA) milestone, the servicing sequence for the original RTM branch begins. Typically, CUs are released every eight weeks, and they are a rollup of hotfixes and minor new features or feature improvements. GDRs only contain security hotfixes, and they are meant for organizations who want less software churn from SQL Server
Roughly a year after GA, Microsoft would release SP1 for that version of SQL Server. Organizations had the choice of staying on the RTM branch (which would continue to get CUs for about another year) or moving to the newer SP1 branch of the product (which would get its own CUs every eight weeks, and GDRs as needed). Roughly two years after GA, Microsoft would release SP2 for that version of SQL Server, which would start a new servicing branch with GDRs and CUs. The release of SP2 would halt the servicing of the RTM branch, which would then become an “unsupported SP”.
This has been the pattern since SQL Server 2005, so organizations should be pretty familiar with this old model.
Modern Servicing Model
The new servicing model will only use CUs and GDRs, there will be no more SPs. CUs will now have localized content (which was a big differentiator between CUs and SPs in the past). There will be a CU released every month for the first twelve months after GA, then changing to a new CU release every quarter for the next four years. New CUs will be delivered the week of the 3rd Tuesday of the month where they are released. About every twelve months, a slipstream-media CU will be released, which will let you install something like SQL Server 2017 with CU12 in one install instead of having to install SQL Server 2017 GA and then doing a separate install of SQL Server 2017 CU12.
Organizations will have to choose whether they will be on the “GDR Train” or the “CU Train”. If they are on the GDR Train and decide to install a CU, there is no going back to the GDR Train. Personally, I think it will be much better for most organizations to be on the CU Train, so that they get the benefit of hotfixes and feature improvements that will show up in CUs. Microsoft also advises organizations to proactively deploy CUs after they become available (after suitable internal testing).
You will need to be on a CU that is less than roughly 24 months old to be in a fully supported state from Microsoft (which is pretty similar to the current support window). Five years after GA, CU servicing will end as that version of SQL Server falls out of mainstream support, with only security fixes being available for the next five years, until that version of SQL Server falls out of extended support.
Premium Assurance
After that, you can extend support for six more years with SQL Server Premium Assurance. Premium Assurance is somewhat pricey, with a sliding price scale that increases depending on when you purchase it. For SQL Server Enterprise Edition, it would currently cost $394.00 per core license, going up to $675.00 per core license if you purchased it after July 2019. Premium Assurance is available for SQL Server 2008 and later.
In most cases, I would much rather have moved to a newer version of SQL Server long before I ever had to think about using Premium Assurance, but for those situations where you have a mission critical legacy application that requires an ancient version of SQL Server, it is nice to at least have the option for a longer support period.
Microsoft’s official announcement about this change is covered in even more depth here.
