Release Management Checklist

Capture the RFC summary in ServiceNow / Jira Service Management / ConnectWise: what is changing, the business reason, and which application or infrastructure components are touched. Vague RFCs ("upgrade middleware") get bounced at CAB — name the version, the host, and the customer-visible behavior.

Pull the CMDB record and trace upstream / downstream dependencies — load balancers, scheduled jobs, integrations, monitoring agents. Common gotcha: a "single app" upgrade silently breaks the nightly batch job that pulls from its API.

Document the exact rollback procedure: snapshot revert commands, package downgrade syntax, config restore steps, and the named decision point at which the engineer aborts and rolls back. "We can roll back" is not a plan — the runbook is the plan.

Standard = pre-approved, repeatable, low-risk (e.g., routine WSUS patch ring). Normal = requires CAB review. Emergency = bypasses normal CAB cadence with expedited approval. Misclassifying a normal change as standard is the most common audit finding in SOX ITGC reviews.

Use the staging or pilot OU / VLAN / cluster that mirrors production topology. Test rings that diverge from prod (different OS build, different agents installed) provide false confidence — patch Tuesday horror stories almost always trace to a staging environment that wasn't really staging.

Hit the named user-facing checks: SSO login, primary report runs, scheduled job fires, monitoring agent reports in. The smoke-test list lives in the runbook — if it's not written down, it's not a test, it's vibes.

Confirm Veeam / Datto / Rubrik shows a successful job within the past 24 hours and that the restore point is mountable — "green dashboard" is not the same as "restorable." If the change touches a database, take a fresh backup before the window starts; do not rely on last night's job.

Walk the rollback runbook step by step on the staging system after the change is applied there. The first time you discover the rollback depends on a credential that rotated should not be at 2am on production.

Most CABs require RFCs in the queue 48-72 hours before the meeting. Late-submitted RFCs get deferred to the next cycle by default, which usually means slipping the deployment window by a week.

Walk the board through scope, blast radius, rollback plan, and test evidence. Be ready for the question "who owns the rollback decision during the window?" — name the engineer and their backup.

Notify via the standing channel — status page, Teams / Slack #announcements, email to affected DLs. Include start time, expected duration, services impacted, and where to file tickets if something is broken after the window closes.

Take VM-level snapshots in vCenter / Hyper-V / Proxmox immediately before the deployment runbook starts. Note: snapshots are not backups — they expire on day-counters and they balloon storage. Tag the snapshot with the change number and a 7-day expiry.

Follow the runbook exactly — do not improvise during the window. If a step fails or surfaces unexpected behavior, stop and call the change owner before continuing. Off-script execution is the most common cause of post-mortem findings.

Execute the same smoke-test list used on staging. Verify monitoring (PRTG, Datadog, LogicMonitor) shows agents reporting and no new alerts. Customer-facing endpoints should be checked from outside the corporate network.

Watch SIEM, EDR, and APM dashboards for 48-72 hours post-cutover. Track any new tickets tagged to the change in the PSA / ITSM queue. Spike in helpdesk volume on day 2 is often the first signal of a partial regression.

Walk through what went per plan, what deviated, and which runbook steps need correction. Capture action items with owners and due dates — a PIR with no follow-through is theater.

Push CI updates into ServiceNow / IT Glue / Hudu — version, host, dependencies, owner. Stale CMDB entries are how the next change owner trips on the same dependency you just discovered.