Lesson 1 of 6
Conversion iterations
9 min
Listen to this lesson
A system conversion is not one event. It is the same technical procedure run several times on different systems, each run with a different purpose. The test strategy should say, for each iteration, what question it must answer and what evidence it must produce. Run every iteration as "convert and see" and you reach the production weekend with plenty of activity and very little proof.
Contoso's path
Contoso converts SAP ECC 6.0 EHP 8 to SAP S/4HANA 2025 Private Edition under RISE. The legacy landscape is ED1, EQ1 and EP1; the target is CMD, CMQ and CMP. SAP's conversion guide recommends doing a test conversion early in a dedicated system and collecting every required change in transport requests, including those that can only be made after the conversion, such as finance customizing. Those transports are then handed to the Software Update Manager (SUM) for the later conversions.
- ExploreSandbox conversionCopy of EP1; find blockers, learn the procedure, first finance migration
- RealizeCMD from ED1Development converted; custom code adapted; transports collected
- RealizeCMQ from EQ1Quality converted with transports; first integration test cycle
- DeployMock conversions 1 and 2Fresh copies of EP1 converted with the runbook; CMQ rebuilt from them for SIT and UAT
- DeployDress rehearsalFinal mock, exactly as planned for production, timed against the 60-hour window
- Go-live weekendCMP from EP1Friday 18:00 to Monday 06:00
A test goal for each iteration
| Iteration | Test goal | Key evidence |
|---|---|---|
| Sandbox | Can we convert at all, and what breaks? | SUM and SI-check results, finance migration errors, list of failed programs |
| CMD | Is custom code adapted and unit-tested? | ATC results after conversion, ABAP Unit runs, developer smoke tests |
| CMQ (first) | Do processes and interfaces work on converted test data? | Functional regression and first integration cycle results |
| Mock 1 | Does the runbook work on production data, and how long does it take? | Step runtimes, reconciliation results, defect list |
| Mock 2 | Are fixes effective and is the timeline stable? | Runtimes against target, full reconciliation, SIT and UAT on converted data |
| Dress rehearsal | Can we do it exactly as planned, inside the window, with go/no-go? | Timed runbook, reconciliation sign-off, rehearsal of rollback decision |
| Production | Is the converted production system right? | Technical checks, reconciliation, business verification, sign-off |
Each iteration answers a different question. If an iteration has no question, it is wasted.
Two principles hold the strategy together. First, the same checks run in every iteration, so results can be compared: a reconciliation that passes in Mock 2 means something only if the same reconciliation ran in Mock 1 and the sandbox. Second, production data appears as early as possible. Many conversion defects come from old, inconsistent or unusual data that test systems don't contain; that is why the sandbox and the mocks start from copies of EP1.
What would you do?
Luis proposes skipping reconciliation in Mock 1 "because the runbook is still changing" and doing it only in Mock 2. What should Priya say?
- Each conversion iteration answers a different test question; write it down before the run.
- Run the same checks in every iteration so results can be compared.
- Use production copies early (sandbox, mocks) because many conversion defects come from data.
- Freeze target stack, runbook and transports before the dress rehearsal; rerun checks for approved changes.
Check your understanding · not graded
Lesson check
1. What is the main test goal of the sandbox conversion?
2. Why should the same checks run in every iteration?
3. Which iteration should be run exactly as planned for production and timed against the window?
4. Why use production copies for the sandbox and mocks?