Lesson 5 of 5
Testing implications and fit
10 min
Each transition path asks a different question of the test team. A new implementation asks "does the new design work, and did the master data and open items load correctly?" A conversion asks "does everything that worked before still work, and did the data survive the conversion?" SDT asks both, plus a third question: "did exactly the data we selected arrive, consistent and usable?"
| Test focus | New implementation | System conversion | SDT |
|---|---|---|---|
| Functional testing of the design | Full, everything is new | Changed areas only | Full for redesigned areas; regression for reused ones |
| Regression of existing processes | Little | Heavy | Heavy for reused configuration and code |
| Data validation | Master data and open items loaded by migration objects | Technical reconciliation of converted data | Selected data, including history, reconciled against the source selection |
| History usability | Not applicable | Implied | Explicit: reports, document flow and follow-on actions on transferred history |
| Cutover rehearsals | Data loads | Conversion runs | Selective transfer runs, usually several |
Reconciliation of a selective transfer
In a new implementation you reconcile what you loaded against your load files. In SDT you reconcile against a selection: in Contoso's what-if, everything in company code 1710 with a posting date in the slice. The test must prove three things: everything inside the selection arrived, nothing outside the selection arrived, and what arrived is consistent. That means counts and totals by company code, fiscal year and document type, balance comparisons at the slice start and at cutover, and spot checks of document chains.
- Define the selectionCompany codes, applications, slice dates and master data filters, signed off by owners
- Snapshot the sourceCounts, totals and balances inside the selection
- Run the transferIn a test system, with the transfer tool's logs kept as evidence
- Snapshot the targetSame counts, totals and balances in SAP S/4HANA
- Compare and explainEvery difference explained or raised as a defect
- Business validationOwners check samples and run their reports on the history
SAP Business Transformation Center includes a Data Transition Validation capability that SAP describes as comparing business data from source and target snapshots using SAP reconciliation reports. Whatever tool produces the comparison, the test lead owns the question of whether the comparison is complete and the business owners own the answer to whether the result is right.
History must be usable, not just present
Transferred history is only worth its cost if people can use it. Test the things users will do with it: run year-over-year sales analysis across the slice, display document flow for a transferred invoice, process a return against a delivery from last year, and post a credit memo with reference to a transferred invoice. These tests are easy to forget because nobody "creates" history in a test script.
Test cycles and landscape
- EarlyTransfer trialFirst selective transfer, often into a sandbox; transfer rules and programs refined
- MidIntegration test transferFull selection into QAS; reconciliation and integration testing on transferred data
- LateUAT and dress rehearsalTimed transfer; UAT on transferred history; final reconciliation practice
- Go-liveProduction transferFinal transfer, reconciliation and owner sign-off
SDT data transfers are usually repeated several times, often first in a sandbox where transfer rules are refined, then into the quality system for integration and acceptance testing, then as timed rehearsals. Plan regression testing of reused configuration and code alongside, and include every retrofitted change.
Assessing fit
- Is the target SAP S/4HANA Cloud Public Edition?Yes → new implementation · No → next question
- Do users need history in the new system, or must systems or company codes be merged or split?Yes → SDT is a strong candidate · No → next question
- Will most processes and configuration be kept as they are?Yes → system conversion (or shell conversion if data must be trimmed) · No → new implementation
- If SDT: reuse most of the configuration?Yes → shell conversion · No → mix and match
What would you do?
Priya is asked to estimate testing for a proposed SDT with a two-year time slice and a shell conversion. Which estimate structure is best?
- SDT testing combines conversion-style regression, new-design functional testing and selective-data reconciliation.
- Reconcile against the approved selection: everything inside arrived, nothing outside arrived, all of it consistent.
- Test that transferred history is usable in reports and follow-on processes.
- Expect several transfer cycles: sandbox, QAS, timed rehearsal, production.
- Fit depends on target edition, need for history or consolidation, and how much configuration is reused.
Check your understanding · not graded
Lesson check
1. What must reconciliation of a selective transfer prove?
2. Which test is easy to forget in SDT?
3. Which SAP Business Transformation Center capability compares source and target snapshots?
4. For SDT with a shell conversion, what testing besides data reconciliation is heavy?