Go-Live Checklist Example: Filled In Two Days Before Go/No-Go
A go-live checklist records each readiness criterion, the evidence that proves it, who confirmed it and when. The example below shows twenty criteria from a fictional ERP release two days before the go/no-go meeting: seventeen met, two waived with a named decision-maker and a compensating arrangement, and one still open.
The example
The checklist below belongs to a fictional ERP go-live at a three-site manufacturer, and is shown as it stood two days before the go/no-go meeting. Twenty criteria across five areas: technical, data, business, operational and governance. Two are waived, one is not met and has an owner chasing it, and the rest are confirmed with the evidence named. This is what the checklist looks like at its most useful - not all green, and honest about it.
| Ref | Area | Criterion | Evidence required | Owner | Status | Confirmed | Note or waiver |
|---|---|---|---|---|---|---|---|
| T-01 | Technical | Production environment built and configured to the signed baseline | Configuration report signed by the solution architect | Infrastructure lead | Met | 06 May | - |
| T-02 | Technical | Performance test passed at 1.5 times peak concurrent users | Performance test report, run 3 | Test manager | Met | 02 May | Peak day is month-end, not an average day |
| T-03 | Technical | Monitoring and alerting live in production, alerts routed to the service desk queue | Screenshot of alert routing and one test alert raised end to end | Service transition lead | Waived | 09 May | Automatic routing due 22 May; alerts monitored manually during hypercare week 1. Waived by the IT service manager |
| T-04 | Technical | No open severity 1 or 2 defects; every severity 3 has an agreed fix date | Defect report exported from the test tool, dated 08 May | Test manager | Met | 08 May | Two severity 3 defects open, both scheduled for the June release |
| T-05 | Technical | Interfaces tested end to end in production configuration, including failure paths | Interface test log with success and failure cases per interface | Integration lead | Met | 07 May | - |
| D-01 | Data | Dry run 3 completed at full volume inside the cutover window | Cutover log: 6 hr 40 min elapsed against a 9 hr limit | Data lead | Met | 04 May | - |
| D-02 | Data | Reconciliation passed: trial balance exact, stock valuation within 0.1%, open orders exact | Reconciliation pack from dry run 3 | Finance data analyst | Met | 04 May | - |
| D-03 | Data | Migration signed off by the business data owners for finance and supply chain | Signed sign-off sheet, one per data domain | Data lead | Met | 06 May | - |
| D-04 | Data | Personal data masked in all non-production environments | Masking report from the data team | Data protection lead | Met | 29 Apr | - |
| B-01 | Business | UAT exit criteria met and the exit report signed | UAT exit report: 214 of 218 cases passed, 4 deferred with agreement | Test manager | Met | 01 May | - |
| B-02 | Business | End-user training completed for all named users | Training register | Change lead | Waived | 09 May | 486 of 502 trained. 16 shift workers to be trained in hypercare week 1. Waived by the operations director |
| B-03 | Business | Super users named per site with contact details in the hypercare pack | Hypercare contact list | Change lead | Met | 07 May | - |
| B-04 | Business | Business verification script written, rehearsed once and owned by named people | Verification script with owners against each section | Cutover manager | Met | 05 May | - |
| O-01 | Operational | Service desk trained, with scripts and a known-error list loaded in the ticket tool | Service desk readiness sign-off | Service transition lead | Met | 08 May | - |
| O-02 | Operational | Hypercare rota staffed for 15 working days, including weekend cover | Signed rota with named people and contact details | Hypercare lead | Met | 07 May | - |
| O-03 | Operational | Third-line support contract active from the go-live date | Countersigned support schedule | Vendor manager | Met | 30 Apr | - |
| O-04 | Operational | Rollback tested to the point of restoring the legacy database in a standby environment | Rollback test log from dry run 3 | Infrastructure lead | Met | 04 May | Restore took 2 hr 10 min; the plan assumes 3 hr |
| G-01 | Governance | Go/no-go meeting scheduled with a named decision-maker and a quorum defined | Meeting invitation and terms of reference | Programme manager | Met | 28 Apr | - |
| G-02 | Governance | Business continuity arrangements agreed for the freeze period | Signed freeze notice with exemptions listed | Operations director | Met | 06 May | Manual order capture at the three sites for the freeze window |
| G-03 | Governance | Weekend cover costs approved and purchase orders raised | Approved budget line and PO numbers | Finance business partner | Not met | - | PO for vendor weekend cover still with procurement. Escalated 09 May, needed by 14 May |
Reading the example
- Ref - a short code with an area prefix, so criteria can be called out in the go/no-go meeting without reading the whole line. It also keeps the list sortable when someone inevitably adds a criterion in week 9.
- Area - the readiness domain. Grouping matters because gaps cluster: a checklist that is green on technical and amber across business and operational is describing a system that works and an organisation that is not ready to use it.
- Criterion - a statement that can only be answered yes or no. "Testing complete" cannot; "no open severity 1 or 2 defects, every severity 3 with an agreed fix date" can. Criteria that need a paragraph to answer are two criteria.
- Evidence required - what someone has to produce. This column is what stops a checklist becoming a set of opinions collected by email. Naming the evidence in advance also tells each owner what to prepare, weeks before they are asked.
- Owner - the person who confirms it, named before go-live week. The owner is the person who can produce the evidence, not the person who wants the criterion met.
- Status - met, not met, or waived. Three values, not a percentage. Partial completion is recorded as not met with a note, as in B-02, rather than as a number that lets everyone assume the remainder is small.
- Confirmed - the date the evidence was accepted. Old confirmations are worth checking: a performance test signed off six weeks and three releases ago is not the same statement it was on the day.
- Note or waiver - for anything waived, who waived it, on what basis and what happens instead. T-03 and B-02 show the pattern: a named decision-maker, a compensating arrangement and a date by which the gap closes. A waiver without those three parts is just a criterion being ignored.
What the waivers are doing
Two waived criteria and one unmet one is a normal state for a checklist two days out. The purpose of the checklist is not to reach all-green; it is to make sure the people deciding know exactly what they are accepting.
T-03 is waived with a workaround: alerts are watched by a person for a week instead of being routed automatically. That is a real cost - somebody has to do it - and the waiver names who agreed to bear it. B-02 is waived because sixteen shift workers cannot be trained before Monday, with a named alternative and a date. G-03 is not waived at all: no one has decided anything yet, which is why it carries an escalation and a date rather than a signature.
The distinction matters at the meeting. Waived items are decisions already taken and can be noted. Unmet items are what the meeting is actually for. Running the meeting itself is covered in the go/no-go meeting guide, and the deck built around a checklist like this one is the go-live readiness deck.
When the criteria should be written
The criteria in this example were agreed at the start of the test phase, roughly two months before the date shown. That timing is the point. Criteria written in go-live week are negotiated against the evidence that happens to exist, and they always pass. Criteria written early are a statement of what the organisation intends to require, made before anyone knows which ones will be inconvenient.
Two things follow. First, each owner knows for weeks what they will be asked to produce, so the evidence column is a work list rather than a surprise. Second, when a criterion is missed, the conversation is about a waiver with a named decision-maker rather than about whether the criterion was ever reasonable. The full set of areas a checklist should cover is in the go-live checklist guide.
What this example leaves out
- Scale. Twenty criteria is a readable summary. A regulated or multi-site programme routinely runs sixty to a hundred, grouped by area and rolled up so that the meeting sees one line per area with the exceptions listed underneath.
- The evidence itself. Every row here points at a document. In practice the checklist links to those documents, and someone has checked that the link opens the thing it claims to.
- Per-site detail. This programme has three sites, and readiness is rarely identical across them. A real checklist for a multi-site release either repeats the business and operational criteria per site or records a site column against each row.
- The rollback and cutover documents. O-04 confirms rollback was tested; the plan it tested is a separate document, as is the timed cutover sequence the weekend runs on.
- Anything about hypercare exit. Go-live readiness stops at the moment the system opens. Whether the programme can hand over and leave is a different set of criteria entirely.
- The history of each row. B-02 was red for six weeks before it became a waiver. The checklist shows the position, not the argument that produced it.
The workbook version of this list, with the criteria, owners and waiver fields already set up, is the go/no-go checklist. The cutover sequence it feeds into sits in the cutover runbook and hypercare pack.
Questions
When should go-live criteria be written?
At the start of the test phase, well before go-live week. Criteria written late are negotiated against whatever evidence exists and always pass, which makes the checklist a formality rather than a control.
Does everything have to be green to go live?
Not necessarily. The checklist exists so the decision-makers know exactly what they are accepting. A waived criterion needs a named decision-maker, a compensating arrangement and a date by which the gap closes.
How many criteria should a go-live checklist have?
Twenty is a readable summary for a mid-sized release. Regulated or multi-site programmes commonly run sixty to a hundred, rolled up so the meeting sees one line per area with exceptions listed underneath.
What is the difference between a go-live checklist and a go/no-go checklist?
In practice they are the same list used at different moments: the readiness criteria are tracked for weeks, then read out as the agenda of the go/no-go meeting where the decision is recorded.