Lesson 2 of 5
Measuring and optimizing load timing
9 min
The cutover window is the hardest constraint of go-live weekend. The window for loading Alternadores del Norte was 40 hours. Mock 2 took 61 hours. The only way to close a gap like that with confidence is to measure every step, find out where the time really goes, change something, and prove the change in the next rehearsal.
Measure every step, not just the loads
Teams usually time the load jobs and forget the rest. On go-live weekend, the clock runs through extraction, transformation, file transfers, simulation, loading, error correction, reconciliation, business validation, sign-off and handovers between shifts. Waiting is time too: a validation step that waits four hours for Dan to wake up is four hours on the critical path.
- Record planned and actual start and end for every runbook step, not just the total.
- Record waits separately: waiting for a predecessor, a person, a decision or a file.
- Record record counts per load so you can compute throughput (records per hour) and scale estimates.
- Record reruns: how often a step had to be repeated after errors and how long that took.
| Block of work | Mock 2 (hours) | Mock 3 (hours) | What changed |
|---|---|---|---|
| Extraction and transformation | 9 | 6 | Extraction programs tuned; transformation started per object as soon as its extract finished |
| Master data loads | 18 | 5 | Business partners and products pre-loaded before the freeze; only deltas at cutover |
| Open items and balances | 14 | 12 | Parallel jobs for large objects; open items split into smaller files |
| Error correction and reruns | 11 | 4 | Better cleansing at source; simulation run before each load |
| Reconciliation and validation | 9 | 8 | Validation checklists prepared; owners scheduled on shifts |
| Total elapsed | 61 | 38 | Within the 40-hour window, with 2 hours contingency |
Where the Alternadores del Norte load time went, Mock 2 versus Mock 3. Numbers are fictional; blocks overlap less than they add up because some run in parallel.
Find the critical path
Not every saving matters. The total elapsed time is set by the critical path: the longest chain of dependent steps. Shaving an hour off a step that runs in parallel with a longer one saves nothing. Luis drew the dependency chain from the runbook after Mock 2 and found that master data loads and error reruns sat on the critical path, while extraction of finance data did not.
- ExtractSource data selected and exported
- Business partnersPre-loaded before freeze; delta at cutover
- Products and dependent master dataBills of material, info records, conditions
- Open orders and stockOpen purchase and sales orders, inventory balances
- Financial open items and balancesAR, AP, G/L; clearing accounts must net to zero
- Validation and sign-offOwners validate; go/no-go checkpoint
Levers for faster loads
- Can the object be loaded before the cutover window?Yes → pre-load it before the freeze and load only deltas at cutover · No → next question
- Is the load itself slow for large volumes?Yes → use parallel jobs or split files, then remeasure · No → next question
- Is the time lost in errors and reruns?Yes → fix causes at source and simulate before each load · No → next question
- Is the time lost waiting for people or decisions?Yes → schedule owners on shifts, pre-agree checkpoints and thresholds · No → look at hardware sizing with Basis
In the SAP S/4HANA Migration Cockpit staging-table approach, the data transfer runs as background jobs. SAP documents (in Knowledge Base Article 3066336) that you can change the number of data transfer jobs for a migration project or object to improve performance; in the Migrate Your Data app this is done through the project's job management settings. More jobs only help if the system has free background work processes and the object can be processed in parallel, so agree the numbers with the Basis team and test them in a mock. Splitting very large files can also help, provided enough jobs are available to process them in parallel.
Contingency
Plan to finish early. A runbook that uses the entire window has no room for a failed load or a late file. Contoso set a rule: the timed plan must finish with at least 10% contingency left. The 38 hours of Mock 3 against a 40-hour window was accepted only after Grace and the steering committee also agreed a fallback: if open items overran, loading of a small number of low-volume objects could move to the first business day with a documented manual workaround.
What would you do?
After Mock 2, a developer proposes doubling all background jobs for every object to save time. Basis warns that the mock system has limited background work processes. What should Luis do?
- Measure planned and actual time for every runbook step, including waits and reruns.
- Only steps on the critical path change the total elapsed time.
- Levers: pre-load before freeze, parallel jobs, split files, fewer errors, scheduled owners.
- In the Migration Cockpit staging approach, the number of data transfer jobs can be adjusted; agree capacity with Basis.
- Prove every optimization in a rehearsal and keep contingency in the window.
Check your understanding · not graded
Lesson check
1. Which time is most often forgotten when timing a mock?
2. Why does shortening a step off the critical path not shorten the cutover?
3. When do more Migration Cockpit data transfer jobs help?
4. What should happen before an optimization is relied on at go-live?