Digital Transformation Through Cutover Rehearsals: Testing Your Team's Readiness Before Go-Live
Most digital transformation projects do not fail at the moment a new tool is chosen. They fail at the moment the old system is switched off and the new one is expected to carry the real work. Someone discovers that a spreadsheet nobody documented was feeding invoices, that a shared inbox was the only record of customer approvals, or that the person who knew how the old process really ran has been on leave for a week. A cutover rehearsal is a deliberate attempt to surface those problems while the old system is still running and the cost of a mistake is small. This article explains how UK founders and operators can plan, run and review a rehearsal, and what to decide from the results. It does not assume any particular vendor, product feature or support arrangement; it focuses on the questions your own team should be able to answer before a switch.
Why a rehearsal is different from a pilot
A pilot asks whether a tool is useful. A rehearsal asks whether your organisation can move from one way of working to another without losing track of anything important. The distinction matters because a pilot often runs alongside the existing process, which hides the gaps. People keep doing the real work the old way and only test the new tool on the side, so nobody learns what would have happened if the old route had closed.
A rehearsal therefore simulates the transition itself. You pick a representative slice of work, such as one week of orders, one client onboarding or one month of expense claims, and you process it end to end as though the new system were the only one in use. The old system stays available as a safety net, but the team is asked to behave as if it is not. This reveals the dependencies that a pilot conceals.
Choosing the slice and writing the scenario
Choose a slice of work that includes the awkward cases, not just the easy ones. A rehearsal that only processes standard orders will tell you little about refunds, corrections, partial deliveries, or the customer who always phones instead of emailing. Ask the people who do the work to list the three exceptions that cause the most friction each month, and make sure at least one of them is in the scenario.
Write the scenario as a short script: who starts the process, what information they have at the outset, what decisions must be made, who must approve, and what the finished output looks like. Keep it in plain language. The script should be specific enough that two different people could run it and produce comparable results. If you find yourself unable to write the script, that is already a finding: the process is not yet understood well enough to be moved.
Running the rehearsal and recording what happens
Assign a neutral observer who is not doing the work. Their job is to record time stamps, handoffs, questions asked, workarounds used and any moment where someone reached for the old system without meaning to. Observers often notice that a team member copies a figure into a notepad before entering it, or checks a colleague's personal calendar to confirm an approval. Those habits are the real process, and they rarely appear in documentation.
Capture three kinds of evidence. First, completeness: did every item in the scenario reach its expected end state? Second, time: how long did each step take compared with the old route? Third, confidence: did the person doing the work know what to do next at each stage, or did they stop and ask? Confusion is as informative as failure. A step that succeeds only because a senior person intervened is a risk that will return when that person is busy.
A readiness checklist for the go or no-go decision
Before deciding whether to cut over, answer the following in writing. Can each step of the scenario be completed by someone other than its usual owner? Is there a named person who can resolve a problem during the first two weeks after go-live, and do they know they are that person? Has every data source the process relies on been identified, including unofficial ones such as personal spreadsheets, and has a decision been recorded about whether each one migrates, is retired or stays as a reference? Are the roles that can approve, edit, export and delete data clearly mapped in the new system, and have those permissions been reviewed against the people who actually need them?
Also ask whether you can describe how you would return to the old process if the new one failed on day three. You do not need a perfect answer, but you need some answer. Write down what you would do, who would do it, and how long it would take. If that description is vague, you are not ready to remove the old route, however promising the new tool appears in the demonstration.
Reviewing results and deciding what to change
Hold a short review within a day of the rehearsal while details are fresh. Separate findings into three groups: gaps in the process itself, gaps in training or documentation, and gaps in the tool's fit. Process gaps mean the work was never clearly defined and should be fixed before any system change. Training gaps can be closed with a checklist or a short walkthrough. Fit gaps are the only ones that should prompt a conversation with the vendor, and even then the question should be specific and written down.
Finally, set a rule for what counts as acceptable. Many teams find it helpful to agree in advance that the rehearsal must complete the scenario without falling back to the old system, that no critical data item may be lost, and that the time taken must be within a stated margin of the old route. Agreeing these thresholds before the rehearsal stops the result from being argued into whatever the team already wanted. If the thresholds are missed, the honest outcome is a second rehearsal after the gaps are addressed, not a hopeful cutover.