Checklists
Go-live readiness checklist for production releases
A go-live readiness checklist is the last gate between a build that looks ready and a release that survives contact with real users, real auditors, and real clients. The twelve items below are the minimum: anything thinner ships risk you have not named, and anything longer usually duplicates checks already enforced upstream by CI.
The twelve items
- Scope confirmed against the contract, ticket, or spec it was committed to.
- Excluded scope listed explicitly, with reason and target release.
- Acceptance criteria met for every included item, with evidence.
- Test results attached: unit, integration, regression, where applicable.
- Security review completed for any change touching auth, data export, or third-party calls.
- Migration plan reviewed, with backwards-compatibility window stated.
- Rollback rehearsed, not just documented. The person who would execute it has done so in staging.
- Observability in place: dashboards, alerts, and on-call ownership for the new surface.
- Customer communication drafted and approved if the change is user-visible.
- Known limitations documented with workarounds and accepted risks.
- Named decision authority identified and available during the deploy window.
- Sign-off captured with timestamp, attribution, and the conditions above attached.
How to use the checklist defensibly
The checklist itself has no value unless the answers are attributed and preserved. A green tick from "the team" carries less weight than a single named yes. Capture each answer with the person who gave it, store the completed checklist with the release record, and lock it once the release is finalised.
Stop relying on Slack threads as proof
Dockbase records each item, who confirmed it, and the conditions under which the release was accepted. Once finalised, the checklist becomes part of the immutable record.