Not Every SAP Custom Object Needs Rewriting: A Risk-Based Modernization Framework

Most mature SAP landscapes carry years, often decades, of custom development: reports, interfaces, enhancements, forms, user exits, background jobs and the occasional direct modification. With mainstream maintenance for SAP ECC 6.0 ending in 2027 and clean core now the default expectation for S/4HANA, the pressure to modernize this code is rising.

The problem begins when “modernize” is read as “rewrite everything”. A custom report that has not run in years should not receive the same investment as pricing logic used on every sales order. A stable enhancement built on a supportable mechanism should not be rebuilt simply because it is ten years old.

A better approach treats custom code as a portfolio rather than a backlog: each object is assessed on evidence and assigned an appropriate outcome.

Step Zero: Prove It Is Used

Before deciding how to modernize an object, establish whether it still needs to exist. The ABAP Call Monitor (SCMON) and Usage and Procedure Logging (UPL) show which custom developments actually execute. The observation window must reflect the business calendar: a program that has not run for six months may be obsolete, or it may be a year-end process. Usage evidence therefore needs confirmation from the business owner.

Objects with no remaining purpose become retirement candidates. This is often the cheapest modernization available: every object safely retired is one fewer to analyse, remediate, test, document and support.

Four Factors That Drive the Decision

1. Business Criticality

What happens if the object fails? Enhancements in order processing, billing, financial close, tax or statutory reporting deserve more scrutiny than a convenience report used by a small team. Criticality sets the level of assurance and testing required, but it does not on its own mean an object should be rewritten. A highly critical development may be technically stable and architecturally acceptable.

2. Dependency Type

How does the development interact with SAP? Some objects consume released APIs and documented extension points. Others rely on classic mechanisms such as BAPIs, BAdIs or user exits, whose release status and future suitability need evaluating. Others read internal tables directly or depend on implementation details that can change between releases. The deeper an object reaches into SAP internals, the greater its upgrade exposure, especially in an ABAP Cloud-oriented architecture, where released APIs draw a clear boundary between custom code and the core.

3. Change Frequency

Consider two developments. One has performed the same calculation for ten years; the other receives new requirements every quarter. Both may work today, but their modernization economics differ sharply. Frequently changing functionality gains most from a cleaner extension architecture, because every future change becomes easier to build and test. Stable functionality may return little from a full rebuild if the current implementation remains supportable.

4. Clean-Core and Upgrade Risk

Finally, look at the technical evidence. What do ABAP Test Cockpit checks, the S/4HANA readiness analysis and the simplification items reveal? Does the program depend on a table whose role has changed, access an internal object instead of a released interface, or compile cleanly while hiding a performance risk? This turns “legacy code is risky” into a concrete engineering finding.

Five Outcomes, Not One

Once the four factors are understood, most custom developments fall into one of five outcomes.

Retire. There is no meaningful usage, the requirement no longer exists, or standard functionality has made the object unnecessary.

Retain. The object is useful, stable, and has an acceptable dependency and upgrade-risk profile. Keep it, document it, monitor it and test it proportionately.

Encapsulate. The business logic is valuable, but the way it touches SAP creates unnecessary coupling. Preserve the logic behind a cleaner technical boundary and replace problematic data access.

Replace. Standard functionality or a released API now meets the requirement. Stop maintaining custom code where differentiation no longer justifies it.

Re-architect. The object is critical, changes frequently and depends heavily on SAP internals or an unsuitable extension mechanism. Redesign it on-stack with ABAP Cloud or side-by-side on SAP BTP.

Object profile	Typical outcome
No meaningful usage across the relevant business cycle	Retire
Stable, low-risk and supportable	Retain
Valuable logic with problematic SAP coupling	Encapsulate
Standard or released capability meets the requirement	Replace
Critical, frequently changing and deeply coupled	Re-architect

The matrix does not replace architectural judgment. Its purpose is to make that judgment explicit.

Three Objects, Three Different Answers

The aging report

An accounts-receivable aging report reads the classic open-item tables BSID and BSAD. In S/4HANA these are served through compatibility views over the Universal Journal. The program compiles and passes functional testing on test volumes. Then month-end arrives, and against production data it slows dramatically. The business logic is still valid; the data-access strategy is not. Rather than rewriting the report, redesign its data access against released CDS views and performance-test it at realistic volume. This is targeted modernization, not replacement.

The sales-order field

A custom header field was added years ago through an append on VBAK and populated in the classic sales order user exit, MV45AFZZ. The business now changes its derivation logic several times a year. The code still works, but the change frequency alters the decision. Moving the field to key-user extensibility and the logic to a released extension point reduces coupling and makes the next ten changes safer.

The stable pricing requirement

A custom pricing requirement routine maintained through VOFM runs on most sales orders, so it is clearly business-critical. Assume it has barely changed in ten years, uses a supported mechanism, produces no major readiness findings and has strong regression coverage. Should it be rewritten because it is old? Its age is not the problem. Retaining it is the lower-risk decision until its dependency profile changes or a clearly better supported option appears. Rewriting stable, critical logic without architectural benefit can introduce more risk than it removes.

Where AI Fits, and Where It Does Not

AI is changing the economics of custom-code analysis. Current tools can explain undocumented ABAP, summarize complex programs, trace dependencies and draft remediation far faster than manual review. That makes prioritization more important, not less. Automatically modernizing an object that should have been retired is still waste; it just happens faster.

AI helps teams understand unfamiliar logic, interpret ATC findings, suggest remediation options and compare alternatives. What it cannot answer on its own is the most important question: should this object exist at all? That depends on business context: why it was built, who depends on it, when it runs, what breaks when it fails, and whether standard functionality now covers it.

The sequence that works is evidence first, decision second, automation third. Programmes that reverse it tend to discover the consequences during integration or regression testing, when changing course is most expensive.

What Changes for Programme Leaders

Budget follows risk. Effort concentrates on the small set of developments where business importance and architectural fragility intersect.

Testing follows criticality. A convenience report and a revenue-critical enhancement should not receive the same testing investment just because both contain custom ABAP.

Clean core becomes measurable. Instead of a slogan, it becomes a trajectory: how many objects were retired, how many still depend on unreleased internals, how many now sit behind stable interfaces, and how many high-change applications use cleaner extension models.

Teams that want to rehearse these calls before facing them on a live programme can work through realistic S/4HANA migration decision scenarios.

Clean core is a destination, not a demolition order. The organizations that reach it most effectively will not be the ones that rewrite the most custom code, but the ones that decide, object by object, on evidence.