An Upgrade Checklist That Fits on One Page

A long upgrade guide is useful until the outage clock starts. An upgrade checklist should fit on one page so the team can see the next action and its owner. The detail belongs in linked runbooks, while this page carries the gates.

Put the Upgrade Checklist Gates on One Page

The compact upgrade checklist below is the working page. Give each line an owner, expected evidence, and a check box in your operational copy. Keep commands, screen captures, and long explanations in separate runbooks. One page should tell the team what must happen next and whether the move can continue. Keep the contact list, server names, and change identifier in a small header. Place the rollback trigger beside the action it controls. A reviewer should see the last verified state without reading a separate chat history. It should not require scrolling through a history lesson during an outage.

I use the page in rehearsal before I use it in production. Which line cannot be verified with the access available in the window? Fix that before scheduling the real change. A one-page checklist is a control surface, not a substitute for a technical plan. It has no patience for a missing owner.

Before: Prove Recovery

Take and verify the backups required by the upgrade method. Run integrity checks under the normal policy, confirm free space, and rehearse restore on a suitable target. Record source version, edition, compatibility levels, and database states. Decide where the rollback point sits and what new writes would mean after it. The restore test is the proof behind the backup check box.

I ask who has the files and who can restore them. Those answers can differ. A successful backup job is not enough if the target host cannot read the file or the operator lacks permission. Keep the exact restore path and file names in the detailed runbook.

Before: Inventory the Application Edges

List logins, Agent jobs, linked servers, credentials, certificates, Database Mail, client drivers, connection strings, and DNS or listener changes. Test each dependency in a rehearsal. Mark owners for applications and reports that will validate after the upgrade. Stop jobs that could write during the window and document when they resume.

The query below lists user database compatibility levels and states. Run it on the exact instance being upgraded and save the output with the change record. I compare it after the move so a silent setting change cannot hide behind a successful login.

SELECT
    name,
    compatibility_level,
    state_desc,
    recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

During: Follow the Upgrade Checklist in Rehearsed Order

Announce the write freeze, confirm clients have stopped, then perform the backup, restore, failover, or installer steps in the tested order. Record start and finish times, file names, warnings, and decisions. Do not add an untested cleanup command because the window looks quiet. Pause when evidence differs from rehearsal and let the go or no-go owner decide.

I keep a separate operator reading the checklist while the DBA runs commands. That small separation catches skipped steps. The person pressing Enter is not the best person to notice that the next line was a validation gate.

During: Confirm the Destination

After the engine or database is online, test the intended endpoint from an application host with the intended service identity. Confirm the connected instance, database, login, and product version. Check critical read and write paths before opening broad traffic. A green SQL Server service indicator is only one layer of the result.

The query below is a quick destination check. It is not a full application test, but it catches a connection that still points to the old server. I put its output next to the cutover time. That makes later log review much easier.

SELECT
    @@SERVERNAME AS ConnectedInstance,
    DB_NAME() AS CurrentDatabase,
    ORIGINAL_LOGIN() AS LoginName,
    SERVERPROPERTY('ProductVersion') AS ProductVersion;

After: Validate the Business Cycle

Run prepared checks for critical data, reports, background jobs, and external integrations. Compare results with the source cutoff or baseline. Watch errors, waits, storage, and query performance through the next normal workload cycle. Keep the change open until the overnight or weekly path that matters has run. A morning smoke test cannot validate a midnight billing job.

I ask the business owner to perform one real task under the new setup. The test should use ordinary permissions and a normal client. If a discrepancy appears, record whether it is a data gap, permission error, query regression, or client setting. Different causes need different fixes.

After: Restore Routine Operations

Enable the intended backup schedule, monitoring, Agent jobs, and alerts on the new instance. Confirm off-host backup copies and run a restore check from the new source. Update inventory and support documentation. Keep the old source or restore point under the approved rollback period and prevent accidental writes to it.

I check that job schedules and owners survived the move. A job can be present but disabled, or enabled with an invalid owner. The checklist should require evidence of a successful scheduled run, not just a count of job names. The next operator needs a system they can recover and monitor.

Review the Upgrade Checklist After the Change

Mark every line complete, skipped with reason, or unresolved. Store the page with logs and validation evidence. Add any step that the rehearsal or live run proved necessary, then remove details that made the page hard to scan. Preserve the one-page shape by moving deep instructions to the runbook.

An upgrade can be technically correct and operationally confusing if nobody knows what was checked. I want the next DBA to read the page and understand the decision. That is the standard for a useful checklist, not how many boxes it contains. Reconcile the checked page with the actual logs before calling the change complete. Record the checks that could not run and assign their follow-up owner. A blank box should never be mistaken for a pass.

Related reading on this blog: SQL SERVER 2022: Oldest Compatibility Level Supported and Full, Differential and Log Backups: A Practical Guide.

An upgrade checklist is not a miniature manual, it is a visible sequence of decisions backed by evidence.

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