How to run a go-live readiness review
The six categories a readiness review should cover, how to write criteria that cannot be fudged, and who signs off on what.
A go-live readiness review is the formal check, before a cutover, that everything needed to run the system in production actually exists. Done properly it is the cheapest risk reduction available on a programme. Done as a status meeting where everyone says they are fine, it is worse than nothing, because it manufactures confidence.
The six categories
- Technical: the system is deployed, configured, integrated, performance tested, and monitored.
- Data: migration is complete, reconciled, and signed off by whoever owns the data.
- Training: users are trained, materials exist, and competence has been checked rather than assumed.
- Communications: everyone affected knows what changes, when, and who to contact.
- Support: the support model is staffed and briefed, with an escalation path that has been tested.
- Rollback: there is a documented way back, with a decision point and a named decision maker.
The last two are the ones that get skipped under time pressure, and they are the two that matter most on a bad night. A rollback plan written after a failed cutover has started is not a rollback plan.
Write criteria that cannot be fudged
The single largest determinant of whether a readiness review is useful is how the criteria are written.
"Training complete" is not a criterion. It cannot be failed by anyone determined to pass it. "94% of named users have completed the core module and scored above 80% on the assessment" is a criterion, because it is either true or it is not.
Each criterion needs an owner, a target date, a status, and evidence. Evidence is what turns the review from a set of opinions into a set of facts. "Yes, we tested that" and a link to the test results are very different statements.
Run it more than once
A single review the week before go-live is too late to fix anything it finds, which creates enormous pressure to find nothing.
A workable rhythm is three passes: one about four weeks out to surface gaps while there is time to close them, one about a week out to confirm they closed, and a short go/no-go immediately before cutover against the outstanding items only.
The first review is supposed to find problems. If it does not, either the programme is in unusually good shape or the criteria are too soft, and the second is more likely.
Sign-off
Every category needs a named person accountable for it: not a team, a person. "Technical readiness: signed by the head of platform engineering, 14 March, with evidence attached."
This is not bureaucracy. A named signature changes how carefully someone reads a criterion, and it means that on the night, when a question arises about whether the integration testing really covered the payment path, there is somebody who knows.
Record conditional sign-offs explicitly
Most real programmes go live with some items open. That can be a legitimate decision. What is not legitimate is an open item quietly recorded as closed. Track it as a conditional sign-off with the condition, the owner, and the date it will be resolved, usually during hypercare.
The go/no-go itself
Keep the final meeting short and narrow. It is not a status update, and it is not the place to review the whole checklist again.
It covers only the outstanding items, the risks accepted in going ahead, the rollback decision point, and who is on call. Everything else was settled in the earlier reviews, which is exactly why they exist.
How this works in Depentra
The Go-Live Readiness Checklist template arrives with the six categories, each criterion carrying an owner, target date, status, evidence, and whether sign-off is required, and exports a formal sign-off document.