Custom Code and Legacy Complexity: What Happens to Your SAP Extensions in S/4HANA?

rating in the survey, ahead of data migration, integration testing, and organizational change management. That is a meaningful data point, because it comes from organizations who have actually been through the process, not from vendors describing a hypothetical challenge.

their migration — meaning for a majority, the custom-code decision is still being made implicitly rather than deliberately.

Part of what makes custom code difficult is architectural: S/4HANA’s simplified data model and in-memory architecture mean that a meaningful share of ECC-era custom code — code written against database tables or logic structures that no longer exist in the same form — will not run unmodified after conversion, regardless of how well it performed for years in the legacy system. That is a technical reality of the platform shift, not a defect in the original code.

The organizations that navigate custom code well typically apply a consistent, deliberate decision to every custom object, rather than defaulting to “keep everything as it was” or “rebuild everything from scratch.”

Retain: the object reflects genuine, still-relevant business logic, is compatible (or can be made compatible) with S/4HANA’s data model, and continues to earn its ongoing maintenance cost.

Redesign: the underlying business need is real, but the object should be rebuilt to work correctly within S/4HANA’s architecture, or reimplemented using newer, more maintainable tools such as SAP Fiori extensibility or the SAP Business Technology Platform rather than classical ABAP modification.

Replace: the business need the custom object once addressed is now met natively by S/4HANA’s standard functionality — a common outcome, since S/4HANA’s simplified processes cover ground that required custom development in ECC.

Retire: the object no longer serves a genuine business purpose, and it exists in the landscape purely as inherited complexity nobody has had reason to remove.

Making this decision well requires two things most organizations underestimate the need for: an accurate technical inventory of what custom code actually does — not what it was originally intended to do, which often diverges after years of undocumented patching — and business input on which of it still matters, since the technical team maintaining a custom object is rarely the same team that can judge whether the business logic it encodes is still relevant.