When to use this checklist
Start six to sixteen weeks before the go-live decision, while there is still time to close gaps. Run it again for the final go/no-go meeting, on the evidence as it stands that week. The checklist is not a substitute for the plan. It is a test of whether the plan’s claims are true.
For SAP ERP 6.0 customers the horizon is fixed: SAP’s mainstream maintenance for SAP Business Suite 7 ends at the end of 2027, with optional extended maintenance to the end of 2030. A fixed horizon adds pressure on the date, which makes an evidence-based decision more important, not less.
How to test each claim
Each line of the checklist is a claim someone will make in the go/no-go meeting. Do not accept the claim as stated. Ask the five READINESS-5 questions. A claim reported Green with only two of the five is an assumption, not a fact.
| Element | The question | What counts as evidence |
|---|---|---|
| Status | Is the status current and specific? | A dated status that says what is done and what is not, not “on track” |
| Owner | Is there a named owner with authority? | One person who can make it true, not a team or a vendor |
| Evidence | Is there an artefact you can open? | A test log, a reconciliation output, a signed approval |
| Date | When will it be true? | A calendar date, not “before go-live” or “soon” |
| Action | What happens if it slips? | An agreed fallback, workaround or change to the plan |
The checklist
Five domains. Apply READINESS-5 to every item that is critical for your programme.
1Testing
- System integration testing complete, with every open defect closed or accepted by a named owner.
- User acceptance testing signed by each business area and entity in scope, not only by the project team.
- Regression run on the final transport set that will go to production.
- Performance tested at production-like volumes for the critical processes.
- Open defects triaged by severity, each with an agreed workaround or a fix date before go-live.
2Data migration
- At least one full mock load on production-like data, with timings recorded.
- Reconciliation of record counts, balances and key fields, signed off by the data owners.
- Load and validation timings fit inside the cutover window, with contingency.
- Cut-off rules agreed for open items: open orders, open invoices, in-flight approvals.
- Master data cleansing complete for the objects that block transactions on day one.
3Integration
- Every interface tested end to end against the real partner systems, not stubs.
- Tax and e-invoicing integration tested where it applies, for example UAE e-invoicing or the ZATCA Fatoora platform.
- Interface monitoring, error queues and reprocessing in place, with an owner for each.
- Partner and bank sign-offs received for changed formats and connections.
4Cutover
- Cutover plan rehearsed end to end, with actual timings from the rehearsal.
- Rollback point agreed, and the rollback plan tested.
- Point of no return named, with the person who calls go or rollback.
- Go/no-go criteria for cutover agreed before cutover starts.
- Business freeze periods and communications agreed with each entity.
5Governance and business readiness
- Hypercare staffed, with exit criteria and the hand-over to normal support agreed.
- Support model in place across business, internal IT and the system integrator.
- Key users trained, and roles and authorisations tested in production-like conditions.
- RAID log current: every open risk and issue has an owner and an action.
- Business readiness confirmed by each entity in scope, in writing.
Then check the claims against each other
The most expensive risks sit between workstreams, where each team’s report is accurate on its own terms. Look for these four patterns:
- A test pass rate that is high because the scope was reduced.
- A data reconciliation reported as passed while a business entity has not signed UAT.
- A cutover plan approved with no agreed rollback point.
- A headline status that cannot be traced to the workstream statuses beneath it.
Who should run it
The programme director usually owns the checklist, but the evidence should be checked by someone who did not produce it. If the system integrator fills it in and the steering committee reads it, the checklist repeats the status report in a different format.
Ask each workstream lead to attach the artefact behind every claim, and have someone outside delivery open them. Where an artefact cannot be produced, mark the element missing, not partial. Where two workstreams describe the same thing differently, treat it as a finding until it is explained.
From checklist to decision
The checklist should end in one of three decisions. Go: the evidence supports the date. Conditional Go: named conditions, owners and dates that must be met first. No-Go: what is missing and the shortest path back to a date.
A Conditional Go is only useful if each condition is written as a test someone can pass or fail, with one owner and an evidence-by date. “Data migration to be stabilised” is not a condition. “Finance signs the trial balance reconciliation for all entities by 14 March” is.