Lesson 2 of 5
Testing rules and mappings
12 min
Listen to this lesson
Rule and mapping tests check that each selection, transformation and value mapping rule behaves as the specification says, before full-volume loads hide individual mistakes among thousands of records. They are the cheapest migration tests and the ones most often skipped.
What to test
- Selection rules: the right records are in and the right ones are out. Example: "customers with an open item or a sale in the last 24 months" includes a customer whose only activity was 23 months ago and excludes one at 25 months.
- Value mappings: every source value maps to a valid target value, and unmapped values are caught. Example: each legacy payment term code maps to an SAP S/4HANA payment term.
- Transformations: derived and restructured fields are right. Example: legacy customers and their contact data become business partners with the right roles.
- Defaults and enrichment: new or newly required fields are filled as specified. Example: a new customer classification defaulted from the sales district.
- Exclusions and duplicates: duplicates are merged per the agreed rule; excluded records are listed, not silently lost.
Targeted data sets
Do not test rules with random records. Build a small, deliberate test set per object that hits every branch of every rule: boundary values, each value in each mapping table, empty and invalid inputs, special cases such as one-time customers or blocked suppliers. A few dozen well-chosen records can exercise every rule; ten thousand random ones may never touch the edge cases.
| Random records | Targeted test set | |
|---|---|---|
| Size | Thousands | A few dozen per object |
| Edge cases | Hit by chance, often never | Every branch, boundary and mapping value on purpose |
| Expected result | Hard to state per record | Written down for each record before the run |
| Alternadores del Norte example | Any 1,000 of the 3,180 legacy customers | Customers inactive 23 and 25 months, one unknown payment term, three duplicate Flotillas Monterrey S.A. de C.V. records |
| Rule | Test records | Expected result |
|---|---|---|
| Customers active in last 24 months | Last activity 23 months ago; 25 months ago; open item only | Included; excluded; included |
| Payment term mapping | One customer per legacy payment term code, plus one with an unknown code | Each maps to the agreed S/4HANA term; unknown code reported, not defaulted |
| Duplicate merge (same tax number) | Three Flotillas Monterrey S.A. de C.V. records with one tax number | One business partner; addresses kept as agreed by Maria |
| Supplier bank details | A local rotor supplier with two bank accounts | Both migrated; the primary flagged as specified |
| Product plant data | ADN-200 in plant 1910 Monterrey | Plant view created for plant 1910 with correct storage location and MRP data |
Targeted test records for Alternadores del Norte's customer, supplier and product rules.
Testing in the transformation stage and in the target
Where data is transformed outside SAP (in a staging area, before it reaches the Migration Cockpit's staging tables), compare source and transformed records for the test set field by field. Then load the test set and check the target: display the business partner, product or open item in SAP S/4HANA and compare with the expected result. The cockpit's simulation step is useful here too: it checks values against the target system's configuration and reports errors without creating data, so invalid mappings appear before anything is posted.
- Is the source value in the mapping table?Yes → map it and check the target value · No → next question
- Does the approved specification define a default for it?Yes → apply the default and log each record · No → next question
- Was the record reported for a data owner decision?Yes → rule works as designed · No → raise a mapping defect for the silent default
Recording results
Store rule tests like any other test cases, linked to the mapping specification version they test. When a rule changes, the linked tests show what must be re-run. Rule changes after Mock 2 should trigger a re-run of the affected rule tests before Mock 3, not discovery in the business validation.
- Specification approvedData owner approves rules, version 1.3
- Test set builtRecords chosen to hit every branch
- Transform and compareSource vs transformed, field by field
- Simulate and loadErrors reviewed; test set loaded to target
- Check targetDisplay objects in SAP S/4HANA; compare with expected
- Log resultsPass/fail per rule; defects raised; linked to spec version
What would you do?
During rule testing, Priya finds that 140 customers with an unknown legacy payment term were loaded with the default "immediate payment" because the mapping falls back to a default. The specification does not mention a default. What should happen?
Custom fields and extended objects
When the migration team extends a predefined migration object, for example with the Migration Object Modeler in on-premise and Private Edition to carry a custom field, that extension is new code and new rules. Add rule tests for the custom fields as for any other mapping, and check them in the target display and in the processes that read them. Extended objects are a frequent source of defects because they sit outside SAP's standard templates and their checks.
- Test selection, value mapping, transformation, defaults and duplicate rules before full-volume loads.
- Use small targeted data sets that hit every branch of every rule.
- Compare source and transformed records, simulate, load and check the target.
- Unmapped values must be reported, not silently defaulted.
- Link rule tests to the specification version; re-run them when rules change.
Check your understanding · not graded
Lesson check
1. Why use targeted test records for rule testing?
2. What should happen when a source value has no mapping?
3. What does the Migration Cockpit's simulation step add to rule testing?
4. A mapping rule changes after Mock 2. What should follow?