Iterations and runtime learning

Nobody gets a conversion right the first time, and nobody should try to in production. A conversion program converts copies of production several times. Each run finds errors, produces fixes and measures durations. The goal of the later runs is not to discover anything new but to repeat a known procedure and prove that its runtime fits the window.

A distributed landscape for conversion

SAP's conversion guide recommends a distributed approach: set up a second development system as a copy of the original, perform and test all conversion phases there, and collect the necessary changes, including those that can only be made after conversion such as finance Customizing, in transport requests. Those transports are then handed to SUM and applied during later conversions, including production. That way, the time-consuming discovery happens once, and production gets a short, repeatable run.

This also creates a dual landscape: ED1, EQ1 and EP1 keep supporting the business on ECC while the project builds CMD, CMQ and CMP. Every production fix made in ECC must be retrofitted into the project line, and every retrofit is a change that needs testing. Track it as part of the run plan, not as an afterthought.

Measure everything, then use the measurements

• Phase durations from SUM. SUM records how long its phases took. Keep the logs and the duration data from each run; they are the evidence for the downtime budget.
• Migration durations for DMO. SAP's DMO guidance says to provide the table migration duration file from a previous run, so SUM can optimize table splitting in the next one.
• Manual steps. Time every manual activity in the runbook, with who did it and what waited for it.
• Resource usage. CPU, memory, I/O and network during the run show whether more parallel processes would help or hurt.
• Errors and fixes. Every stop, its cause and its fix, so the next run avoids it.

Two cautions. First, compare like with like: a run on smaller hardware or an old copy of production does not predict the production run. Ask SAP ECS which infrastructure the mock target used and make the dress rehearsal as production-like as possible. Second, change one big thing at a time. If mock 2 adds data archiving, more parallel processes and a new SUM support package at once, nobody can say which change helped, or which one caused the new error.

The output of all these runs is a runbook: every step from ramp-down to ramp-up, with owner, predecessor, planned duration, measured duration from the last run, and the check that proves the step is done. Luis owns the runbook for the cutover weekend; Sam owns the technical steps in it, including the hand-offs to and from SAP ECS. A runbook that only lists SUM phases is not enough, because most delays in a rehearsal happen between steps, while one team waits for another.