Lesson 1 of 5
Migration as a test object
11 min
Listen to this lesson
Most SAP test plans test processes: can Contoso Motor Co. take an order, ship it, bill it and collect the cash? Data migration needs its own tests, because a process can work perfectly on test data and still fail on go-live morning when it meets migrated data. A customer migrated without a tax classification cannot be invoiced; an open purchase order migrated with the wrong price creates a variance at goods receipt; an open receivable migrated to the wrong customer is chased from the wrong company. The migrated data is a product the program delivers, and like any product it needs requirements, tests, defects and sign-off.
This course assumes the basics from the data migration fundamentals course: migration objects, load sequence, data owners, mock loads and the SAP S/4HANA Migration Cockpit. Here we focus on proving that the data is right. Our running example is Wave 2 of Contoso's program. Contoso's own move to SAP S/4HANA was a system conversion that kept its data in place; right after it, Contoso acquired Alternadores del Norte S.A. de C.V. in Monterrey, Mexico, and is loading that company's data from its non-SAP legacy ERP into the converted system as new company code 1910 (MXN) with plant 1910 Monterrey.
Four test levels for migration
| Level | Question it answers | Who | Alternadores del Norte example |
|---|---|---|---|
| Rule and mapping | Does each rule transform data as specified? | Migration specialist and tester | Legacy payment term CR30 becomes 0004; inactive customers excluded |
| Load | Did every in-scope record load, and are rejects explained? | Migration specialist | 1,943 customers loaded from 1,946 in scope; the 3 merged duplicates explained |
| Reconciliation | Do counts and values match across stages? | Tester with migration specialist | Open AR in company code 1910 equals the legacy ERP by currency |
| Business validation | Is the data right and usable? | Data owners and key users | Maria delivers and bills a migrated open order for Flotillas Monterrey S.A. de C.V. |
What each migration test level proves.
Why each level is needed
Each level catches problems the others miss. A load can succeed with 100% of records and still be wrong if a mapping rule is wrong; reconciliation of totals can match while individual customers have swapped balances; business validation can confirm samples while a whole category is missing. Only the combination gives confidence. Equally, none of these is a substitute for the process tests: integration and acceptance testing on migrated data is where the levels meet the rest of the program.
Requirements for data
To test, you need expected results. For migration they come from three places: the mapping specification (what each rule should do), the source system (what counts and totals should arrive) and the data owners (what "right" means for the business). If any of these is missing for an object, write that down as a gap before testing starts; a migration object without an approved specification cannot be signed off.
| Source of expected results | What it tells you | Test level it feeds | Alternadores del Norte example |
|---|---|---|---|
| Mapping specification | What each selection, mapping and transformation rule should do | Rule and mapping tests | Legacy payment term CR30 becomes 0004 |
| Source system | Which counts and totals should arrive in the target | Load and reconciliation | 1,946 in-scope customers (of 3,180 in the legacy ERP) and MXN 48,615,320.40 open AR as of the extract key date |
| Data owners | What "right" and "usable" mean for the business | Business validation | Maria confirms Flotillas Monterrey S.A. de C.V. can be billed from sales area 1910 / 10 / 00 |
What would you do?
After Mock 2 of the Alternadores del Norte load, the migration specialist reports: "All 26 objects loaded with fewer than 1% errors. Migration is green." Priya is asked whether migration testing is complete for Mock 2. What should she answer?
The key date and the moving source
Source data keeps changing while the old system is live. Every mock therefore needs a defined extract key date and time, and every reconciliation compares the target with the source as of that moment. On go-live weekend, the old system is closed for posting before the final extract so that nothing changes underneath the load. In mocks, where the source keeps running, record the key date carefully; otherwise perfectly correct loads appear to have differences simply because invoices were posted in the legacy ERP after the extract.
- Before the mockKey date agreedExtract date and time fixed and written into the mock plan
- Key dateSource snapshotCounts and totals captured from the legacy ERP at exactly that moment
- ExtractData pulledGo-live only: the legacy ERP closed for posting first so nothing moves underneath
- LoadObjects loadedSAP S/4HANA loaded in the agreed sequence
- ReconcileCompare as of key dateTarget checked against the snapshot, not against today's live source
Make sure the migration test team is staffed for this. At Contoso, Priya assigns one tester per value stream to migration testing for each mock, working alongside the migration specialist, with Maria and Dan scheduled for validation slots. Migration testing that depends on whoever happens to be free fails at exactly the moment it is needed.
- Migrated data is a product: it needs requirements, tests, defects and sign-off.
- Four levels: rule and mapping, load, reconciliation, business validation.
- Each level catches different problems; only together do they give confidence.
- Expected results come from the mapping specification, the source system and the data owners.
Check your understanding · not graded
Lesson check
1. Which test level answers "is the data right and usable?"
2. Why is a 100% successful load not enough?
3. Where do expected results for migration tests come from?
4. Why track migration defects in the same tool as process defects?