A final master-data load brings an approved, controlled set of business reference records into the target ERP just before operations begin. Teams agree which records qualify, when the source is frozen or extracted, which mapping and dependency rules apply, how the final upload will be sequenced, and how business owners will validate the result. A completed technical job alone does not prove readiness for go-live.
Start with the business population
Final scope may include suppliers, customers, materials, cost centers or other approved master objects needed on day one. Data owners first decide which records are active, which duplicates need consolidation, which organizational extensions are required, and which sensitive fields need review. Exclusions must be justified and documented rather than silently disappearing from a file.
Decide the cutoff and ownership of changes
A source freeze or controlled update period stops untracked changes after the final extract. The runbook records source system, extraction time, approval, control totals and responsible owner. For urgent changes after cutoff, teams need an authorized delta process. Reusing a rehearsal extract without checking freshness can miss new suppliers or changed payment details.
Business and technical roles must agree
Business stewards sign off scope and data meaning; the migration team validates mappings, supported migration objects and technical processing; cutover leads manage timings and dependencies; Finance or relevant process owners reconcile acceptance counts and critical fields. Ownership must be named for every significant rejection and decision.
Loading order depends on actual business relationships
Master records rarely stand alone. Organizational structures, company codes, plants, purchasing organizations and agreed business-partner relationships may need to exist before dependent records are useful. The object sequence depends on the SAP edition, activated migration content and target design; do not prescribe one universal order for every project. The approved runbook identifies predecessors, responsible operators and acceptance gates.
Use rehearsal results to size the production window
Mock migrations test mapping rules, duplicate detection, missing mandatory values and target validation. Record duration and error categories, then include time to inspect rejected records and obtain business sign-off. SAP migration simulations can surface issues before a load; simulation does not itself establish that production data was successfully created. A final window should be planned with contingency, not merely the fastest trial runtime.
Example: one supplier, two source records
Two acquired business units may have separate records for the same supplier, with different bank details and payment terms. Blindly loading both can introduce duplicate identities or unsuitable organizational assignments. The business owner decides the approved target identity, verifies sensitive details through appropriate controls, documents how company-code and purchasing extensions should behave, and signs off the mapping before final extraction.
Reconcile what the target actually accepted
After the load, compare approved source counts with submitted, accepted and rejected records by migration object. Investigate exceptions, sample important attributes and verify that users can perform the required processes with the target master records. Count matching is necessary but not sufficient: a supplier can be present yet assigned to the wrong organization or hold the wrong payment terms. Record acceptance and residual business risk explicitly.
Separate master-data readiness from transaction continuity
Supplier, customer and material masters are reference records; open invoices, purchase orders and balances are transactional obligations. Their load sequences, migration options and reconciliation criteria can differ. A cutover plan must coordinate both without treating a successfully loaded supplier as evidence that outstanding supplier invoices were also transferred.
Consultant thinking: require a defensible sign-off
Ask who approved the source cutoff, mapping and object dependency sequence; what rejected and accepted counts were reconciled; which exceptions remain; and what contingency applies if a critical load fails. If the team cannot answer, final-load readiness is not established. Never promise rollback unless it has been designed and tested for that environment.
Related concepts: How Data Migration Mock Loads Are Tested, What a Mock Cutover Is, How Open Transactions Are Handled During Cutover, How a Cutover Plan Is Built, and the Consulting & ERP Projects hub.