Lesson 4 of 5
Incremental plan
9 min
Listen to this lesson
A modernization program that stops feature delivery will be cancelled. One that changes everything at once will break something important. Contoso's plan has to fit inside the normal release cadence that Grace runs in SAP Cloud ALM, alongside new requirements, support packages and the yearly upgrade cycle. The tool for that is the slice: a small, independently releasable piece of modernization with its own tests and its own way back.
What makes a good slice
- One extension or one well-bounded part of one, such as "pricing reads in Z_FLEET_REBATE_CALC".
- Behavior-neutral or explicitly changing behavior, never both in the same slice.
- Tested before and after by characterization or unit tests plus the relevant regression scenarios.
- Reversible: a switch, a parallel path or a transport that can be backed out without data repair.
- Small enough to fit one release, so it never waits half-finished in CMQ.
Patterns for safe slices
| Pattern | How it works in SAP | Contoso example |
|---|---|---|
| Ride-along | When an extension changes for a feature, its next modernization step goes in the same release, tested together | A new fleet rebate tier triggers the interface extraction in Z_FLEET_REBATE_CALC |
| Branch by abstraction | Introduce an interface, keep the old implementation behind it, add the new one, switch, then delete the old | ZIF_CMC_PRICING_READER with old (table reads) and new (released APIs) implementations |
| Feature switch | A customizing entry or parameter chooses old or new path per company code or customer | New rebate logic switched on for company code 1810 first, then 1710 |
| Parallel run | Old and new run on the same input; results compared; old stays authoritative until confidence is high | Rebate run in shadow mode for two month-ends, results reconciled with Dan |
| Strangler | A new app takes over part of a process while the old one handles the rest | New RAP app creates agreements; old transaction only changes existing ones until retired |
Patterns that keep modernization slices small and reversible.
- CharacterizeTests pin current behavior of the slice
- Introduce the seamInterface or switch in place; old path still active
- Build the new pathClean implementation behind the seam, unit tested
- Parallel or partial runNew path on one company code or in shadow mode; compare
- SwitchNew path becomes authoritative; old path kept briefly as fallback
- Remove the old pathDelete old code and the switch; record the new clean core level
Fitting the release calendar
Each slice becomes a feature in SAP Cloud ALM, linked to its transports and test evidence, and planned into a release like any other change. Modernization work then shows up in the same release plan, the same quality gates and the same regression runs as business features, which is the point: it is not a side project. Grace reserves a fixed share of each release's capacity for modernization so it is neither starved nor allowed to crowd out business work.
- Quarter 1Retire and quick wins47 dead extensions retired; shared utility ZCL_CMC_DOC_UTIL refactored, lifting many extensions
- Quarter 2Pin and refactorCharacterization suites for the top 20 critical extensions; first refactor slices ride along with features
- Quarter 3Before the upgradeLevel D in order-to-cash and finance remediated or rebuilt behind switches
- Quarter 4Upgrade and measureUpgrade to the next SAP S/4HANA release or feature pack; compare adjustment effort with the baseline
Risks to manage
- Half-finished slices: two paths and a switch left in place forever double the maintenance. Every slice plan includes the removal step and a date.
- Switch sprawl: too many switches make the system hard to reason about. Track them and remove them once a slice is done.
- Hidden coupling: other extensions may call the code being changed. Usage data and where-used lists define the regression scope.
- Upgrade collisions: avoid slices that are mid-flight during an upgrade; finish or pause them first.
What would you do?
Halfway through the year, Contoso has 9 slices with new paths built behind switches, but only 2 have reached the "remove the old path" step. The team wants to start 6 new slices. What should Kenji recommend?
- Deliver modernization in small, tested, reversible slices that fit one release.
- Use ride-along, branch by abstraction, switches, parallel runs and strangler patterns.
- Plan each slice as a Cloud ALM feature, with a fixed share of release capacity.
- Finish slices, including removing old paths and switches, before starting many new ones.
Check your understanding · not graded
Lesson check
1. Which slice violates the rules for a good slice?
2. What does branch by abstraction involve?
3. Why plan each slice as a feature in SAP Cloud ALM?
4. What is the risk of leaving switches and old paths in place after a slice?