A go-live readiness checklist for a customer implementation lists the gates that must be met before the customer's people start working in the new system. Each gate names the evidence, the owner who delivers it, and the person who accepts it. The rollout proceeds only when the named decision owner makes a go decision against that list, and the project lead can show the record behind every gate.
What should a go-live readiness checklist include?
A go-live readiness checklist for a customer implementation should cover data, users, cutover, customer-side dependencies, support, and rollback. Each line needs evidence, a delivery owner, and an accepter. A line without evidence stays open until the evidence exists. The table below is a starting point; replace each bracketed placeholder with your project's detail.
Moxo's go-live guide makes the same point: “A structured go-live planning checklist transforms scattered assumptions into explicit tasks with owners, deadlines, and dependencies” (Moxo).
In the table, the Accepted by (decision owner) column names the person who can accept each gate's evidence.
| Gate | Evidence to review | Met when | Owner | Accepted by (decision owner) | Status |
|---|---|---|---|---|---|
| Data validated | [Reconciliation report and its file location] | Agreed reconciliation checks are run, and each discrepancy is fixed or accepted by name and date | [Data lead] | [Customer data owner] | [Met / Open] |
| Users ready | [Practice results for each role's critical tasks] | Each role has finished its critical tasks in practice, and [customer department lead] has signed off the results | [Trainer] | [Customer department lead] | [Met / Open] |
| Cutover plan signed off | [Cutover runbook and rehearsal notes] | Each cutover script has been rehearsed and signed off at the go/no-go checkpoint | [Project lead] | [Customer sponsor] | [Met / Open] |
| Customer dependencies cleared | [Access, approvals, and notices from the customer] | Each dependency is delivered, and the named customer contact has confirmed it in writing | [Customer contact] | [Customer sponsor] | [Met / Open] |
| Support path confirmed | [Named support contacts and escalation route] | Support owners, coverage, and escalation routes are named and confirmed | [Support lead] | [Customer service owner] | [Met / Open] |
| Rollback criteria agreed | [Written stop conditions and steps] | Stop conditions and return steps are written, and the decision owner has accepted them | [Project lead] | [Decision owner] | [Met / Open] |
Keep the table in the project's shared tracker, or in a document the sponsor can open. Report each gate as met or open. ALA Consulting's guide says readiness should not be reported as a percentage when one open issue can block launch (ALA Consulting), so mark each gate met or open rather than reporting a percentage complete.
The Met when wording follows Microsoft's go-live checklist, which asks for test cycles with “exit criteria met and signed off by the business stakeholders” (Microsoft Learn). It also follows ALA Consulting's call for “agreed acceptance criteria” set before the review (ALA Consulting).
Illustrative filled gate, with placeholders only:
Gate: Users ready
Evidence: practice results for the [role] critical tasks, recorded in [tracker name]
Met when: each [role] has finished its critical tasks in practice, and [customer department lead] has signed off the results
Owner: [trainer]
Accepted by: [customer department lead]
Status: Open
Who decides whether the rollout goes ahead?
The named decision owner decides whether the rollout goes ahead, and the project lead makes the recommendation. Name that person in writing before the readiness review, and copy the name into the checklist header so no one has to guess who can say yes.
Editorial judgment, not from the listed sources: in most customer implementations the decision owner is the customer sponsor or a business owner who can accept operational risk.
An exception that goes live needs approval from someone authorized to accept the risk. ALA Consulting's guide adds that each accepted exception needs an owner, an agreed action, and a due date (ALA Consulting). Ask the sponsor these questions by email:
- Who can say yes to going live?
- Who can stop the rollout?
- Who accepts an open item that goes live as an exception?
Confirm the answers in writing with the date, and copy the names into the checklist header.
How do you check that data is ready?
Data is ready when migrated records have been reconciled against the source, each discrepancy is fixed or accepted by the customer data owner, and the cutover steps have run on a copy of the data. Ask the data lead to show the reconciliation, not to report that the migration is complete.
Microsoft's go-live checklist asks teams to “test and sign off on all scripts and processes that are planned for the cutover migration” (Microsoft Learn). Use the same test on your project:
- Agree the reconciliation checks with the customer data owner. Include record counts by type and the totals the business relies on, such as [account balances or stock totals].
- Run the migration on a copy of the data and save the output.
- Compare a sample of records, chosen with a business user, against the source system.
- Log each discrepancy with an owner and a decision: fix it, or accept it with the customer data owner's name and the date.
Sample status line:
Data validation: reconciliation completed on [date]. Open discrepancies: [list]. Decision needed from [customer data owner] on [item] by [date].
How do you confirm users are ready?
Users are ready when each role can finish its critical tasks in the new system with the support they will have on the day. Attendance at training does not show that. Ask each role to complete a short practice task and record the result.
Whatfix's guide says go-live readiness “can’t be reduced to basic communication, user acceptance testing (UAT) sign-up, and training completion” (Whatfix). In practice:
- List the roles that will use the new process, and the critical tasks each role must finish.
- Ask each role to complete those tasks in a test environment, using the materials they will have on the day.
- Record each task as complete, complete with help, or not complete.
- Turn every “not complete” into an open gate with a named trainer and a date.
When does the go/no-go meeting happen, and what does it cover?
The go/no-go meeting decides whether the rollout proceeds on the planned date, proceeds with named exceptions, or waits. Open with the lines that are not met. Hold it after the cutover rehearsal and before the go-live date, and send the checklist beforehand. Keep status updates out of it.
Microsoft's guidance asks for sign-off from stakeholders at the cutover go/no-go checkpoint (Microsoft Learn). Editorial judgment, not from the listed sources: the rehearsal shows which open lines are real, so the meeting should follow it, and holding the meeting before the go-live date leaves time to move the date if the answer is delay.
Use this agenda:
- Confirm the decision owner and the question: go, go with exceptions, or delay.
- Walk the open lines only. For each one, record an outcome: close it before the go-live date, accept it as an exception, or move the date.
- For each accepted exception, record the owner, the agreed action, the due date, and the name of the person who accepted the risk.
- Read back the decision and its conditions, and send the written record before the group leaves the meeting.
Illustrative decision record, with placeholders only:
Decision: proceed with exceptions
Open item: [item]
Exception owner: [name]
Agreed action: [action]
Due date: [date]
Accepted by: [name and role], who is authorized to accept the risk
Recorded on: [date]
Sample decision request:
Subject: Go/no-go decision for [project name] on [go-live date]
[Sponsor name], the readiness review is complete except for the items below. Recommendation: [proceed / proceed with exceptions / delay]. Open items: [item, owner, due date]. Please confirm your decision by [date] so the team can [next step].
What counts as a launch blocker?
A launch blocker is an open gate that stops the go decision, because it would stop a critical task on the first day or make a failed change hard to reverse. Other open items can move past launch when each has an owner, an agreed action, and a due date.
ALA Consulting's guide draws the same line between launch blockers and issues that can be managed after launch (ALA Consulting). Test each open item with these questions. Can a user finish the main task without it? If it fails on the first day, can the team stop and return to the old process? If the answer to either question is no, the item is a blocker, and it goes into the decision record described under the go/no-go section above.
What should the rollback plan say?
A rollback plan states the observable conditions that trigger a stop, the steps to return to the previous process, and the person who can call the stop. ALA Consulting describes fallback as criteria for stopping or reversing the change, with an accountable decision maker (ALA Consulting). Write the plan before the cutover rehearsal, not during the launch.
Template:
Stop trigger: [observable condition, such as a critical record that cannot be saved after the agreed retries]
Who can call the stop: [name and role]
Steps to return: [step, with owner for each step]
How the old process is checked: [who checks, and how]
Who tells users, and what they are told: [name and message]
Microsoft's guidance asks a cutover plan to cover dependencies, timing, roles and responsibilities, verification steps, and documentation for each activity (Microsoft Learn). Check the rollback steps against the same list.
How do you clear customer-side dependencies?
Customer-side dependencies are the items only the customer can deliver, such as system access, approvals, data owner sign-off, and notices to the customer's own staff. List each one with a named customer contact and a date, and escalate through the sponsor when a contact does not respond in time.
Microsoft's guidance asks teams to align external dependencies with the timelines and scope for go-live (Microsoft Learn). Send each dependency as a specific request:
Subject: [Action needed] [dependency] before [go-live date]
[Contact name], [project] goes live on [date] and needs [dependency]. Please [specific action] by [date]. If that date will not work, tell me by [date] so we can agree the next step with [sponsor name].
When the sponsor has to make a choice, send it as a decision request with the options and the date. Record the answer on the checklist line it affects.
What mistakes do teams make at go-live?
Go-live decisions go wrong when teams treat a green status as proof, count training attendance as readiness, or leave the decision owner unnamed. Check each of these risks before the go/no-go meeting, and give each one a named owner and a date.
- Treating a green status as proof. ALA Consulting's guide notes that “a green status without a review or acceptance record leaves too much room for different interpretations” (ALA Consulting).
- Counting training attendance as readiness. Use practice tasks instead.
- Leaving the decision owner unnamed, so the meeting ends with agreement in general and no one has said yes.
- Reporting readiness as a single percentage. An open gate can still hold the launch.
- Running the go/no-go meeting as a status update, so the decision slips to the end.
- Accepting an exception with no due date.
What happens after the go decision?
After a go decision, the checklist becomes the hypercare list. Hypercare is the period of close support right after go-live. Steady support takes over only when every exit condition has its evidence recorded and an accepter named. Use the exit conditions below as the handover record.
Microsoft's guidance asks for a plan covering production monitoring and for transitioning to support teams (Microsoft Learn). Write each exit condition with the evidence, the person who accepts it, and the date:
- Support issues from the first days are resolved or accepted, with the open list and the accepter recorded. Evidence: [open support issue list]. Accepted by: [customer service owner]. Date: [date].
- Monitoring checks have run on the agreed schedule, with results recorded. Evidence: [monitoring log]. Accepted by: [support lead]. Date: [date].
- Named support owners and escalation routes are handed to the steady support team. Evidence: [handover note listing contacts]. Accepted by: [steady support lead]. Date: [date].
- Each role can finish its critical tasks without help from the project team. Evidence: [practice results or support ticket review]. Accepted by: [customer department lead]. Date: [date].
Before the work moves to steady support, record the evidence for each exit condition.
Next step: ask [customer service owner] for the open support issue list by [date], so the first exit condition has evidence before the handover meeting.