SAP Mock Cutover: What a Dress Rehearsal Must Prove

Decision context

A mock cutover exists to replace estimates with measurements. If it finishes and the plan still contains estimated durations, an untested rollback, and a reconciliation that was eyeballed, it was an expensive walkthrough.

Most programs run two or three rehearsals. The first proves the sequence is complete, the second proves the timings fit the window, and the last proves the whole thing including reconciliation and rollback on production-sized data.

What Adranum contributes is narrow and specific: it records what was executed, binds validation results to the exact package, and preserves the checkpoint a rollback would restore, so the rehearsal produces evidence rather than recollection.

What each rehearsal is for

Giving each rehearsal a single question keeps scope honest. A rehearsal that tries to answer everything answers nothing conclusively.

• Mock 1, completeness. Does the runsheet contain every task, in a workable order, with an owner? Volume can be reduced. The output is a corrected task list, not a timing.
• Mock 2, timing. Do the downtime-relevant tasks fit the agreed window at production volume? This is the rehearsal that must not be shortcut on data size, because load and conversion times do not scale linearly.
• Mock 3, full dress. The complete window, production volume, the real team, the real command centre cadence, reconciliation executed and signed, and rollback tested at least once from a real checkpoint.
• Optional rollback drill. If the full dress rehearsal cannot afford to test rollback, test it separately. An untested rollback is a plan, not a capability.

Outputs that make a rehearsal count

Ask for these before the rehearsal starts, so the team collects them while it runs rather than reconstructing them afterwards.

• Actual start and finish per task, recorded live, not filled in from memory the next morning.
• The revised critical path and the new downtime budget, with the remaining slack stated explicitly.
• A defect list from the rehearsal with owners and target fix dates, tracked like any other defect.
• Reconciliation output at production volume: record counts, control totals, and open item balances compared source to target.
• The interface restart sequence, proven, including queue drain and duplicate protection.
• A rollback execution record: what was restored, how long it took, and how the restored state was verified.
• A list of every manual step performed but missing from the runsheet. This list is always non-empty on the first rehearsal.

Common reasons a mock cutover misleads

A rehearsal can pass and still fail to predict the real weekend. These are the usual causes.

• Reduced data volume. Load, conversion, index and reconciliation times are the tasks most likely to break the window and the least likely to scale from a subset.
• A quality system with different hardware, memory, or storage from production.
• Interfaces stubbed rather than connected, so queue behavior, duplicate handling, and partner windows go untested.
• The rehearsal team is the people who built the plan. The real window is often staffed differently, which is exactly what the deputy column is for.
• No business participation, so the business verification gate is never exercised and its duration is unknown.
• Rollback declared out of scope, which converts the highest-consequence unknown into an assumption.

What the workflow must cover

• Measured timings. Capture actual per-task durations during the rehearsal and feed them back into the runsheet's downtime budget.
• Reconciliation evidence. Compare source and target counts, control totals, and open items as a recorded artifact rather than a verbal confirmation.
• Package binding. Bind each validation result to the exact package that was executed, so a later change invalidates the earlier approval.
• Verified rollback. Keep a checkpoint of prior target state and record what a restore actually returned, so recovery is demonstrated rather than described.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Set one question for each rehearsal and agree the exit criteria.
2. Restore the source and target to a defined starting state.
3. Execute the runsheet with live actuals and a real command centre cadence.
4. Run reconciliation and rollback, and record both outputs.
5. Rebuild the downtime budget from measured durations and re-plan.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Rehearsal starting state
• Per-task actual durations
• Revised critical path
• Defect list with owners
• Reconciliation output
• Interface restart record
• Rollback execution record
• Undocumented manual steps found

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A rehearsal on reduced data does not predict a production window.
• Hardware and storage differences between the rehearsal system and production change timings in ways no tool can extrapolate.
• Rehearsal results age. A landscape change after the last rehearsal reopens the timing question.

Buyer checklist

• Was the rehearsal run at production data volume?
• Were interfaces really connected or stubbed?
• Was rollback executed, and how was the restored state verified?
• How many manual steps were found that were not in the runsheet?
• Does the downtime budget still have slack after the measured durations?