Microsoft announced a new Modern Servicing Model for SQL Server a few months ago. That reminded me of a blog post of mine from several years ago, Not Before Service Pack 1, when I explained why the “not before the first service pack” policy is flawed and unnecessarily delays many organizations from taking advantage of powerful new SQL Server features. That post is even more relevant today considering there will be no more SQL Server service packs going forward, only Cumulative Updates (CUs) and General Distribution Releases (GDRs).

The rationale of postponing adoption until the first service pack stems from the days when testing was mostly manual, often incomplete, and at a time where speed to market sometimes trumped release quality. Unless you’ve been asleep for the last dozen years or so, you’ve probably noticed the technology world has changed, and is changing faster every day. A great deal of investment in automated unit testing has facilitated more rapid delivery of production quality software, not just by vendors like Microsoft, but by many organizations as well. We live in a different world today with much more thorough automated regression testing and it makes little sense to abide by rules based on rationale that isn’t relevant in today’s world.

The truth is that only you can ascertain production readiness of your application or vendor software. There is risk with any change but the decision to adopt and deploy a new version should be based on priorities specific to your application and organization, considering factors like cost, value in new features, vendor lifecycle alignment (including support), application mission criticality, risk of falling behind in security patches, and the level of testing you are able to perform. How Microsoft decides to label a release (RTM, CU or SP) shouldn’t be a consideration. If you’ve waited to install SQL Server 2014 until SP1 was released, I think Microsoft erred and should have just labeled CU1 as SP1 to get you onboard earlier.