Lesson 2 of 5
Rehearsal design
11 min
Listen to this lesson
A rehearsal that is badly designed produces numbers nobody trusts. A well-designed one produces a timed, sequenced, signed record of the cutover that the steering committee can use to decide whether the real one will fit in the window. Design comes down to four choices: the environment, the data, the runbook and the measurement.
Environment: as close to production as you can get
Rehearse on infrastructure sized like production. For Contoso, moving to SAP S/4HANA Cloud Private Edition under RISE, that means agreeing early with the platform team which system will host the mocks (often a copy of the target landscape or a dedicated cutover system) and booking the technical steps that the provider performs. If the rehearsal system is much smaller than production, load times will be misleading in both directions: slower because of less hardware, or faster because of less data.
Data: realistic volumes, realistic mess
Use a full or near-full extract of production data, taken the way it will be taken on the night. Small samples hide the two things that hurt most at cutover: long run times and data that fails validation. Contoso's mock 1 used a 10% sample and loaded open sales orders in 40 minutes; mock 2 with full volumes took over five hours, because thousands of orders for Great Lakes Fleet Services carried pricing conditions that needed checking.
Runbook: one line per task, owned and timed
The runbook is a test script for the cutover. Each task needs enough detail that the owner could perform it without asking, and enough structure that you can time it and measure dependencies.
| Runbook column | Why it matters | Contoso example |
|---|---|---|
| ID and task | Unique reference for timing and lessons learned | C-214 Load open purchase orders, plant 1710 |
| Owner and backup | Named people, not teams | Data migration lead; backup: P2P consultant |
| Predecessors | Defines sequence and the critical path | After C-180 supplier master load and C-190 purchasing info records |
| Planned start and duration | Baseline to compare against | Sat 04:00, 90 minutes |
| Actual start and end | Captured live, not reconstructed later | Sat 04:25 to 06:40 |
| Checkpoint or evidence | What proves the task is done | Record counts match; PO value by plant reconciled and signed |
| Go/no-go point | Marks tasks after which fallback changes | Yes, see fallback plan section 3 |
A runbook line built for rehearsal: every task can be timed and proven.
Measurement: capture timings as you go
Assign a timekeeper in the command center whose only job is to record actual start and end times and any waits. Time lost while a task waits for a person, an approval or a system lock is often larger than the task itself. After each mock, compare actual against plan, recalculate the critical path and look at total float: how many hours of contingency remain in the window.
- Freeze runbook versionVersion number and change log for this mock
- Take the data extractSame method and timing as go-live
- Execute with timekeepingActual start and end per task, waits noted
- Run checkpointsReconciliations and approvals done live
- Retrospective within 48 hoursIssues, timing variances, root causes
- Update runbookNew version with each lesson traced to its task ID
Turning rehearsal lessons into the final runbook
A rehearsal that does not change the runbook was wasted. Hold a retrospective within two days, while memories are fresh, and log every finding against a runbook task ID: missing steps, wrong sequence, wrong owner, unrealistic duration, unclear checkpoint. Then version the runbook and keep the change log. By the dress rehearsal, every lesson from mock 1 and mock 2 should be traceable to a change, or to a recorded decision not to change.
| Lesson type | Typical fix | Who signs the change |
|---|---|---|
| Missing step | Add task with owner, predecessors and checkpoint | Cutover manager |
| Duration overrun | Parallelize, pre-load static data earlier, or tune the load | Cutover manager with data and Basis leads |
| Approval delay | Name the approver and backup; schedule the approval slot | Process owner |
| Failed reconciliation | Fix the data or the mapping, then re-prove in the next mock | Data owner |
What would you do?
After mock 2, Contoso's timings show the cutover now fits the 60-hour window with only 1.5 hours to spare. Luis asks Priya what to recommend for the dress rehearsal. What is the best response?
- Rehearse on production-like infrastructure with full or near-full data volumes.
- Write the runbook as a test script: owners, predecessors, durations, checkpoints and go/no-go points.
- Capture actual timings live and report remaining contingency after every mock.
- Log every lesson against a runbook task ID and version the runbook so changes are traceable.
Check your understanding · not graded
Lesson check
1. Why do small data samples make poor rehearsals?
2. Which runbook column lets you calculate the critical path?
3. What should happen within about two days of each mock?
4. A task waited 50 minutes for an approver who was asleep. How should that appear in the rehearsal record?