Lesson 5 of 5
Correcting errors and iterating
11 min
No first load is clean. The skill in migration is not avoiding errors; it is correcting them at the right place, quickly, without creating new ones, and leaving a trail that shows what was changed and why. This lesson describes the correction loop Contoso uses in every mock.
- MigrateSuccessful records are created; failed records keep their error status
- Group errorsBy message and cause, as in simulation
- Fix at the source of the causeConfiguration, mapping, sequence or source data
- Correct the staging dataUpload a corrected file or correct the staging records
- ReprocessPrepare, map, simulate and migrate again; only open records are processed
- RecordLog the cause and fix so the next mock starts with it
Fix at the right place
| Cause | Fix in | Contoso example |
|---|---|---|
| Missing or wrong configuration | Development system, transported to the migration target | Supplier reconciliation account created in company code 1910 and transported |
| Wrong or missing mapping | Mapping specification, then the project's mapping tasks | Old unit PCE now mapped to PC |
| Wrong load sequence | Run book and project setup | Info records moved after suppliers |
| Wrong source data | Source system (cleansing) or the extraction rules, then new staging data | Supplier tax numbers corrected in the legacy ERP |
| Transformation logic error | ETL tooling, versioned and retested | Address line split rule fixed |
Where each type of error is fixed.
The tempting shortcut is to fix the data in the staging table or file and move on. That works for this mock and fails in the next one, because the next extract brings the same wrong data. Correct the staging data to finish the current run if you must, but always also fix the cause in the source, the rules or the configuration, and record it.
Reprocessing in the cockpit
After corrections, reprocess the object. Records already migrated successfully are not created again; records with errors are processed again. Depending on what changed, you may need to repeat preparation (if staging data changed) and confirm new mapping tasks (if new source values appeared) before simulating and migrating. In newer releases the app lets you display and correct values in the staging table records directly; whichever way you correct, keep the corrected source file or extract as evidence.
- Run 19,000 products8,140 migrated, 860 errors (9.6%), three causes
- FixCauses resolvedValuation class configuration transported; unit mapping added; 120 records cleansed in the legacy ERP
- Run 2860 reprocessed842 migrated, 18 errors
- Run 318 reprocessed after owner decisions15 migrated, 3 excluded with owner approval as obsolete
- CloseObject completeCounts reconciled: 8,997 migrated + 3 excluded = 9,000 extracted
Keep the books balanced
Every record extracted must end up in exactly one bucket: migrated, failed with an open defect, or excluded with an owner's approval. The counts must add up. This simple equation is the start of every object reconciliation, and it catches records that silently disappeared between extraction and the staging tables.
Evidence from the cockpit
For each object and run, keep the counts (records in staging, migrated, with errors), the message list exported from the app, the mapping values used and the source file or extract version. Together with the corrected-cause log, these are the evidence Priya attaches to the mock's migration test results. They also answer the question auditors ask after go-live: how do you know every supplier and every open item came across?
What would you do?
In Mock 3, 40 open purchase orders fail because their supplier is blocked for purchasing in SAP S/4HANA. The migration analyst unblocks the suppliers in the target, reprocesses, and the POs migrate. What is missing?
- Correct errors where their cause lives: configuration, mapping, sequence, source data or ETL logic.
- Reprocessing handles only open records; repeat preparation and mapping when data or values changed.
- Every extracted record ends as migrated, failed with a defect, or excluded with approval; counts must add up.
- Record every cause and fix so the next mock starts better.
Check your understanding · not graded
Lesson check
1. Where should a "payment terms not defined" error be fixed?
2. What happens to successfully migrated records when an object is reprocessed?
3. Which equation should hold for every object at the end of a mock?
4. Why is fixing only the staging file a poor long-term fix?