How to know if your ERP go-live is actually ready
"On track" and "ready" are different claims. These are the checks that tell you which one you are looking at.
- Has anyone run the whole thing end to end, once, with real data?
- Do the migrated numbers reconcile — and who signed that?
- What is the open defect count, and how has it moved?
- Has cutover been rehearsed against the clock?
- Can you go back?
- Do the people who use it on Monday know how?
- Does anyone independent agree?
- The questions behind the questions
- What a go/no-go meeting should produce
- Conditional go-live
- The week after
- Who should be in the room for the decision
Every ERP programme reaches a point where someone has to say whether it is ready. The decision usually gets made in a room where the people with the most information have the least incentive to raise a problem, and the people with the most authority have the least visibility of the detail.
Here is what to ask instead of "are we ready?"
Has anyone run the whole thing end to end, once, with real data?
Not module testing. Not a happy-path demo. A full business cycle — order to cash, or procure to pay — executed start to finish, using migrated production-like data, by the people who will actually do it.
The number of programmes that reach a go-live decision without this having happened even once is higher than most executives assume. Ask for the date it was done and the name of the person who ran it. Vagueness in the answer is itself the answer.
Do the migrated numbers reconcile — and who signed that?
Data migration is either reconciled or it is not. Ask for the reconciliation report that shows source totals against target totals, with variances explained line by line.
Then ask who signed it. If the signature belongs to the team that performed the migration, you have a self-certification, not an assurance. Finance should own that signature, because finance is who will be asked to explain the numbers afterwards.
What is the open defect count, and how has it moved?
A raw defect count tells you little. The trend tells you almost everything.
- Is the count falling, or is it flat because new defects arrive as fast as old ones close?
- How many "closed" defects were closed by deferral, re-classification, or a decision to handle the case manually after go-live?
- How many severity-one defects remain open, and what is the plan for each?
A manual workaround is a legitimate decision. Twenty of them, discovered at the gate, is a different system than the one that was approved.
Has cutover been rehearsed against the clock?
A cutover plan is a document. A cutover rehearsal is evidence. The difference is that a rehearsal produces a duration, and durations are stubborn facts.
If the plan allows a 48-hour window and the rehearsal took 61 hours, you do not have a plan — you have an intention. Ask how many rehearsals were run, what the longest one took, and what was descoped to make the timing work.
Can you go back?
Ask what the rollback procedure is, when it was last tested, and at what point it stops being available. Many programmes discover during cutover that the point of no return passed several hours earlier than anyone had documented.
A useful question: at hour 30 of a 48-hour cutover, if the integration to the warehouse system fails, what specifically happens next? If nobody can answer that in a sentence, the rollback plan is theoretical.Do the people who use it on Monday know how?
Training completion percentages measure attendance, not capability. The question is whether users were trained on the system that will exist, or on a version that has since changed.
Where configuration changed after training was delivered, that training is partially obsolete and nobody has recorded which part.
Does anyone independent agree?
The final check is the simplest. Every answer above comes from inside the programme. Independent verification exists to test whether the evidence supports the claim — not to second-guess the team, but to give the board a number it can defend.
That is the entire purpose of a readiness score: to convert a room full of confident opinions into one figure with evidence behind it.
The questions behind the questions
Each check above has a follow-up that tends to be more revealing than the original, because the first answer is usually prepared and the second rarely is.
- Instead of "is testing complete?" — "which business processes have no test case mapped to them?"
- Instead of "did data reconcile?" — "what was the largest unexplained variance, and what happened to it?"
- Instead of "was cutover rehearsed?" — "what went wrong in the rehearsal, and what changed as a result?"
- Instead of "are users trained?" — "which training was delivered before the last configuration change?"
A rehearsal in which nothing went wrong was not a rehearsal. It was a demonstration.
What a go/no-go meeting should produce
The go/no-go decision is frequently the weakest governance moment on the entire programme, because it happens under time pressure with an implicit default of yes.
Three things make it stronger, and all three have to be agreed in advance:
- Written criteria, defined weeks earlier, when nobody knew which way the decision would go. Criteria written the same week are criteria written to be met.
- A named decision-maker. Committees diffuse accountability, and a decision everyone made is a decision nobody made.
- A documented no-go path. If the answer is no, what happens — what is the next candidate date, what does the delay cost, who tells whom?
Programmes without a documented no-go path rarely say no, because saying no means inventing the alternative in the room, under pressure, in front of people who want to proceed.
Conditional go-live
Many programmes go live conditionally — accepting known gaps with agreed workarounds. This is a legitimate and often correct decision. It becomes dangerous in two specific ways.
The first is accumulation. Three manual workarounds is manageable. Twenty is a different operating model, adopted without anyone deciding to adopt it. Count them collectively rather than approving them one at a time.
The second is that workarounds outlive their fix dates. A temporary manual process with no owner and no deadline becomes permanent, and eighteen months later nobody remembers it was meant to be temporary.
If you go live conditionally: give every workaround a named owner and a fix date before go-live, and review that list monthly. The list should shrink. Go BackThe week after
Readiness is usually assessed up to go-live and rarely beyond it, but the first month-end close on a new ERP is where a surprising number of problems surface for the first time.
Ask before you launch: has anyone rehearsed the close? Does finance know which reports have changed? Is there a plan for the first close that assumes it will take longer than usual — because it will.
Who should be in the room for the decision
The go/no-go decision is often taken by the programme and reported to the business. That is the wrong way round. The people who carry the consequences of a bad go-live are the ones who should hold the decision.
At minimum: the executive sponsor, the finance lead who will run the first close, the operations lead who will ship on Monday, and the person accountable for customer impact. If the room is mostly programme and partner staff, the decision is being made by the people with the strongest attachment to the date.
One further participant is worth having: someone whose assessment did not come through the programme. Not to overrule anyone, but so that at least one voice in the room has no stake in the answer.
Free · 90 seconds · No sign-up
Find out where your programme actually stands.
Six questions, an instant score out of 100, and a plain reading of the risks your status reports may not be showing you. Your answers never leave your browser.