Step 4 of 6 Intermediate 10 min

Remediation Without Rewriting Everything

Lesson 4 — The instinct after seeing a scary readiness report is to rewrite everything from scratch. That instinct is how a six-month project becomes an eighteen-month one. Here's the actual remediation hierarchy.

S
s4ready.ai Team

Prerequisites

  • Lesson 3: Reading your own risk

The instinct after seeing a scary readiness report is to rewrite everything from scratch, “properly, this time.” That instinct is precisely how a realistic six-month remediation project quietly becomes an eighteen-month one — and it’s usually driven by fear of the report, not by what the report actually said.

The remediation hierarchy — cheapest fix first, as the default

The remediation hierarchy, cheapest option firstFirst check if a released API replacement already exists — swap the call, done. If not, check if the object can be retired entirely because it’s genuinely unused. Only if neither applies do you rewrite the logic against a released API. Full rewrite is the last resort, not the default.1 · SWAPA released APIalready replaces it —just point to it2 · RETIREGenuinely unused —confirm with usage data,then delete it3 · REWRITEOnly when 1 and 2genuinely don’t apply —the last resort, not the default
Most remediation projects that blow their budget skipped straight to option 3 for objects that only ever needed option 1 or 2.

Why “just rewrite it” is usually the expensive wrong answer

Recall the exact same shape of mistake from AI Foundations Lesson 6 — “just fine-tune it” was the expensive default when a cheaper, more precise fix already existed. Remediation has its own version: a genuinely deprecated table access might just need a swap to its released CDS-view replacement, a five-line change. Treating that the same as a full logic rewrite doesn’t make the fix more correct. It makes the project more expensive, for no additional safety.

The discipline: for every finding, check swap first, retire second, and reach for a full rewrite only when neither genuinely applies — not as the default starting assumption for anything flagged Critical.

The honest exception, and it’s a real one: scale and criticality can force a rewrite regardless of what swap or retire would otherwise suggest. An object implementing a core business process with fifty-plus findings, or one built on internal SAP structures that no longer exist in S/4HANA at all, is a genuine re-architecture candidate — not because the hierarchy failed, but because at that scale a full rewrite is the correct answer, not a shortcut around it. The hierarchy tells you where to start looking for each finding. It doesn’t override what the scale of the problem is actually telling you.

Try it yourself

Take three Critical findings from a real or hypothetical readiness report. For each, honestly classify it: does a direct released-API swap exist? Is the object actually used anywhere, based on real usage data, or has everyone just assumed it might be? Only for the ones where neither applies, write down what the actual rewrite would need to touch.

Go deeper

The specific ECC-to-S/4 object swap table, and a full remediation playbook by pattern, are in The ABAP Custom Code Remediation Guide.

Key takeaways

  • Remediation has a hierarchy: swap the API, retire if unused, rewrite only as the last resort — in that order, every time.
  • “Just rewrite it” is the same expensive-default mistake as “just fine-tune it” from AI Foundations — a cheaper, more precise fix usually already exists.
  • Confirm “unused” with real usage data before retiring anything — an assumption is not evidence.

Next: the objects are fixed. Now the data underneath them has to move — and this is the phase most timelines quietly underestimate.

← Reading Your Own Risk: The Readiness Assessment Data Migration: The Part Everyone Underestimates →