By Ritvars Mētra, Founder of ReadinessCompassMost ERP programmes rehearse their cutover two or three times. Almost all of those rehearsals test the same thing: whether the technical runbook completes inside the weekend window.
That is a real and necessary test. Extracts run, loads complete, reconciliations balance, the sequence holds, and the team learns that step 47 takes ninety minutes rather than the forty they planned. Every one of those findings is worth having.
But at the end of it, the programme knows that the system can be cut over in a weekend. It knows nothing at all about whether the organisation can work on Monday.
The gap a technical rehearsal leaves
A technical cutover rehearsal is performed by the people who built the system, executing a sequence they wrote, in an environment they control, without customers. It is a test of the migration.
The first working day is the opposite of all four conditions. It is performed by people who did not build anything, executing work they have practised for a few hours at most, in a live environment, with real customers waiting. The rehearsal that resembles this is a different exercise entirely, and most programmes never run it.
Markus and Tanis, in their study of the enterprise system lifecycle, list among the characteristic problems of the post-go-live period a phrase worth sitting with: no growth of end-user skills after initial training. Training happens, and then capability plateaus — because being shown something once, in a classroom, several weeks before you need it, does not make you able to do it under pressure. This is why training completion and adoption are different measurements, and why the gap between them is usually discovered on day three.
Rehearsal is not a softer version of training. It is a stronger one
The evidence for practice over instruction is unusually strong, and it does not come from change management. It comes from medicine.
In a meta-analysis published in Academic Medicine, William McGaghie and colleagues compared simulation-based medical education with deliberate practice against traditional clinical education across fourteen studies and 633 learners. The pooled effect size was 0.71 (95% CI 0.65–0.76). The authors describe the results as powerful, consistent, and without exception — every individual study favoured the simulation-based approach.
That is trainee doctors learning procedures, not warehouse operatives learning goods receipt. But the mechanism transfers exactly: repeated attempts at a realistic task, with immediate feedback, at increasing difficulty, until performance reaches a standard. Deliberate practice is not more classroom time. It is fewer explanations and more attempts.
If a hospital would not let a registrar attempt a procedure on a patient having only watched a demonstration, it is worth asking why a business will let a team run the month-end close on that basis.
Borrow a taxonomy that already exists
Change programmes tend to invent rehearsal formats from scratch, which is why they end up with one giant event that is too complex to run well and too late to fix anything. Emergency management solved this problem decades ago.
The US Homeland Security Exercise and Evaluation Program defines seven exercise types, split into discussion-based (seminars, workshops, tabletop exercises, games) and operations-based (drills, functional exercises, full-scale exercises). Its central principle is the building-block approach: exercises increase in complexity over time, each one preparing participants for the next, so that a full-scale exercise is preceded by the smaller formats rather than substituting for them.
That maps onto a go-live almost without translation.
| Exercise type | Cutover equivalent | What it surfaces |
|---|---|---|
| Tabletop | Walk the first day aloud with managers and process owners, no system | Unowned steps, disagreements about who decides, missing handoffs |
| Drill | One team, one process, repeated attempts in the test system | Whether individuals can complete a task unaided, and how long it takes |
| Functional | A full end-to-end chain across functions — order to cash, procure to pay | Handoff failures, data that arrives wrong, queues forming between teams |
| Full-scale | A simulated live day at realistic volume, with injected exceptions | Whether the organisation holds up under load, and where it breaks first |
The sequencing is the point. A programme that runs only the last row will discover fifty problems in one day, most of which could have been found and fixed weeks earlier at a fraction of the cost — and it will have no time left to fix any of them.
Designing the rehearsal so it tells you something
Choose scenarios by consequence, not by novelty. The instinct is to rehearse what changed most. The right selection is what hurts most if it slows: the processes with customer-facing deadlines, cash impact, or regulatory timing. A change impact assessment already contains this list if one was done; if not, three process owners in a room will produce it in an hour.
Use real volume, or a realistic fraction of it. A rehearsal in which each person processes two orders proves that the transaction works. It does not test the thing that actually fails, which is throughput. If the team handles 300 orders a day, rehearse 60 in two hours and see what happens to the queue.
Inject exceptions deliberately. Happy-path rehearsals are the most common design failure. Real work is mostly exceptions: the short delivery, the blocked customer, the price that does not match, the approval from someone on holiday. Write eight of these in advance and hand them out mid-session. Exceptions are also where UAT tends to reveal the difference between confidence and capability.
Ban rescue. This is the rule that changes what you learn. If a super user or consultant is allowed to lean over and take the keyboard, the rehearsal measures the expert, not the team. Put the experts in the room as observers with a written instruction not to intervene for the first ten minutes, and record every occasion someone needed them. That list is your capability gap, and it is also an early warning of the expert dependency that will consume hypercare.
Rehearse the support model too. Have people raise tickets the way they will on day one, to the people who will actually answer them. Most programmes discover during this that the routing does not exist, or that the answer to half the questions is “ask Maria”.
What to record while it is happening
Rehearsals generate impressions. Impressions do not survive contact with a steering committee. Five things are worth capturing in writing, by an observer whose only job is to watch:
- Unaided completion rate — by role and by scenario. The single most useful readiness number a programme can hold, and it is not obtainable any other way.
- Time per transaction, against the legacy baseline. Expect it to be worse. You are looking for how much worse, and whether it improves across attempts.
- Every intervention — who needed help, on what step, from whom.
- Recurring questions. The same question asked by five people is a design or documentation defect, not five training gaps.
- Workarounds invented in the room. People will start improvising within twenty minutes. Whatever they invent under rehearsal conditions, they will use in production — and, as Markus and Tanis observe, they will keep using it long after the underlying problem is fixed. This is where the spreadsheet habit begins, and a rehearsal is the cheapest place to catch it.
Unaided completion by role also gives the receiving manager something concrete to sign, which is what turns business readiness from an assertion into evidence.
A programme that did this properly
When the Bank of England replaced the Real-Time Gross Settlement system — infrastructure settling around £790 billion of sterling payments a day — it could not rely on its own readiness alone, because the change landed on every bank and payment provider connected to it.
The National Audit Office records the approach: the Bank engaged RTGS users to prepare them for major milestones through user testing, dress rehearsals, and monitoring industry readiness. Three distinct activities. Testing proved the interface. Dress rehearsals proved the participants could operate it. Monitoring industry readiness tracked whether the wider population was keeping pace — a readiness measure about other people’s organisations.
Most internal programmes have the equivalent of all three available and use only the first. The shared services centre, the third-party logistics provider, the outsourced AP function and the interfacing customer are all in your cutover whether you rehearse with them or not.
Four ways rehearsals get wasted
- Run too late to act on. A rehearsal two weeks before go-live can only inform the go/no-go decision. To change capability it needs six to eight weeks of runway, and preferably a second attempt.
- Staffed by volunteers. The people who put their hands up are the confident ones. Rehearse with the median performer and the person who was on leave during training — those are the people who define day one.
- Treated as a training event. If the session is framed as learning, nobody records failure honestly. Frame it as a test of the design, not of the people, and say so out loud at the start.
- No after-action review. HSEEP treats improvement planning as part of the exercise, not an optional follow-up: findings become assigned corrective actions with owners and dates. A rehearsal whose findings live in a facilitator’s notebook has cost you a day and taught the organisation nothing.
The question a rehearsal answers
A technical cutover rehearsal answers whether the migration will complete. A business rehearsal answers something a steering committee cannot get anywhere else: can these specific people, at this volume, with these exceptions, produce the organisation’s normal output — and if not, which ones cannot, on what, and by how far.
Half a day of structured observation produces more defensible readiness evidence than a month of survey work, because it measures behaviour rather than belief. It is also the only method that reliably exposes borrowed confidence — the person who is sure they can do it because the expert was sitting beside them last time.
Programmes rarely regret rehearsing. They regret rehearsing the runbook and calling it readiness.
More on evidence-led ERP go-lives in the ERP Readiness Hub, or see how a Readiness Diagnostic Sprint designs and runs this kind of observation when the date is close.