cut-over.net Generate plan →
Guides

Cutover rehearsal: the complete guide for integrators

How to design, run, and learn from a cutover rehearsal. Covers the four types of rehearsal (tabletop, mock cutover, dry run, dress rehearsal), timing, what to capture, and common mistakes.

A cutover rehearsal is a practiced execution of the cutover plan against a non-production environment, performed before the real cutover window. Its purpose is to find what will go wrong, while there is still time to fix it.

This guide covers the four kinds of rehearsal integrators run, how to design one that surfaces real problems instead of validating assumptions, what to capture during the run, and how many rehearsals a program actually needs before go-live.

Definition

A cutover rehearsal is a structured, time-boxed execution of the cutover plan against a representative non-production environment. It involves the same people, the same sequence of activities, and (ideally) the same data volumes as the production cutover. It is not a smoke test, a unit test, or a code walkthrough. It is the cutover, run for practice.

Why rehearsals matter

The most common failure mode in cutovers is not a missing step. It is cumulative drift between estimated and actual time per phase. By the time the cutover lead notices that step 4 took 90 minutes instead of 30, three downstream phases are at risk, the business sign-off window has compressed, and the team is making rollback decisions while fatigued.

Rehearsals exist to catch this drift before it costs you. Specifically, a well-run rehearsal surfaces:

  • Time calibration. Activities take longer in practice than on paper. Rehearsals replace estimates with measurements.
  • Hidden dependencies. Integrations, downstream systems, and reporting jobs that nobody on the cutover team owns will surface only when the system is actually moved.
  • Sequence errors. A plan that reads correctly in a spreadsheet often has subtle ordering problems — phase X assumes phase Y has finished, but Y was scheduled in parallel.
  • Decision-making under load. Cutover leads make 30+ go/no-go calls during a typical window, many of them past midnight. Practicing those calls in a low-stakes environment measurably improves judgment.
  • Muscle memory. People who have executed the sequence twice are faster, calmer, and more accurate than people running it for the first time.

The four kinds of rehearsal

Rehearsals exist on a spectrum from cheap-and-fast to expensive-and-realistic. Most programs need more than one kind.

1. Tabletop walkthrough (T-30 to T-21)

A facilitated discussion. The cutover lead reads the plan aloud, phase by phase. Each owner narrates what they would do at that step, in what order, with what tools. No system access, no data, just talking through it.

What it catches: missing activities, owner ambiguity, sequence problems, communication gaps.

Time investment: 2–4 hours.

Who attends: all stream leads. Including junior team members is valuable here — their unfamiliarity with the plan surfaces assumptions experienced people make silently.

2. Mock cutover (T-14)

A partial execution of the plan against a non-production environment. Typically focused on the riskiest phases — data migration, validation, the cutover window itself — and skipping the lower-risk parts like communication procedures and freeze coordination.

What it catches: technical failure modes in the cutover window itself. Time drift on data migration. Validation script bugs. Integration timeout patterns.

Time investment: half a day to one day, plus environment prep.

See the mock cutover explainer for the detailed runbook.

3. Dry run migration (T-10 to T-7)

A full end-to-end execution of the data migration only, against production-equivalent data volumes. The system is not cut over to end users — only the migration itself is rehearsed.

What it catches: scale issues that only appear with real data volumes. Performance regressions. ETL bugs that depend on data patterns. Storage and network bottlenecks.

Time investment: matches actual migration time. Often 8–24 hours.

See dry run migration: a complete how-to.

4. Dress rehearsal (T-7)

The full cutover sequence, executed end-to-end against a production-like environment, with the actual cutover team and at the actual time of day. Communication procedures are simulated. Rollback procedures are tested. Business sign-off is dry-run with real users where possible.

What it catches: everything the smaller rehearsals missed. Sequence problems that only appear under fatigue. Coordination failures between streams. Process gaps in the communication plan.

Time investment: matches the actual cutover window — 8 hours to 72 hours.

This is the rehearsal that, if you do only one, you do. See cutover dress rehearsal: a walkthrough.

How to design a rehearsal that actually surfaces problems

Many rehearsals fail to find problems because they are too forgiving. Common ways to over-soften a rehearsal:

  • Running against a non-representative environment (small dataset, simplified network)
  • Allowing the team to skip steps “because we know they work”
  • Pausing the clock for breaks — real cutovers don’t pause
  • Letting senior people answer for junior owners
  • Skipping participants who can’t attend live (“we’ll loop them in”)
  • Stopping at the first sign of trouble instead of executing through it

If your rehearsal does not surface at least three real issues, it was not strict enough. Tighten the next one.

Designing strictness in

  1. Use a production-equivalent environment. Same data volumes, same integration endpoints, same authentication, same network topology. Where you cannot match production exactly, document the divergence and pay close attention to that area during the post-mortem.
  2. Run on the real clock. If the cutover is scheduled for Saturday 23:00, run the dress rehearsal at 23:00 the previous Saturday. Cognitive load at 03:00 is materially different from cognitive load at 14:00.
  3. Require the actual owner to execute each task. No delegation upward. If the database team’s junior engineer is on the rota for the real cutover, they execute the rehearsal.
  4. Time-stamp everything. Every task start, every task end, every decision point.
  5. Do not pause for problems. If something fails, attempt to recover inside the rehearsal window. The rehearsal is your one chance to practice recovering under pressure.

