Software Update Checklist
Standard change-management workflow for applying a vendor software update to a production system, from pre-update assessment through CAB approval, execution, and post-update sign-off. Run by the platform engineer who owns the system, with sign-off from the change advisory board.
Pre-Update Assessment
-
Pull release notes and CVE references
Capture the vendor's release notes, the target version, and any CVE / KEV references that motivated the update. Note breaking-change items separately — config-format changes, deprecated APIs, and required schema migrations are the items that derail mid-window.
-
Map dependent services and integrations
Pull the service's CMDB record. List upstream callers, downstream dependencies, scheduled jobs, and SaaS integrations that authenticate against this system. The blast radius drives the maintenance-window length and stakeholder list.
-
Run the update in staging end-to-end
Apply the update against a staging environment that mirrors prod. Run the smoke test suite and the regression suite. A staging cycle that skips integration tests against external APIs is a common reason updates fail in production.
-
Document the maintenance window blast radius
Quantify expected downtime, affected user populations, and any read-only or degraded-mode behavior. This becomes the body of the CAB submission and the customer-facing notification.
Change Approval & Scheduling
-
Submit the RFC to the change advisory board
File the RFC in the PSA / change tool (ServiceNow, Jira Service Management, ConnectWise) with the staging test results, blast-radius assessment, rollback plan, and proposed window. Standard changes may auto-approve; normal and emergency changes go to CAB review.
Collects list -
Address CAB feedback and resubmit
Document the rejection reasons, address each one (additional testing, expanded rollback plan, revised window), and resubmit. Do not proceed to scheduling until CAB approval is recorded in the change ticket.
-
Notify stakeholders of the maintenance window
Send the maintenance notification to internal users, affected customers, and any vendors that hold integration health monitors. Include start time, expected duration, and a status-page link.
-
Confirm on-call coverage and escalation paths
Verify the on-call rotation in PagerDuty / Opsgenie covers the window. Identify the incident commander, the executor, and the comms lead. A solo update with no backup pager is the recipe for a 3 AM regret.
Backup & Rollback Preparation
-
Snapshot the system and verify backup integrity
Take an immutable snapshot via Veeam, Datto, AWS Backup, or the platform's native tooling. Confirm the snapshot completes and a test-restore mounts cleanly — an unverified backup is not a backup.
Collects file -
Document the rollback procedure
Write the rollback steps as a runbook attached to the change ticket — exact commands, expected output, decision criteria for invoking. The rollback runbook is read under stress; ambiguity is the enemy.
-
Stage the prior version artifact for fast rollback
Pre-position the prior installer / container image / Terraform module on the target host or in the registry. Pulling artifacts during a rollback adds minutes of downtime and assumes the network path is healthy.
Update Execution
-
Enter the maintenance window and freeze deploys
Flip the status page to maintenance, post in the change-management Slack channel, and apply the deploy-freeze tag in CI/CD. A concurrent unrelated deploy mid-window is a classic incident-multiplier.
-
Apply the update per vendor procedure
Execute the upgrade commands or pipeline. Tee output to a session log for the postmortem. Do not skip vendor-prescribed pre-checks even when staging passed cleanly — production data shapes surface bugs staging misses.
-
Run the smoke test suite
Run the documented smoke tests: auth flow, primary read path, primary write path, integration heartbeats, scheduled-job triggers. Capture pass/fail with timestamps in the change ticket.
Collects list -
Execute rollback to the prior version
Invoke the rollback runbook and the staged prior-version artifact. Page the incident commander, open an incident channel, and begin the comms cycle. Schedule a blameless postmortem within five business days.
Post-Update Verification & Closeout
-
Monitor error rates and SLOs for 24 hours
Watch the Datadog / Grafana / New Relic dashboards for error-rate spikes, latency regressions, and SLO burn. Subtle regressions often show up after the first full traffic cycle, not during the smoke test.
-
Sign off on the post-update review
Service owner reviews the 24-hour observability data, the smoke test artifacts, and any user-reported tickets. Capture the verdict, any caveats, and dashboard screenshots for the change ticket and the SOC 2 / ISO evidence trail.
Collects list Collects paragraph Collects file -
Update the CMDB, runbooks, and IT Glue entries
Update the version field in the CMDB, refresh runbook screenshots that show old UI, and revise any documented commands whose syntax changed. Stale runbooks during the next incident waste minutes nobody has.
-
Close the change ticket and notify stakeholders
Mark the RFC closed-successful (or closed-with-issues) in the PSA, send the completion notice to the original stakeholder list, and flip the status page back to operational.
Use this template
Copy it to your account, customize the steps, and run it with your team in minutes.
Browse hundreds of free templates across every team and industry.
Back to template libraryRun Software Update Checklist with your team
Customize the steps, assign roles, set a schedule, and keep a complete record for every run.