Lesson 4 of 5
Documenting and resolving differences
8 min
Every mock load produces differences. That is the purpose of mocks. What separates a well-run migration from a stressful one is how differences are recorded, classified, owned and closed. A difference that lives only in someone's email is a difference that comes back on go-live weekend.
Recording a difference
Keep one difference log per migration cycle, shared by the migration team and the business validators. In projects that use SAP Cloud ALM or SAP Solution Manager, differences that need a fix are often raised as defects there, linked to the migration object. Whatever the tool, each entry needs enough detail for someone else to reproduce it.
| Field | Contoso example |
|---|---|
| ID and object | DIF-2-014, Customers |
| Check that found it | Field profile: payment terms |
| Expected vs actual | Legacy N30 on 1,100 customers; SAP 0001 on 700 and 0002 on 400 |
| Records affected | 400; list attached with legacy and SAP numbers |
| Business impact | Due dates 15 days early on AR open items; dunning would start too soon |
| Cause category | Mapping |
| Owner and due date | Migration consultant for the mapping; Maria to re-validate; before mock 3 |
| Status | Open, fixed, re-validated, accepted as exception, or closed |
A difference record with enough detail to act on.
Classifying by cause
The cause decides who fixes the difference and where. Classify each one before assigning it.
- Is the record wrong or missing in the legacy system itself?Yes → source data: business data owner cleanses legacy before the next extract · No → next question
- Was it extracted wrongly or filtered out?Yes → extraction: migration team fixes the extract rule · No → next question
- Was a value translated wrongly?Yes → mapping or transformation: fix the mapping task or rule, re-validate the affected field · No → next question
- Did SAP S/4HANA reject or default a value?Yes → target configuration: configure the missing value or adjust the design · No → next question
- Is the "difference" a deliberate change?Yes → expected difference: document the rule, adjust the expected figure · No → investigate further with the migration team
Expected differences are real and common: legacy customers merged into one business partner, inactive products excluded, a new chart of accounts that maps three legacy accounts into one. They are not errors, but they must be written down, approved by the data owner and used to adjust the expected counts and totals. Otherwise every reviewer rediscovers them.
Fixing: in the source, the rule or the target
Fix the cause, not the symptom. If a mapping is wrong, correct the mapping so the next mock and the production load are right. Correcting 400 customers by hand in the test client fixes nothing for go-live. Manual correction in the target is acceptable only for a documented handful of records in the final load, approved by the data owner and logged, with a check that dependent objects are corrected too.
Severity and closure
- Critical: blocks a business process or misstates financials, for example wrong bank details or balances not tying out. Must be fixed before acceptance.
- Major: wrong data that users would notice and work around, for example wrong sales office on 50 customers. Fix before go-live, or accept with a dated correction plan.
- Minor: cosmetic or rarely used fields. Can be accepted as an exception with an owner.
Watching the trend across mocks
Count differences per object and per cause after each mock. A healthy migration shows the number of open differences falling sharply from mock 1 to mock 3, with source-data and mapping causes disappearing first. If mock 3 still produces new mapping differences, the mapping has not stabilized and the production load is at risk. Grace, as PMO lead, can use this trend as an early warning long before the go/no-go meeting.
When a fix lands, re-validate more than the one field. A corrected mapping for payment terms might have been implemented by changing a rule that other fields also use. Repeat the field profile and the sample for the object, not only the original failing check.
A difference is closed only when the fix has been re-validated in a later load, or when the data owner has formally accepted it as an exception. "Fixed" by the migration team is not closed; the business validator confirms it.
- FoundValidator records the check, expected vs actual, records and impact
- ClassifiedCause category and severity agreed with the migration team
- FixedOwner corrects source data, extract, mapping or configuration
- Re-validatedValidator repeats the check in the next load and confirms
- Closed or acceptedClosed with evidence, or accepted as an exception by the data owner
What would you do?
In mock 3, Contoso's inventory value in plant 1720 is 31,200 USD higher in SAP S/4HANA than in legacy. Quantities match. The migration consultant suggests posting a manual adjustment so the totals agree. What should Dan say?
- Record every difference with the check, expected vs actual, records affected, impact, cause, owner and status.
- Classify by cause: source data, extraction, mapping, target configuration, or expected difference.
- Fix the cause so the next load is right; avoid manual corrections in the target.
- Expected differences must be documented and approved, and used to adjust expected figures.
- Close a difference only after re-validation or formal acceptance by the data owner.
Check your understanding · not graded
Lesson check
1. Legacy customers were deliberately merged into fewer business partners. How should this be treated?
2. A value is translated incorrectly from legacy to SAP. What is the cause category?
3. When is a difference closed?
4. Why fix a mapping rule instead of correcting records by hand in the test client?