How to Patch SQL Server Without a Bad Morning

Before you patch SQL Server, write the recovery plan and rehearse the maintenance sequence. Back up what you need and check each instance before moving to the next one.

Define the Change and the Exit

Write down the source build, target package, instances, and applications affected. Distinguish a CU from a major-version upgrade. Their recovery boundaries aren’t identical. Read the target package’s prerequisites and known issues before deciding that the change is routine.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('ProductUpdateLevel') AS update_level;

Set a point at which you stop and recover rather than continue improvising. Include who can approve that decision and which application checks must pass. A maintenance window without an exit condition can turn into an open-ended experiment.

Don’t quote a generic installation duration as your outage estimate. Rehearse on representative systems and measure the steps. Include service startup, recovery, failover, and application checks. The installer is only part of the elapsed window.

Back Up More Than Tables

Take the required database and system backups, then confirm your restore evidence is current. Preserve encryption certificates and keys where relevant. Script server configuration, logins, and scheduled work needed for rebuilding. Store the recovery material where you can access it if the instance is unavailable.

SELECT
    database_name, type,
    MAX(backup_finish_date) AS last_recorded_backup
FROM msdb.dbo.backupset
GROUP BY database_name, type
ORDER BY database_name, type;

History alone doesn’t prove that the files exist or that a restore succeeds. Check the files and a tested restore path separately. For availability groups, backup history can be distributed across replicas. Collect the evidence from the place where the backups actually ran.

Keep a record of service accounts, paths, startup parameters, and dependent components. User database backups alone can leave the recovered engine without the connections and jobs the application needs.

Sequence Availability Group Replicas

For a supported rolling AG update, work through secondary replicas before the current primary. Check replica health and the documented sequence for your topology. Don’t assume every secondary is a safe failover target. Synchronization mode and state determine whether a planned no-data-loss failover is available.

SELECT
    ar.replica_server_name,
    ars.role_desc, ars.connected_state_desc,
    ars.synchronization_health_desc
FROM sys.availability_replicas AS ar
JOIN sys.dm_hadr_availability_replica_states AS ars
    ON ars.replica_id = ar.replica_id;

This is an initial health view, not a complete failover authorization. Check database synchronization and application readiness too. Perform a planned failover only after the intended target meets the requirements. Then update the former primary and verify the group again.

A major-version rolling upgrade can create a one-way boundary after failover to the newer engine. A same-version CU has different conditions. Use Microsoft’s guidance for the exact operation rather than blending those procedures into one remembered sequence.

Treat a Failover Cluster Instance Separately

A failover cluster instance shares an instance through cluster resources. An availability group replicates databases between instances. Those designs require different patch planning. For a supported FCI rolling update, update passive nodes first according to the documented procedure, then move ownership as planned.

Check cluster health, possible owners, shared storage, and the package’s node requirements. Confirm which node currently owns the SQL Server role before each step. Don’t patch every node simultaneously and assume the word cluster guarantees continued service.

If the environment combines FCIs and availability groups, document both layers. The sequence must preserve the supported state of each. This is a good place for a rehearsal and a reviewed runbook rather than a clever one-line command.

Verify Before Reopening the Workload

SELECT
    SERVERPROPERTY('ProductVersion') AS version_after,
    SERVERPROPERTY('ProductUpdateLevel') AS update_after;

SELECT name, state_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE';

Read Setup logs and the SQL Server error log as well as the build query. Check application authentication and representative transactions. Confirm jobs, backups, and monitoring are running where expected after failover. A quiet dashboard can mean the collector stopped.

Compare performance using similar work rather than a newly idle server. Watch for query regressions through Query Store when available. Preserve the before evidence. Don’t clear the cache or rebuild every index merely to make the post-patch period look different.

Know Which Rollback You Have

Some CUs support uninstalling under documented conditions. That isn’t a guarantee that every failed patch can be reversed cleanly. A major-version database upgrade cannot be undone by restoring its newer backup on an older engine. Keep these recovery cases separate.

Plan the fallback around tested backups, rebuild steps, and the handling of writes after service resumes. Record the final build on every node and replica. Close the change only after the agreed checks pass, including the checks performed by the application owner.

A patch window is not an installer appointment, it is a controlled change with a tested way to recover.

This post was rewritten from scratch in September 2026. The original, published on 2009-07-25, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.