Mock cutover: an explainer

A mock cutover is a partial execution of the cutover plan against a non-production environment, focused on the riskiest cutover-window activities: data migration, validation, and smoke tests. It runs at T-14 days, two weeks before the production cutover, and exists to catch technical issues while there is still time to fix them.

It is one of four types of cutover rehearsal, and the cheapest one that actually executes against real systems.

Definition

A mock cutover is a time-boxed, partial rehearsal of the cutover plan. It exercises the high-risk technical phases of the cutover window — source-system lock, final data migration, validation, and target-system smoke tests — against a production-equivalent non-production environment.

It deliberately excludes communication procedures, business sign-off, DNS cutover, and opening the new system to users. Those belong to the dress rehearsal at T-7.

When in the cutover timeline

T-14 days is the standard slot. Earlier than that, the integration code or migration scripts often are not stable enough to run. Later than that, there is not enough time to act on issues found.

For high-risk programs, schedule two mock cutovers: one at T-21 (early signal) and one at T-14 (confirmation). For most programs, one mock at T-14 is enough.

What’s in scope

A mock cutover includes:

• Source-system lock procedure (in non-prod)
• Final backup snapshot
• Final data extraction / synchronization
• Migration to target environment
• Row-count and checksum validation
• Smoke tests against the target
• Time measurement of every step

A mock cutover excludes:

• Communication to end users
• Business sign-off / UAT
• DNS or load-balancer cutover
• Opening the new system to users
• Full rollback procedure (the dress rehearsal owns this)
• Hypercare procedures

The reason for the narrower scope is cost. A mock that includes everything is a dress rehearsal, and you cannot afford to run two dress rehearsals before most cutovers. Keep the mock focused.

Running a mock cutover: step-by-step

Pre-mock (T-21 to T-15)

1. Confirm environment readiness. The non-production environment must be a representative copy of production — same data volumes, same integration endpoints, same authentication, same network topology. If you cannot match production exactly, document each divergence; the gaps will show up in the post-mock action list.
2. Refresh the environment from a recent production snapshot. No stale data. The mock must run against a starting point that matches what the real cutover will see.
3. Brief participants on scope. Each owner needs to know which of their cutover plan activities are in scope for the mock and which are skipped.
4. Confirm tooling access. Slack channel, video bridge, war-room doc, time-tracking sheet, runbook checklist — all set up and accessible.

Execution day (T-14)

5. Stand up the war room. Same setup the real cutover will use. Slack channel staffed. Video bridge open. Shared timeline document.
6. Execute the source-system lock. Same procedure as production. Time-stamp the start and end.
7. Take the backup snapshot. Verify the backup completes and is restorable. If verification fails, this is the first action item — do not skip past it.
8. Run the final data migration. End to end, at production-equivalent data volumes. This is the longest step in the mock and the most important to time accurately.
9. Validate row counts and checksums. Use the same validation scripts the real cutover will use. If validation fails, do not skip — diagnose and document the failure pattern.
10. Run smoke tests against the target. Same scripts the real cutover will run. Capture pass/fail and elapsed time.
11. Stop. Do not proceed to DNS cutover or user-facing changes. The mock ends after smoke tests.

Post-mock (T-13 to T-7)

12. Debrief within 24 hours. While memory is fresh. Capture observations in the five-category structure: time variance, new risks, sequence issues, decision quality, communication failures. See the cutover rehearsal pillar for the debrief structure.
13. Produce the action list. Each action has an owner and a due date — before the dress rehearsal at T-7 wherever possible.
14. Update the runbook live. Every deviation from the plan becomes an edit. Corrected timings, new steps, fixed owners.
15. Verify actions closed. The dress rehearsal at T-7 explicitly validates that the action list from the mock actually worked.

What to measure

The mock cutover’s primary output is a measurement, not a checkmark. The five numbers to capture:

Metric	Why it matters
Total elapsed time	Does the plan fit in the production window with a 30% buffer?
Data migration time	The longest single phase; drives the rest of the timeline
Validation time	Often underestimated; failures here force rollback decisions
Smoke test time	If smoke tests take longer than the buffer, the plan needs revision
Time-to-recover from a failure	If a step fails, how long does it take to retry and succeed?

If any of these numbers exceeds the plan estimate by more than 30%, the cutover window is at risk. Adjust the plan or expand the window.

Mock cutover vs dress rehearsal

	Mock cutover (T-14)	Dress rehearsal (T-7)
Scope	Technical phases only	End-to-end including comms, sign-off, rollback
Duration	Half day to one day	Full cutover window (8h–72h)
Participants	Technical streams	All streams plus business owners
Environment	Production-equivalent	Production-equivalent
Data volumes	Real	Real
Catches	Migration bugs, time drift, validation failures	Sequence, coordination, communication, decision quality
Skip rollback?	Yes	No — rollback must be exercised

The two rehearsals are complementary. Do both.

Common pitfalls

Cutting scope until the mock fits in 2 hours. The mock has to surface real failure modes. If you compressed it to fit a lunch break, you saved time but lost the insight you were paying for.

Using stale non-prod data. Data patterns in production change. A mock against last quarter’s snapshot misses the patterns that will actually be live on cutover day.

Treating validation failures as “not a real cutover problem.” Validation scripts that fail in the mock will fail in production. Fix them now.

Letting the team skip steps “because we know it works.” The mock is the audit of that assumption.

No time-keeping. If you cannot answer “how long did the migration actually take?”, the mock did not produce its primary output.

Related

• Cutover rehearsal: the complete guide — the pillar, with the full taxonomy of rehearsals
• Dry run migration: a complete how-to — when you want to rehearse the data move at scale, without the rest of the cutover sequence
• Cutover dress rehearsal: a walkthrough — the T-7 full rehearsal that complements the mock
• Cutover plan template generator — generates a tailored plan with rehearsal phases scheduled at T-7 and T-14