Some teams upgrade the week a release ships and some wait for its third birthday. When to upgrade is a business decision with a technical test behind it, and RTM, the first CU and a later build each trade time against exposure to defects.
When to Upgrade Has No Magic Date
There is no release milestone that makes every workload safe. A first CU fixes issues found after RTM, but it cannot promise an absence of new issues. A later CU has more field experience and more fixes, while delaying the upgrade also delays features and support benefits. Pick based on your workload and risk.
People ask me when to upgrade, as if there were one right month. There is no such month. There is a set of tests your workload passes, or does not.
Start with the reason for moving. A new feature can solve a current problem. An old version can be approaching support deadlines. Hardware or Windows changes can force a schedule. A team that only says “newer is better” has not yet written an upgrade case.
Name the cost of waiting too. Remaining on an older release can leave security exposure, limited support, or a growing migration gap. The right decision balances those costs against the risk of changing a working application. You need evidence, not a slogan.
Understand What RTM Gives You
RTM is the initial released build. It is a supported starting point for a new SQL Server version. It also has less production history than a later serviced build. If a feature is urgent, RTM can be a rational choice after strong testing and a clear recovery plan.
Read known issues and supported upgrade paths. Check vendor certification for your applications and drivers. A SQL Server release can be available before a vendor approves its software on that release. If your business depends on that vendor’s support, the certification date matters more than the product launch date.
I prefer to test RTM in a lab even when production waits. That work finds deprecated features, driver problems, and changed plans early. The test investment is useful regardless of the final go live date.
What the First CU Changes
The first CU includes fixes released for the new major version after RTM. It can address early defects that matter to your workload. It also creates another build to validate. Do not assume CU1 is automatically a safer landing point for every application without reading its notes.
Map the exact build you plan to install. Test with that exact package. A test on RTM does not cover a CU, and a test on CU1 does not certify a later CU. Keep the package identity beside the change record so the production team does not substitute a newer download at the last moment.
If the CU fixes a bug you reproduced, run the same reproduction afterward. If it introduces a known issue in a feature you use, account for that before choosing the build. A release note can change the decision faster than a calendar rule.
The Case for Waiting Longer
A later CU gives the product more field use and includes previous CU fixes for that major release. Waiting can also give application vendors time to certify drivers and operations teams time to build runbooks. For a stable system with no urgent feature need, that breathing room has value.
Waiting has limits. An unsupported source version does not become safer because the target release is new. A delayed project can collide with hardware retirement or a contract deadline. Put a review date on the decision. Without one, “wait” becomes permanent postponement.
If you choose a later CU, test the whole upgrade path. Restoring a database onto the target, moving logins, adjusting compatibility, and validating jobs all matter. Waiting for the CU does not remove migration work. It just changes the target build.
Measure Your Own Risk Before Deciding When to Upgrade
Create an inventory of databases, compatibility levels, drivers, Agent jobs, linked servers, SSIS packages, and high availability components. Rank critical application paths. Identify features that changed or were deprecated. This list turns a vague fear of bugs into specific tests.
Almost every upgrade I have seen go badly skipped the same step. Nobody ran the heaviest real query on the new version before cutover.
Restore production data to a target test instance. Run representative workloads and compare measured results with the source. Capture query plans, errors, job outcomes, and application acceptance. Do not invent a universal percentage that makes a regression acceptable. The application owner must decide what matters.
Check recovery time and data loss requirements. An in place upgrade has a different fallback from a side by side migration. A side by side route can preserve the old system longer, but it requires a data cutover plan. Pick the method before setting the launch date.
SELECT
name,
compatibility_level,
state_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;Start with what you are moving. This lists every user database and the compatibility level it would carry across.
SELECT
name,
compatibility_level,
recovery_model_desc,
state_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;Decide When to Upgrade With a Gate, Not a Guess
Write a small decision gate. The target build is identified. Vendor support is confirmed. Backups and restore steps are tested. Critical application paths pass. Performance differences are understood. High availability and monitoring work. An owner signs off on known exceptions. If one condition fails, the date moves or the plan changes.
A gate also makes an early move possible. If the workload has been tested deeply and the business needs the feature, you can proceed with clear eyes. Waiting for an arbitrary CU number would add no evidence. The gate answers the real question: can your team operate this version safely?
Record the reason for your choice. Six months later, another DBA should understand why you chose RTM, CU1, or a later build. That history helps when an incident is blamed on the upgrade.
Plan the First Weeks After Cutover
Watch the workload after production moves. Review Query Store, failed jobs, error logs, backup status, and application reports. Compare results with the baseline collected before upgrade. A successful first login is only the beginning of validation.
Keep the source system or restore route available for the agreed recovery period. Define who can call a rollback and what data work it requires. After a major version moves database files forward, an old engine cannot simply attach those files again. A reverse migration needs a real plan.
I schedule a follow up review with the application team. Ask what broke, what improved, and what remains open. The upgrade is complete when the system is stable and supportable, not when setup reaches the final screen.
Related reading on this blog: What Breaks When You Upgrade, and How to Find It First and In-Place Upgrade or Side by Side: Choosing Properly.
The right upgrade date is not a release label, it is the day your evidence supports the move.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
