Lesson 1 of 5
Giving every mock a purpose
9 min
A mock load is a rehearsal of the data migration into a non-production system. Most programs run several. The mistake many make is to run them as repeats: the same thing three times, a little better each time. Good programs run them as a progression, where each mock has a different main question to answer and cannot start until the previous one has answered its question.
Contoso Motor Co. moved its own ECC system to SAP S/4HANA Cloud Private Edition by system conversion, rehearsed with mock conversions rather than mock loads. Right after it, Contoso acquired Alternadores del Norte S.A. de C.V. in Monterrey, Mexico, and that company's data has to be loaded from its non-SAP legacy ERP into the converted system as new company code 1910 (MXN) with plant 1910 Monterrey. For this Wave 2 load, Contoso planned three mocks and a dress rehearsal before company code 1910 goes live. Luis, the cutover manager, owns the schedule and the runbook. Priya, the test lead, owns validation and the defect log. Dan and Maria, as data owners for finance and order-to-cash, sign off the results of their objects.
- Mock 1Can it load?Main objects, partial data; prove the sequence, templates and mapping rules work end to end
- Mock 2Is it right at full volume?All objects, full data; first full reconciliation and business validation
- Mock 3Does it fit the window?Full cutover sequence against the clock, with the final runbook and frozen rules
- Dress rehearsalCan we do it exactly as on the day?Go-live simulation: same people, same shifts, same checkpoints and go/no-go calls
- Go-liveFinal loadProduction load, validation and sign-off
Entry and exit criteria
Write down, before each mock, what must be true to start it and what must be true to call it passed. Entry criteria stop a mock from running on a broken foundation. Exit criteria turn a pile of observations into a clear decision: move on, or repeat.
| Mock | Entry criteria | Exit criteria (examples) |
|---|---|---|
| Mock 1 | Target configuration transported to the mock system; mapping specifications drafted for core objects; extraction programs ready | Every in-scope object has loaded at least once; sequence gaps documented; error causes classified |
| Mock 2 | Mapping specifications approved by data owners; Mock 1 actions closed or accepted; fresh full extract | All objects loaded at full volume; error rate per object below the agreed threshold; open receivables reconciled by company code |
| Mock 3 | Rules frozen; runbook version issued; Mock 2 defects fixed and retested | Elapsed time within the cutover window with contingency; reconciliation complete; owners have signed sample validation |
| Dress rehearsal | Mock 3 passed; go-live staffing confirmed; cutover plan baselined | Runbook executed without unplanned steps; go/no-go checkpoints held on time; sign-offs captured as on go-live |
Entry and exit criteria per mock. Contoso's thresholds were agreed by Priya with the data owners.
Make each mock more realistic than the last
Realism covers more than data. It means a target system built with the same transports production will receive, a fresh extract from the source, the real cutover team on their real shifts, and validation done by the business owners who will do it on go-live weekend. A mock run by the migration specialists alone, at their own pace, proves the tools work; it does not prove the organization can do it under pressure.
Mocks also feed testing
A good mock produces a realistic data set. Contoso planned the later Wave 2 integration test cycle and user acceptance testing on data from Mock 2 and Mock 3, so that order-to-cash scenarios for company code 1910 ran on Alternadores del Norte's migrated fleet customers, such as Flotillas Monterrey S.A. de C.V., and migrated open orders, not on a handful of records typed in by testers. Those test cycles regularly find migration defects that reconciliation missed, such as a migrated open order that cannot be delivered because a field mapped to the wrong shipping point.
- Mock loadFull data set loaded and reconciled
- Refresh test clientMock result used as the data base for test client 100 in CMQ
- Integration and UATProcesses run on migrated customers, products and open items
- Migration defectsProcess failures traced back to mapping or source data
- Next mockFixes proven in the following rehearsal
What would you do?
The day before Mock 2, three of the Alternadores del Norte mapping specifications (supplier bank details, pricing conditions and open purchase orders) are still not approved. Grace asks whether Mock 2 should go ahead. What should Priya recommend?
- Run mocks as a progression: can it load, is it right at volume, does it fit the window, can we do it exactly as on the day.
- Give each mock written entry and exit criteria that are measurable and owned.
- Increase volume first, then realism: production-like system, fresh extract, real team, real shifts.
- Use later mock results as test data for integration and acceptance testing.
Check your understanding · not graded
Lesson check
1. What is the main question of a timed rehearsal such as Mock 3 of the Alternadores del Norte load?
2. What is the purpose of entry criteria for a mock?
3. Which is a good exit criterion?
4. What makes a dress rehearsal different from Mock 3?