Lesson 4 of 5
Simulating and analyzing messages
11 min
Simulation is the cheapest test in data migration. The cockpit runs each record through the same SAP interface and checks that a real migration would use, and then rolls everything back, so no business data is created. You get the full list of errors and warnings a real load would produce, while the target system stays clean.
Why simulate before migrating
- It finds missing configuration (payment terms, tax codes, valuation classes) before data is created against it.
- It finds invalid values and broken references (a supplier that does not exist yet, a plant that is not mapped).
- It shows the volume of problems per object, which tells Luis whether the cutover window is realistic.
- It avoids partial loads that have to be cleaned up or reversed, which is far more expensive than fixing data before migration.
- Start simulationFor the whole object or selected records; runs as background jobs
- Checks runEach record goes through the standard interface and application checks
- RollbackNothing is saved; the target system is unchanged
- MessagesErrors, warnings and successes per record, available in the app
- DecideFix causes and simulate again, or proceed to migration
Reading the messages
Messages are listed per record and per run. Do not read them one by one in record order. Group them by message text and count them: thirty different messages often have three causes. For each group, identify the cause type and the owner.
| Message group (example) | Records | Cause type | Owner and action |
|---|---|---|---|
| Reconciliation account for suppliers not created in company code 1910 | 212 | Missing configuration | Finance consultant creates the G/L account in 1910 and transports the settings |
| Supplier not found (info record) | 96 | Missing reference / sequence | Load Supplier object first; resimulate |
| Tax number format invalid for country MX | 41 | Invalid source data | Supplier data owner cleanses in the legacy ERP |
| Field "Purchasing group" is required | 18 | Mapping or fixed value missing | Add fixed value with owner approval |
| Warning: bank account check digit could not be verified | 7 | Warning; review | Data owner confirms or corrects |
Grouping Contoso's simulation messages for the Supplier and info record objects. Message texts are paraphrased.
- Is it an error that blocks the record?Yes → must be fixed before migration · No → next question
- Is it a warning that changes business meaning (bank, tax, price)?Yes → data owner reviews before migration · No → next question
- Is it a warning that repeats in every mock without consequence?Yes → document it as accepted with the owner · No → next question
- Is it an information message?Yes → no action · No → reclassify with the functional consultant
What simulation cannot tell you
A clean simulation means every record would be created. It does not mean the records are right. A supplier with the wrong payment terms mapping simulates perfectly. A product with the wrong valuation class simulates perfectly if that class exists. Simulation checks technical and configuration validity; correctness is proven by reconciliation and business validation after migration, by the data owners.
Runtime and background jobs
Simulation and migration run as background jobs. For large objects, the project settings let you allow more than one job per object so records are processed in parallel; the useful number depends on the free background processes in the target system and on what else is running. More jobs on one object usually help more than many objects running at once, which compete for the same processes. Simulation takes roughly as long as migration, because it does the same work before rolling back, so time both and feed the numbers into the cutover plan.
Contoso tracks simulation results per object and per mock in the same table it uses for load errors: records simulated, records with errors, error rate and the top three message groups. Priya uses the trend to judge whether cleansing and configuration are improving, and Luis uses the job runtime to refine the cutover plan.
What would you do?
The Supplier object simulates with zero errors in Mock 2. The migration analyst wants to skip validation after migration to save a day, because "simulation proved the data is fine". What should Priya decide?
- Simulation runs the standard checks and rolls back; no data is created.
- Group messages by text and cause; assign owners for configuration, sequence, data and mapping causes.
- Simulate small slices first for new objects.
- A clean simulation is necessary but not sufficient; validation proves correctness.
Check your understanding · not graded
Lesson check
1. Why simulate before migrating?
2. 212 suppliers fail because their reconciliation account is not created in company code 1910. What is the cause type?
3. What is the best way to analyze many simulation messages?
4. What does a clean simulation not prove?