SAP S/4HANA data migration is complete only when the business can prove that required data arrived correctly, balances reconcile, open processes continue and exceptions are owned. A technically successful load is not sufficient evidence for go-live.
Direct answer
A production-ready migration cycle needs six evidence groups: scope, source quality, mapping, load control, reconciliation and cutover authorization. Each must have an accountable owner and acceptance threshold before the final migration window.
1. Scope and retention
- List migration objects, source systems and target owners.
- Separate master data, balances, open items, active documents and historical information.
- Record legal, tax, audit and operational retention obligations.
- Define what remains in an archive or legacy-access solution.
- Confirm whether the selected transition approach changes the available migration tooling.
SAP notes that its Migration Cockpit is the recommended tool for standard business-data migration in a new implementation, while selective data transition commonly uses specialist tools and services for broader historical scope. See SAP’s Selective Data Transition guidance.
2. Source profiling and ownership
Measure nulls, duplicates, invalid values, orphaned references, code-set inconsistency, inactive records and cross-system conflicts. Do not treat cleansing as an IT-only task. The business owner must decide the correct value when technical rules cannot.
For each critical field, record:
- source definition and owner;
- target definition and owner;
- transformation or default rule;
- allowed-value and completeness threshold;
- privacy classification;
- reconciliation method.
3. Mapping and transformation control
Version mapping rules in a controlled repository. Every change should identify the reason, approver, affected objects and required regression tests. Test transformations on boundary conditions rather than only representative happy-path records.
Useful mapping tests include code conversions, units and currencies, date handling, organizational assignments, partner relationships, document status, blocked records and records that span the cutover boundary.
4. Mock-load evidence
Run repeated migration rehearsals with controlled input snapshots. For each load, retain counts, rejected records, runtime, throughput, transformation version, target validation results and defects. Compare runs so the team can tell whether quality is improving.
| Evidence | Example acceptance question |
|---|---|
| Record control totals | Did every in-scope source record load, reject with a reason or receive an approved exclusion? |
| Referential integrity | Do dependent records resolve to the correct target objects? |
| Financial reconciliation | Do agreed ledgers, balances and open items match within approved tolerances? |
| Process continuity | Can active orders, deliveries, invoices and service processes continue? |
| Security validation | Are sensitive records restricted to the correct target roles? |
| Performance | Can the cycle finish inside the cutover window with contingency time? |
5. Reconciliation by business outcome
Reconciliation must combine technical counts with business meaning. A matching row count can still hide incorrect company codes, currencies, dates or status. Build controls at three levels:
- technical controls — counts, checksums, rejects and duplicates;
- financial controls — balances, open items and document relationships; and
- operational controls — process status, inventory, customers, suppliers and active work.
Each exception needs an owner, severity, root cause, resolution and retest result. The sign-off pack should distinguish corrected defects, accepted variances and unresolved blockers.
6. Cutover and rollback evidence
Before authorization, prove the extraction freeze, final delta method, job sequence, handoffs, verification window, rollback boundary and communication path. A rollback plan must state what can actually be reversed after business transactions begin in the target.
Set a stop condition for load duration, unreconciled value, critical rejects, failed integrations and unavailable approvers. If a threshold is exceeded, escalation should be procedural rather than improvised.
Practical lab: rehearse and reconcile
In the S/4HANA Readiness Lab, participants identify data and integration dependencies before selecting a transition path. The full SAP migration program extends this into a synthetic migration cycle, defect log, reconciliation pack and cutover defense.
Frequently asked questions
Who signs data reconciliation?
Technical teams produce evidence, but accountable business owners should approve business correctness. Finance, operations, security and audit roles may each own different acceptance criteria.
How many mock migrations are required?
There is no universal number. Continue until the team meets quality and duration thresholds consistently, has rehearsed failure handling and can explain remaining variance. The count is an assumption requiring project-specific validation.
Can reconciliation be performed after go-live?
Some validation continues during stabilization, but critical financial, master-data and process-continuity evidence should be available before authorizing production use.
View the complete SAP S/4HANA migration curriculum or enquire about training.