Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Planning performance for large volumes

10 min

Direct transfer removes file handling, but not volume. Selecting and migrating hundreds of thousands of records takes time in both systems, and the final load has to fit the Wave 2 cutover window, the weekend when the Monterrey business switches systems. Performance planning starts in the first mock, not the week before go-live.

Where the time goes

PhaseRuns whereDrivers
SelectionSource (reading) and target (storing selection results)Volume in the source, selection complexity, source system load
MappingTarget, mostly manualNumber of new values; prepared mapping files reduce it
SimulationTargetVolume, application checks per record, parallel jobs
MigrationTargetSame as simulation, plus database writes and follow-on updates
ValidationPeople and reportsNumber of checks, availability of data owners

The phases of a direct transfer and what drives their runtime.

Levers you control

  • Reduce volume: archive or block what should not move, so it is never selected. The fastest record is the one you do not migrate.
  • Parallelize: the cockpit runs work as background jobs, and the project's job settings allow several jobs per object. More jobs help only if free background processes exist; flooding the queue with many objects at once often makes things slower.
  • Sequence smartly: run independent objects in parallel streams and keep the dependency chain short. The longest chain is the critical path of the cutover.
  • Pre-load stable master data: load master data that changes rarely before the cutover weekend, and plan how changes after the pre-load are handled, because a reload is not a delta.
  • Apply SAP's performance guidance: SAP publishes a knowledge base article with performance tips for direct transfer; check it for your release.
  1. Cutover -3 weeksPre-loadBanks, business partners, products: selected, simulated and migrated
  2. Cutover -3 weeks to -1 dayChange controlMaster data changes in ECC tracked and replayed in SAP S/4HANA by agreed procedure
  3. Cutover day 1Freeze and selectECC posting stops; open POs and open items selected
  4. Cutover day 1–2Simulate and migrateOpen items migrated in dependency order with parallel jobs
  5. Cutover day 2ValidateCounts and values reconciled; owners sign
What-if plan for spreading Wave 2 load volume across the cutover.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-202
Low volume, low changeLoad any time; e.g. banks
High volume, low changePre-load before cutover; e.g. products
Low volume, high changeLoad in the cutover window; quick
High volume, high changeCritical path; tune jobs; e.g. open items and open POs
Placing objects in the cutover plan by volume and change rate.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-202

Load on the source system

Selection reads the source. For mocks that is usually a copy, but the final load reads the production source, during the freeze, while its users are locked out. Agree with the source Basis team when selection may run, how many parallel reads the source can take, and who watches it. In the what-if, Alternadores' ECC is frozen on the Friday evening of the Wave 2 cutover, selection for open items starts immediately, and the source stays available read-only until validation is signed, in case a record has to be checked or reselected.

Measure every mock

For each object and phase, record start, end, record count, number of jobs and errors. After two mocks you have a throughput figure per object (records per hour at a given job count) and can predict the final load. In the what-if, Mock 2 showed open purchase orders as the slowest object at the planned job count; the team raised the job count for that object, moved two independent objects out of its time slot, and Mock 3 confirmed the improvement.

What would you do?

In the what-if, Mock 2's total direct transfer time is 38 hours against a 30-hour Wave 2 cutover window. Which change should the team try first?

Key points
  • Runtime comes from selection, mapping, simulation, migration and validation; measure each.
  • Reduce volume first, then parallelize with job settings within available background processes.
  • Pre-load stable master data and plan how later changes are handled.
  • Use mock timings to predict the final load and tune the critical path.

Check your understanding · not graded

Lesson check

  1. 1. What is the most effective first lever for performance?

  2. 2. Why can starting many objects at once slow things down?

  3. 3. Which objects are good candidates for pre-loading before cutover?

  4. 4. What should be measured in each mock for performance planning?