Clean Core Without the Rewrite Reflex: A Risk-Based Way to Triage SAP Custom Code

A custom report that has run reliably for ten years is not automatically a modernization priority just because it contains old ABAP syntax. The architectural risk comes from what the development depends on, how often that dependency changes, and how difficult the object is to upgrade or replace.

The first step in a Clean Core review should therefore be inventory, not rewriting. Identify direct table access, unreleased function modules, classes, enhancement spots, classic exits, implicit enhancements, generated objects, external RFC contracts and custom modifications.

Every custom object can be placed into a small number of dependency categories. Some use stable released APIs. Some read tables directly but never update them. Others depend on unreleased implementation details, modifications or deeply coupled exits.

The category matters because two programs with identical business importance can have completely different upgrade risk. A small utility that modifies standard code may deserve attention before a large custom report that consumes stable interfaces.

• Released and supported API or extension point
• Stable read-only dependency with a migration path
• Unreleased API or implementation object
• Modification or implicit enhancement
• Tightly coupled integration contract
• Dead or duplicated custom object

Traditional ABAP systems allow access to many objects that are technically callable. That does not mean those objects are the intended extension contract for a cloud-ready or upgrade-stable architecture.

For each dependency, check whether a released API, CDS entity, class, event or extension point can provide the same business semantics. Replacing a table with a newer-looking CDS view is not an improvement if the view does not represent the same business meaning.

A useful modernization queue can be built from four factors: business criticality, dependency risk, change frequency and replacement complexity. High-criticality objects that use fragile dependencies and change frequently should move toward the front of the queue.

Low-change utilities with low upgrade exposure can remain under control while the team addresses the objects that actually create release friction. This prevents Clean Core from becoming an expensive blanket rewrite programme.

• Business criticality: what stops if this fails?
• Dependency risk: released contract or internal implementation detail?
• Change frequency: how often does this object need modification?
• Replacement complexity: is there a proven supported alternative?

Modernization is not a binary keep-or-rewrite decision. In practice, the useful outcomes are retain, encapsulate, replace, redesign or retire.

Retain when the dependency is supported and the object remains valuable. Encapsulate when a fragile dependency cannot be removed immediately but can be isolated behind a controlled interface. Replace when a released alternative preserves semantics. Redesign when the requirement belongs in a side-by-side extension or event-driven pattern. Retire when the custom object duplicates standard capability or no longer has meaningful usage.

A team can delete thousands of lines of code and still remain tightly coupled to the core. Conversely, a modest refactoring that moves critical dependencies behind released contracts can materially improve upgrade stability.

The better modernization metrics are the share of critical custom objects using released interfaces, the number of modifications or implicit enhancements, the volume of direct core dependencies, and the effort required to adopt a new S/4HANA release.