Lesson 5 of 5
Equivalence testing
9 min
Listen to this lesson
A migrated interface is supposed to behave exactly like the original. Equivalence testing proves it: the same inputs go through the old PO flow and the new Integration Suite flow, and the outputs are compared. SAP's migration course puts it simply: run historical messages from PO through the migrated integrations, and if the outputs match, the migration is validated. The same course cites an estimate that testing takes 60 to 65% of overall migration effort, which is why the method deserves design.
Inputs: historical messages
The best test data is real traffic. Capture a representative sample of production input messages from PO with their corresponding outputs: every message type and partner, every variant the mapping handles (single and multi-item, special characters, currencies, empty optional fields), month-end and peak-day examples, and known historical errors. Because these messages contain real business and personal data, agree with data protection how they are extracted, where they are stored, who can see them and when they are deleted, or scramble them consistently on both sides.
- CaptureProduction inputs and PO outputs for each interface, covering variants and peaks.
- ProtectStore under data protection controls, or scramble consistently.
- ReplaySend the same inputs into the new flow in the test tenant with receivers stubbed.
- CompareNew outputs against PO outputs, with agreed rules for fields that may differ.
- ExplainEvery difference fixed or accepted in writing by the interface owner.
What to compare
| Aspect | Compare | Usually allowed to differ |
|---|---|---|
| Payload | Every field value after mapping, element order where the receiver depends on it | Message IDs, creation timestamps |
| Envelope | File names, encoding, line endings, namespaces, headers the receiver reads | Technical headers the receiver ignores |
| Routing | Which receiver got which message | Nothing |
| Errors | Same inputs fail, with equivalent error handling and alerts | Error text wording, if owners agree |
| Performance | Throughput and latency at peak volume | Within agreed targets, not necessarily identical |
Equivalence comparison rules for a migrated interface. Agree the allowed differences before the first run.
Envelope differences cause more go-live incidents than payload differences. A carrier system that rejects a file because the new flow writes UTF-8 with a byte order mark, or names files with a different timestamp pattern, is a classic. Compare the bytes the receiver sees, not just the parsed XML.
Making it repeatable
Run the comparison automatically and keep it. Each migrated interface should have a stored set of inputs, expected outputs and comparison rules that can run again after every change: a mapping fix, an Integration Suite update, an S/4HANA support package. SAP also offers a managed SAP Integration Suite Testing Service for testing during and after a transition, and partner tools exist; whichever you use, the test design in this lesson is what makes the result meaningful. Integration Suite updates arrive continuously, so the regression set outlives the migration.
- Is the interface migrated rather than redesigned?Yes → equivalence test against PO outputs · No → functional test against new expectations
- Do all payload, envelope and routing comparisons match within agreed rules?Yes → next question · No → fix or get written acceptance per difference
- Do error inputs fail the same way, with alerts reaching owners?Yes → next question · No → fix error handling
- Does peak-volume replay meet performance targets?Yes → ready for owner sign-off and cutover · No → tune before switching
What would you do?
Replaying 2,000 historical bank payment messages, the comparison shows identical payload values but every new file has a different line ending from PO's files. The developer says the bank "probably won't care". What should Priya do?
- Equivalence: same inputs through PO and Integration Suite, outputs compared.
- Replay real historical messages, covering variants and peaks, under data protection controls.
- Compare payload, envelope, routing, error behavior and performance; agree allowed differences up front.
- Keep each interface's replay set as a regression suite after the migration.
Check your understanding · not graded
Lesson check
1. What does SAP's migration course recommend as the core test for migrated scenarios?
2. Which difference is most often acceptable in an equivalence comparison?
3. Why do historical messages need data protection controls?
4. What happens to the equivalence replay set after the migration?