MS SQL Server Cumulative Updates - Best Practices

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.

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.