What to capture during the rehearsal

A rehearsal generates two artifacts: an updated runbook and a debrief log.

Updated runbook: every deviation from the original plan becomes an edit. New steps, corrected timings, additional rollback triggers, fixed owner assignments. Do this live during the rehearsal — not from memory afterward.

Debrief log: structured observations across five categories.

CategoryExamples
Time varianceStep 7 estimated 30 min, took 47 min
New risksDependency on a report job nobody on the team owns
Sequence issuesPhase B depends on Phase A but ran in parallel
Decision qualityLead hesitated on rollback call at 02:15
Communication failuresStream lead unaware that data migration finished

The cutover lead reviews the debrief log within 48 hours and produces an action list. Each action has an owner and a due date — typically before the next rehearsal or the production cutover, whichever comes first.

How many rehearsals does a program need?

A defensible minimum for most ERP and platform migrations:

  • One tabletop walkthrough at T-30 to T-21
  • One dry run migration at T-10 to T-7
  • One full dress rehearsal at T-7

That is three rehearsals. For high-risk programs — global ERP rollouts, regulated industries, programs with weak prior cutover history — add a mock cutover at T-14 and a second dress rehearsal at T-3 to confirm that the action list from the first one actually closed.

For low-risk programs — a contained platform replacement with a small user base — a tabletop plus one dress rehearsal is sometimes enough. Skipping the dress rehearsal is the single most common preventable cause of cutover failure, regardless of program size.

Common mistakes

Treating the rehearsal as a status check. The rehearsal is not a meeting where everyone reports “yes I’m ready.” It is an execution. If the rehearsal looks like a status meeting, it is a tabletop. Tabletops have their place, but they are not a substitute for the other three rehearsal types.

Letting executives observe. Stream leads modify their behavior when senior leadership is in the room. A rehearsal is supposed to surface problems, which requires a culture where it is safe to fail. Brief leadership separately, with the rehearsal output, after the rehearsal is complete.

Skipping the rollback. Most rehearsals execute the happy path through the cutover window and stop. The rollback path is the riskier one — because it is exercised less. At least one rehearsal must execute a full rollback to the source system.

Re-using the previous rehearsal’s environment without resetting. If the source-equivalent environment is not refreshed between rehearsals, the team rehearses against a stale starting point. Each rehearsal should begin from a freshly snapshotted copy of production.

No business validation step. Cutovers that fail to obtain business sign-off inside the window are common. If business validation is not rehearsed, the team finds out at 04:00 during the real cutover that the validation takes longer than the plan assumed.

After the rehearsal: closing the loop

The action list from the rehearsal debrief is the single most important artifact the program produces. It is the difference between an organization that learns from its rehearsals and one that does not.

  • Every action has an owner and a date.
  • The cutover lead reviews status at the next stand-up.
  • Actions that will not close before the cutover are escalated, not ignored.
  • The next rehearsal explicitly validates that the prior actions worked.

Generate your cutover plan

If you have not built a cutover plan yet, start with the free interactive generator. It produces a tailored plan with rehearsal phases already scheduled at T-7 and T-14 — the timing recommended above.

Frequently asked questions

What is a cutover rehearsal?
A cutover rehearsal is a structured, time-boxed execution of the cutover plan against a non-production environment, run before the real cutover window. It involves the same people, the same sequence of activities, and ideally the same data volumes as production. Its purpose is to find what will go wrong while there is still time to fix it.
How is a cutover rehearsal different from a dry run?
A dry run is one kind of cutover rehearsal — specifically, a rehearsal of the data migration only, executed against production-equivalent data volumes. A cutover rehearsal is the broader category, which also includes tabletop walkthroughs, mock cutovers, and full dress rehearsals.
When should the cutover dress rehearsal happen?
The dress rehearsal should happen at T-7 days — one week before the production cutover window. This gives the team time to act on issues surfaced during the rehearsal but is close enough that the environment, integrations, and team state are representative of production conditions.
Do small projects need a cutover rehearsal?
Yes. Even small platform replacements benefit from at least one tabletop walkthrough and one dress rehearsal. Skipping the dress rehearsal is the single most common preventable cause of cutover failure.
Can a cutover rehearsal use a smaller dataset?
Tabletop walkthroughs and mock cutovers can use small datasets. Dry runs and dress rehearsals must use production-equivalent data volumes — scale-dependent issues (timeouts, memory, throughput) only surface at real volumes.
Who should attend a cutover rehearsal?
Every owner listed in the cutover plan must execute their assigned activities personally — no delegation upward. For the dress rehearsal, this means the cutover lead, infrastructure lead, data migration lead, QA lead, business owner, and the on-call rota for the actual cutover window. Executive observers should be briefed separately.