Software Release Management Checklist Template

What the Software Release Management Checklist Covers

1. 1
   Phase 1

   Phase 1: Release Scope & Plan

   6 tasks

   Fill in the first task before anything else. The planned release date sets every due date in the checklist, and the approver named there makes the go/no-go decision.

   • Record the product, version, release type and planned release date — use the next version number in your scheme and name the release manager, QA lead and go/no-go approver
   • Agree the release scope with product and engineering — the tickets, epics and fixes that make up the version, tracked under one fix version in your issue tracker
   • Publish the release calendar — scope freeze, code freeze and branch cut, first release candidate, regression window, go/no-go and release date
   • Flag high-risk changes early — database migrations, API or integration changes, infrastructure changes and anything that cannot be rolled back
   • Agree the release criteria before testing starts — the exit criteria the go/no-go will check, such as no open S1 or S2 defects, regression passed, performance within budget and security scans clear
   • Freeze the scope — from here, new work goes to the next version; a late addition needs the release manager's approval and a reason
2. 2
   Phase 2

   Phase 2: Code Freeze & Release Candidate

   8 tasks

   After the code freeze, the release branch takes only fixes for defects in this release, and every change reaches testing through a new release candidate.

   • Announce the code freeze and its rules — the date, the time zone and what may still merge: fixes for this release's defects, each approved by the release manager
   • Cut the release branch from main — for example release/4.2, and record the commit it was cut from
   • Move unfinished work out of the release or behind a feature flag, off by default — nothing half-built ships switched on
   • Set the version number in the build and start the changelog — release candidates carry a pre-release label, such as 4.2.0-rc.1
   • Build the release candidate in CI from the release branch — the same artefact goes to staging and, if approved, to production; never rebuild it
   • Confirm automated tests, static analysis and dependency scans pass on the candidate — for this build, not an earlier one with the same version number
   • Deploy the candidate to staging and rehearse the migrations — on a production-sized copy of the data, recording how long each migration takes
   • Log every fix and new candidate after the freeze — each fix merged to main as well as the release branch, so the next version does not bring the defect back
3. 3
   Phase 3

   Phase 3: Regression Testing & Sign-Offs

   6 tasks

   Test the numbered candidate you intend to ship. When a fix produces a new candidate, re-run the tests its change could affect.

   • Run the full regression suite against the release candidate — the automated suite plus the manual key user journeys
   • Test upgrades from the previous version — data, settings, API clients and any older app versions customers still use
   • Run performance and load tests against the agreed budget — response times and resource use compared with the last release
   • Triage every defect found in the release — S1 and S2 block the release; lower severities are scheduled and listed as known issues
   • Retest each fix on the new candidate — confirm the fix and check that nothing near it has broken
   • Collect sign-offs from QA, product and security — each recorded with the name, the candidate and the date
4. 4
   Phase 4

   Phase 4: Release Notes & Customer Comms

   6 tasks

   The breaking changes task appears only when the first phase records breaking changes or deprecations.

   • Draft the release notes from the tickets in the release — new features, improvements, fixes, known issues and any action users must take
   • Document breaking changes and deprecations — with migration steps and dates, so customers can prepare before the release
   • Review the notes with product, support and documentation — check every change is described the way a customer will see it
   • Brief support and customer success — what changed, the known issues and answers to likely questions, before customers ask
   • Update help articles, API docs and screenshots — ready to publish when the release goes live
   • Schedule customer communications — release email, in-app message and a status page notice for any maintenance window
5. 5
   Phase 5

   Phase 5: Go/No-Go

   5 tasks

   The approver named on the first task records the decision on the last task. The checklist halts there, and nothing after it can be completed until they decide.

   • Check each release criterion against the evidence — Met or Not met, with a link to the result
   • List the known issues and accepted risks — each with an owner and the version that will fix it
   • Confirm the deployment plan and its rollback plan — run in the Production Deployment & Rollback Checklist, started for this candidate with its own deployer and approver
   • Confirm support and on-call cover for release day and the days after — who answers customers and who can build and ship a fix
   • Record the go/no-go decision — Approved, Approved with conditions or Not approved, with the reason
6. 6
   Phase 6

   Phase 6: Deploy & Monitor

   6 tasks

   Deploy-day steps, the deploy strategy and the rollback decision live in the Production Deployment & Rollback Checklist. This phase records the release around the deploy.

   • Deploy the approved candidate through the deployment checklist — the same artefact that passed regression, in the agreed window
   • Tag the release in source control — for example v4.2.0, on the exact commit the candidate was built from
   • Publish the release notes and changelog — with the version number and the release date
   • Send the customer communications — the release email, in-app message and any status page update you scheduled
   • Monitor errors, performance and support tickets for the agreed period — compared with the baseline before the release
   • Triage defects reported after the release — decide for each whether it needs a hotfix or can wait for the next version
7. 7
   Phase 7 — If Needed

   Phase 7: Hotfix Release

   6 tasks

   Shown only when a defect found after the release needs a hotfix. A hotfix is a patch version, such as 4.2.1, built from the release tag rather than from main.

   • Confirm the defect justifies a release outside the plan — severity, customers affected and whether a feature flag or workaround would contain it
   • Branch the fix from the release tag — so the hotfix contains the fix and nothing else that has merged to main since
   • Test the fix and the areas around it — plus a smoke test of the critical journeys; a shortened run, not none
   • Approve the hotfix — the approver named on the first task records the decision before it is deployed
   • Deploy the hotfix through the deployment checklist — and publish a short note for the patch version
   • Merge the fix back into main and any open release branch — or the next version ships the defect again
8. 8
   Phase 8

   Phase 8: Retrospective & Close

   4 tasks

   • Close the version in your issue tracker — mark it released, close its tickets and move anything unreleased to the next version
   • Hold the release retrospective — what slipped, which defects escaped testing and what to change next time
   • Record the release metrics — planned and actual release dates, scope changes after the freeze, defects found after release and hotfixes needed
   • Turn retrospective actions into tickets with owners — and update this template if a step was missing or in the wrong place