Go-Live Checklist: What to Confirm Before You Release

A practical go-live checklist covering readiness, go/no-go criteria, rollback triggers, comms and hypercare — with the checks teams skip under deadline pressure.

A go-live checklist is the set of readiness conditions confirmed before a release is allowed to proceed, covering technical, data, business, operational and governance readiness. It is written weeks before the decision, when the team is calm, precisely so it can be applied when they are not.

A go-live checklist exists for one reason: on the day of the decision, nobody is thinking clearly. The list is written weeks earlier, when the team is calm, precisely so it can be applied when they are not.

It is not the same as the cutover plan. The cutover plan describes what happens during the window. The checklist decides whether the window opens at all.

Readiness, grouped

Technical readiness

• All planned releases built, tested and signed off
• Known defects triaged; no open severity-1 or severity-2 defects, or documented acceptance of any that remain
• Performance and load testing complete against production-like volumes
• Environments confirmed: target configuration matches what was tested
• Backups taken and, more importantly, restore verified — an untested backup is a belief, not a control
• Rollback procedure documented and rehearsed

Data readiness

• Migration dry run completed at full volume
• Reconciliation criteria agreed in advance, with a defined tolerance
• Data owner sign-off obtained

Business readiness

• End users trained, with a record of who has and has not attended
• Support and service desk briefed, with scripts for the likely first-week questions
• Business processes updated, including the manual workarounds for anything not ready
• Key business users available during the window and the days after

Operational readiness

• Monitoring and alerting in place for the new components
• Support model agreed: who is on call, for how long, and at what response time
• Third parties and vendors notified and available
• Change request approved through the change board

Governance

• Go/no-go criteria written down and agreed before the meeting
• Decision makers named, with deputies
• Change freeze scheduled
• Communications drafted, including the failure message

Getting go/no-go right

The most common failure is holding a go/no-go meeting without agreed criteria. What happens then is a discussion of sentiment, and sentiment in a room containing the sponsor who wants the date has a predictable outcome.

Write the criteria a fortnight ahead. Each one should be answerable yes or no by someone other than the person who wants to go live. Agree in advance which criteria are absolute and which can be waived, and who has authority to waive them.

Record the decision, the criteria status at the time, and who made the call. This is not bureaucracy — it is what makes an honest post-incident review possible.

The checks that get skipped

Restore, not backup. Everyone takes the backup. Far fewer confirm it restores.

Service desk readiness. The system goes live and the first fifty calls arrive at a desk that has not seen the new screens.

The rollback rehearsal. Documented rollback is not tested rollback. If you have never run it, you do not know how long it takes, and duration is exactly what you need to know at the point of no return.

Availability of the people, not just the systems. Check the calendar. A go-live over a holiday weekend when the database specialist is unreachable is a decision, and it should be a conscious one.

Hypercare exit criteria. Teams plan a two-week hypercare period and never define what "over" means, so it either never ends or ends abruptly.