Lesson 6 of 6
Risk sources in SAP conversions and upgrades
9 min
Listen to this lesson
Lessons 2 to 5 work for any SAP release. A system conversion or a major upgrade changes so much at once that a transport list can no longer show where the risk is: Contoso's conversion changes thousands of objects in a single SUM run. SAP provides analysis tools that point at the likely failures. Their findings are evidence for likelihood; the process owners still supply impact, and every finding that matters becomes a testable risk statement.
Where conversion risk comes from
| Source | Evidence | Contoso example | Product risk it suggests |
|---|---|---|---|
| Simplification items | SAP Readiness Check and the simplification item checks before SUM | Customers and suppliers become business partners (CVI); 60 one-off customers still failed on missing postal codes six weeks before the CMQ conversion | Orders for one-off aftermarket customers may fail after conversion, resulting in lost counter sales |
| Custom code | ATC with the S/4HANA readiness checks, weighted by SUSG usage | 7,500 objects in scope; 3,900 findings in the first scoped ATC run | Custom pricing routines for fleet orders may misprice after data model changes, resulting in wrong invoices |
| Modifications | SPDD (dictionary) and SPAU (other repository objects) adjustments during SUM | Modified standard objects carried over from ECC | A modification adjusted the wrong way may silently change delivery processing, resulting in blocked shipments |
| Finance data | Finance data migration into the Universal Journal, with reconciliation | Balances and open items for company codes 1710 and 1810 | Balances for 1710 may differ after migration, resulting in a misstated opening position |
| Interfaces | Interface inventory and IDoc partner profiles | About 60 interfaces on Process Orchestration, about 25 of them IDoc | EDI orders from fleet customers may fail on the converted system, resulting in orders missing from the backlog |
SAP-specific risk sources in Contoso's conversion, the evidence for each, and a risk statement it produces.
A long list of findings is not the same as high risk. Contoso's first scoped ATC run produced 3,900 findings across 7,500 objects. Priya doesn't score 3,900 risks. She groups the findings by the process the objects serve, overlays SUSG usage, and asks the owners for impact. Findings in objects that run every day in order to cash or finance become strong likelihood evidence for a handful of process-level risks; findings in rarely used reports become one low-risk line covered by a smoke test. Usage matters: 13 months of SCMON and SUSG data in EP1 before the conversion retired about 4,300 never-called objects and left 7,500 in scope, and a second review in CMP after go-live found about 960 of those 7,500 still never called.
Re-scoring at every conversion run
Each conversion run produces new evidence. After Contoso's Mock 1, Priya re-scored the risks touched by the validation findings before Mock 2, raising likelihood where findings clustered and lowering it where clean results repeated. The dress rehearsal, about three weeks before go-live, gives the last full set of evidence before the go/no-go decisions. Keep product risks (the converted system behaves wrongly) apart from cutover project risks (the runtime overruns, as Mock 1 did at 71 hours): the first drive tests, the second drive Luis's cutover plan.
Upgrades and feature packs in Run
After go-live the same idea scales down. Before each upgrade or feature pack update, read SAP's release information for the areas you use, check the SAP notes and simplification items for the target release, rerun ATC on the custom code, and use SUSG to see which affected objects actually run. The result is the next release's risk register, and the regression scope comes from it: high risks retested at depth, the rest covered by the regular regression run.
What would you do?
Kenji reports 3,900 findings from the first scoped ATC run. Grace asks Priya to add all 3,900 to the risk register "so nothing is missed". What should Priya do?
- In a conversion, SAP's analysis results supply likelihood evidence: simplification items, ATC findings, SPDD and SPAU adjustments, finance reconciliation and the interface inventory.
- Group findings by process and weight them by usage; don't turn every finding into a risk.
- A clean technical check isn't a business test: fixed findings in high-risk areas still need linked tests.
- Re-score after every conversion run, and keep cutover project risks apart from product risks.
Check your understanding · not graded
Lesson check
1. What do SAP Readiness Check and ATC findings mainly contribute to a risk score?
2. Which transactions adjust modified SAP objects during a SUM run?
3. Mock 1 took 71 hours against a 60-hour window. What kind of risk is the overrun?
4. Why overlay SUSG usage on 3,900 ATC findings?