Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 5

Remediation planning

10 min

Listen to this lesson

0:00 / 14:29

A classified inventory raises the obvious question: what do we fix, and in what order? Remediation is not a rewrite program. Contoso cannot stop delivering features to rebuild 158 level C and D extensions, and many of them do not need to move at all. The goal is to reduce upgrade risk where it matters most, with each move proven by tests.

Moves between levels

MoveTypical techniqueContoso example
D → C or betterReplace modifications and implicit enhancements with released BAdIs or other extension points; stop writing to SAP tables and use an API that performs the updateSales order save logic: move the custom flag to a custom field and fill it in a released BAdI
C → BReplace reads of internal tables and calls to internal function modules with classic APIs that SAP has classifiedFleet rebate calculation: read pricing through a classified BAPI instead of the tables
C or B → AReplace with released APIs or released CDS views; where none exists, wrap the object in a small wrapper so new logic can be ABAP CloudFleet invoice output: switch the internal read to a released CDS view
Any → retiredRetire extensions nobody uses or that the standard now coversA legacy margin report replaced by a standard analytical app

Typical remediation moves. Retiring is often the cheapest way to raise the estate's average.

Typical remediation moves raise an extension one or more levels, and retiring it is often the cheapest move of all.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-301

Wrapping deserves care. A wrapper is a custom class, often released for use in ABAP Cloud within the customer system, that calls an unreleased SAP object. SAP publishes a sample generator for wrapping function modules and BAPIs. It lets new code be written cleanly, but the wrapper itself still depends on the unreleased object. Its level is the level of what it wraps, and so is the level of any extension that relies on it. The gain is containment: one place to check after an upgrade instead of many.

A wrapper contains the risk in one place for upgrade checks, but it does not remove it: callers keep the wrapped object’s level.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-301

Choosing what to remediate first

Leave or retireLow risk, low effort: retire if unused, otherwise accept and monitor
Accept with testsLow risk, high effort: keep, cover with regression tests, revisit later
Fix nowHigh risk, low effort: shared utilities, single implicit enhancements, simple table reads
Plan as a projectHigh risk, high effort: rebuild or redesign in slices with characterization tests
Prioritizing remediation. Start top-left of the high-risk row: high risk, low effort.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-301

Upgrade risk is highest for level D, then C. Weight it by business criticality: a level D implicit enhancement in sales order save, used on every order Maria's team enters, matters far more than a level C read in a quarterly report. Effort includes the redesign and, just as important, the testing needed to prove the new version behaves like the old one.

Fit remediation into the release calendar

  1. Before go-liveStop the bleedingNew work at level A by default; no new level D without board approval
  2. First quarter after go-liveQuick winsShared utility ZCL_CMC_DOC_UTIL, implicit enhancement in sales order save, retire unused extensions
  3. Before the first upgradeReduce upgrade scopeRemediate level D extensions in critical processes; review level C against SAP's changelog
  4. OngoingRide alongWhen an extension is changed for a feature, lift its level in the same change
A remediation roadmap for Contoso that works with, not against, delivery.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-301

Mistakes to avoid

  • Big-bang rewrites: rebuilding everything in ABAP Cloud at once stalls delivery and multiplies regression risk.
  • Chasing A everywhere: a well-tested level B extension can be the right long-term answer.
  • Remediating dead code: check usage before spending effort.
  • Skipping tests because "it is only a refactor": clean core moves change code paths; test them like any change.

What would you do?

Contoso's first upgrade after go-live is planned for next year. Kenji has budget for about 30 remediation items this year. Which plan is best?

Key points
  • Typical moves: D to C by using extension points, C to B with classic APIs, to A with released APIs; or retire.
  • Wrappers contain risk in one place; they do not remove it.
  • Prioritize by upgrade risk times business criticality against effort; shared utilities are quick wins.
  • Prove every remediation with tests that show unchanged behavior.

Check your understanding · not graded

Lesson check

  1. 1. What is usually the cheapest way to improve an estate's clean core picture?

  2. 2. An extension calls an unreleased SAP function module through a custom wrapper. What does the wrapper achieve?

  3. 3. Which item belongs in "fix now" on the remediation matrix?

  4. 4. What evidence should accompany a remediated extension before sign-off?