I'm trying to get an idea of what recommended best practices are for the SQL Server Cumulative Updates.

Currently, we run on the idea of "do nothing unless an issue fixed by the CU is one we experience". That works from an "if it ain't broke, don't fix it" approach, but I'm wondering if that's really a good idea since so many of the CUs have performance enhancements. We're looking at perhaps adding the CU to the patches applied during our periodic maintenance cycles a month or two after the CU is released.

What do others do, and why?

As an update to the question that affects the answers below, on March 24, 2016, Microsoft's SQL Server team announced they were updating their servicing model. Microsoft is recommending that all users install all CUs released after January 2016:

As of January CU releases, these caution messages have been updated, we now recommend ongoing, proactive installation of CU’s as they become available. You should plan to install a CU with the same level of confidence you plan to install SPs (Service Packs) as they are released. This is because CU’s are certified and tested to the level of SP’s. Also, Microsoft CSS data indicates that a significant percentage of customer issues are often previously addressed in a released CU, but not applied proactively. More so, CU’s contain added value over and above hotfixes. These also may contain supportability, logging, and reliability updates enhancing the overall experience.

In addition to messaging and guidance updates, we have made updates to the CU acquisition model.

Acquisition changes:

  • CUs, of course, have traditionally been made available on the “Hotfix” server (accompanied by the “cautionary language” associated with a ‘QFE’ or ‘Hotfix’). The inconsistency here is that CUs are not really simple quick hotfixes anymore. The encompassed updates are well tested at individual as well as full system integration levels today.
  • Therefore, we are now placing the latest CU per mainstream supported baseline (2012 SP2/SP3 and 2014 RTM/SP1 today) on microsoft.com/downloads, just as is done for Service Packs today
  • Additionally, we will soon release, and maintain, all CUs into the Windows Update Catalog to facilitate acquisition and distribution
  • Only interim CU ‘On-Demand’ fixes will be placed on the hotfix server moving forward
  • To reduce friction, downloading CUs from the microsoft.com/downloads will not require providing/receiving an email and URL
  • We are also evaluating offering the latest CU as an Optional update on Microsoft Update, just like Service Packs today

2 Answers 2


I am a big advocate of keeping up to the date with the most recent cumulative update, but only if your testing/QA cycle can ensure full and proper regression testing against it. Glenn Berry of SQLskills is also a proponent of this approach.

Microsoft's own recommendation is to only apply CUs that fix issues that affect you, though they have loosened that stance recently. The problem is that you may be affected by one or more of those issues and not know it, or you might be affected tomorrow even if it hasn't hit you yet. Are you going to go through and try to reproduce the issue behind every single fix in every single CU for your branch? Are you going to do this continuously to make sure you still aren't affected?

I'll be quite honest: I've never had an issue applying any CU to my instances. And in fact their CU release process has been a lot more reliable than the service pack release cycle, and in many cases (including most recently with SQL Server 2012 Service Pack 2), you don't want to apply the service pack until the first CU for that branch has been released anyway. In this case there is an interim hotfix to resolve the issue that wasn't fixed in time to make the Service Pack code, but that isn't always true.

  • Thanks for the insight. Your opinion seems to mirror what I see elsewhere. We're a fairly small setup, so our QA cycle for most of our systems is essentially non-existant, but only a few of our systems are operations critical and those systems do have a QA process. We don't have the people to do it more rigorously, unfortunately, as we're a public entity with limited funding. We have large maintenance windows essentially daily, however, which does help a lot. It is very difficult to keep up on what issues the CU might resolve. The 2012 SP2 issue is actually what sparked the discussion.
    – Bacon Bits
    Jun 30, 2014 at 16:41
  • FYI, The link in "Glenn Berry of SQLskills is" is broken. Try this one instead (with the https protocol) sqlskills.com HTH
    – jrdevdba
    Sep 12, 2019 at 19:16
  • 1
    @jrdevdba Thanks, fixed. It's odd that http://www redirects fine, but not without the www. Sep 12, 2019 at 19:51

We used to keep up with the CU's. Approximately 1 month after release we would apply them whether we were experiencing an issue corrected by them or not.

However, after we ran into a huge problem we stopped this practice. In our case a service pack we had installed fixed a problem with full-text indexing that we were experiencing. A few months later, one of the CUs rolled back that particular fix. This caused all sorts of issues for us that took quite a bit of research to figure out what happened. We ended up coding a work around which was then later screwed up when a new CU broke something else... Net result: server re installed from the ground up to a particular SP/CU level and frozen.

Our application performance is such that we're not concerned with any new SQL performance enhancements that might come out, so that's a non-issue. Also, the reporting and other queries are consistently pulling back valid results so any new tweaks are unnecessary. Which means that it has to be a security issue before we consider applying a CU at this time.

I completely agree with Aaron: only do this if your testing/QA cycle can properly test it Otherwise I'd say steer clear unless it corrects a problem that you are actually faced with. And even then, test every little facet of it with real data to make sure they didn't break something that you may be depending on.

  • Your experience is exactly what I'm afraid of. Thanks for sharing!
    – Bacon Bits
    Jun 30, 2014 at 17:04
  • 2
    Do you have any specific details about which version, which service pack, which CU? I've been following CU releases extremely closely (and with a lot of info direct from MS) and I don't recall any issues like this, but I would like to know more about them if they do exist. I can assure you that since SQL Server 2008 the CU process goes through much more rigorous testing than the disclaimers on the KB articles would imply. Jun 30, 2014 at 17:38
  • 1
    @AaronBertrand with Azure and even more frequent releases that noone can opt out of I'm sure the process is even more tight.
    – usr
    Jun 30, 2014 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.