Lesson 6 of 6
A phased remediation plan
10 min
Listen to this lesson
Contoso cannot stop delivering features to clean up 38 apps, and it does not need to. With 2.x delivery on hold, there is no external deadline; the plan is driven by risk, change and Contoso's own release calendar. This lesson assembles the course into a phased plan with regression gates that Grace's steering group can track and Priya can sign off.
The phases
- Phase 0, month 1Inventory and baselineAll 38 apps: owner, usage, technology, linter report, test suite status
- Phase 1, months 1 to 2Retire and gateRetire unused apps; add the linter to every pipeline as a non-blocking report
- Phase 2, months 2 to 4Test suites firstBring each in-scope app's OPA5 suite to the Test Starter; wdi5 for the top 10 apps
- Phase 3, months 3 to 9Remediate by riskAutofix, then hand fixes, app by app, inside normal releases
- Phase 4, months 6 to 12RebuildFiori elements rebuilds where the service exists; old apps read-only until parity
- OngoingHold the lineLinter blocking for new findings; no new legacy code
Ordering the apps
Start with a quick win: a critical app with few findings proves the pipeline, the tests and the release path on something that matters. Contoso started with the core agreement app's single controller extension, then the fleet status app. The order-to-cash apps Maria's team uses daily go in releases outside month-end close and outside the regression windows in CMR.
Regression gates
| Gate | When | Blocks if |
|---|---|---|
| Linter, report only | Every pipeline run from Phase 1 | Never; trend reported weekly |
| Linter, no new findings | From Phase 2, per app once baselined | Findings above the app's baseline |
| OPA5 suite | Every commit | Any failing journey |
| wdi5 suite in CMQ | Nightly and before release | Failures on two consecutive runs, or any failure on release day |
| Key user acceptance | Rebuilds and visible changes | No sign-off from the business owner |
| Release regression in CMR | Quarterly window | Failures in the app's business process tests |
Contoso's regression gates for UI remediation, tightening as the phases progress.
Fitting remediation into releases
Remediation rides on Contoso's normal release train. Front-end server apps are transported with the regular release in Luis's release window; BTP apps move through CMC_DEV, CMC_TEST and CMC_PROD with SAP Cloud Transport Management, where Priya forwards to production after sign-off. Each release carries at most a few remediated apps, so that if a regression appears in CMR's quarterly regression window, the cause is narrow. Maria's order-to-cash apps never go in the same release as a pricing or output change, which would make defects hard to attribute.
| Release slot | Remediation content | Key user check |
|---|---|---|
| Monthly release 1 | Core agreement app extension; fleet status app globals | Maria: agreement and fleet status smoke test |
| Monthly release 2 | Fleet status app async loading | Maria: order status for 1000457 and five other orders |
| Monthly release 3 | Two finance freestyle apps, globals and async | Dan: month-end reports compared with previous run |
An illustrative release slotting for the first remediated apps.
Reporting progress
Grace's steering group gets one page per month: apps by phase, linter findings by rule type (trend, not just totals), suites on the Test Starter, apps with wdi5 coverage, defects found by the suites during remediation, and incidents in production caused by remediated apps. The last number is the one that matters: Contoso's target is zero, and every incident triggers a review of which gate should have caught it.
What goes wrong
- Remediation as a side project. Without slots in the release calendar, it never ships.
- Gates switched on too early. Blocking on all findings from day one stops every feature release; baseline first, then block new findings.
- No owner per app. Findings without owners do not go down.
- Progress measured by count. A big autofix makes the chart drop while the hard sync-loading work has not started.
What would you do?
In month two, the steering group sees linter findings drop from 9,800 to 3,100 and asks Priya whether Phase 3 can be declared complete. What should she answer?
- Without an external 2.x date, plan by risk, change and your own release calendar.
- Phase order: inventory, retire and gate, suites first, remediate by risk, rebuild where a service exists.
- Gate on "no new findings" after a baseline, plus OPA5 and wdi5 results.
- Report findings by rule type and production incidents, not just totals.
Check your understanding · not graded
Lesson check
1. Which phase comes before remediating apps?
2. Why start Phase 3 with a critical app that has few findings?
3. When does the linter gate start blocking at Contoso?
4. Which progress number matters most to the steering group?
5. Why is a large drop in findings after autofix not completion?