What goes in a go/no-go checklist?
A go/no-go checklist lists the readiness criteria agreed before the meeting, each with an owner, the evidence behind it, a yes or no answer and an explicit note of whether it can be waived. It spans technical, data, testing, business, support and governance readiness, and it records the fallback position and the deadline for the decision.
The structure of a single line
A checklist that is a list of statements is not much use in a meeting. What makes it work is the columns beside each criterion, because those are what turn a discussion into a record.
| Column | Why it is there |
|---|---|
| Criterion | Written so the answer is yes or no, not a judgement |
| Owner | The named person who answers for it, not a team |
| Evidence | The report, test result or sign-off the answer rests on |
| Status | Met, not met, or met with conditions |
| Waivable | Whether proceeding without it is permitted at all |
| Waiver approver | Who may accept the gap, if it is waivable |
| Mitigation | What compensates for the gap if a waiver is granted |
The waivable column is the one most checklists lack, and it is the one that shortens the meeting. Deciding in advance that a criterion is mandatory removes an argument that would otherwise be held at the worst possible moment. The Go/No-Go Checklist is built around those columns.
Technical readiness
Environments built and configured to the agreed specification. Code and configuration deployed to the target and version-matched to what was tested. Infrastructure capacity confirmed against expected load. Interfaces configured and connectivity proven end to end with each third party. Backups taken and, more importantly, a restore tested rather than assumed. Monitoring and alerting active before go-live rather than added after the first incident.
Data readiness
The dry run completed at production volume with recorded timings. Reconciliation results within the tolerances agreed in advance, and a named person who has signed those results. Data cleansing complete for the objects the business depends on from day one. Defects from the last dry run either closed or accepted with a documented workaround. The data migration guide covers what reconciliation should actually prove.
Testing readiness
Test execution complete against the agreed scope. Open defects listed by severity, with severity defined the same way everyone in the room understands it. No open severity 1 or 2 defects, or each one explicitly accepted with a workaround and an owner. Regression run against the interfaces and the integrations that were changed last. Performance results against the agreed thresholds.
Business readiness
Training delivered, with a record of who attended and who did not. Process documentation available to the people who will use it on the first day. Business sign-off on the user acceptance results. A verification team named and rostered for the window and the first morning. Manual workarounds documented for anything that will not be available at go-live. Communication issued to end users with the outage times and the support route.
Operational and support readiness
The support model agreed: severity definitions, response expectations, hours of cover and the escalation path. Service desk briefed and scripts updated. Hypercare staffing confirmed and rostered, including the people who wrote the code. Known errors and workarounds handed to support in a form they can search. Access and accounts provisioned for the support team, which is the item most often discovered missing at 08:00 on day one. The hypercare guide covers what that period needs.
Governance and commercial readiness
The change record raised and approved through whatever governs production change. Contractual milestones and any acceptance conditions confirmed with suppliers. Regulatory or audit requirements evidenced where they apply. Fallback approved, with the rollback plan tested at least once. The decision-maker present, or a named delegate with the same authority.
The lines that are not criteria
Two things belong on the checklist that are not readiness items. The first is the fallback position: what happens if the answer is no. A no-go with no agreed next step turns into an unplanned meeting the following week and a date nobody can commit to. The second is the decision deadline — the latest moment the decision can be made and still leave time to execute either outcome. Both belong on the front page.
Keeping the checklist honest
Criteria are agreed early, ideally when the cutover plan is drafted, and not edited in the week before the meeting. A criterion softened three days out is not readiness; it is a lowered bar with a tick beside it. Where a criterion genuinely no longer applies, it is removed with a reason recorded, which is a different thing from quietly rewording it.
The checklist is also the source for the readiness view presented at the meeting. The Go Live Readiness Deck puts the same criteria in front of the committee as a scorecard, and the go-live checklist guide covers the fuller technical, data and operational set.
Questions
How many criteria should a checklist have?
Enough to cover each readiness area with a named owner, and few enough that each one is genuinely checked. A list nobody can work through in the meeting is a list that gets skimmed.
Who writes the criteria?
Each workstream writes the criteria for its own area, and the group that will take the decision approves the combined set before the window is scheduled.
What counts as evidence?
A document, test report, reconciliation output or signed record that someone other than the owner could inspect. A verbal assurance is a status, not evidence.
Can a criterion be marked amber?
The status can record met with conditions, but the decision itself is binary. Amber criteria need a waiver decision, an approver and a mitigation, otherwise they carry into go-live unresolved.