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

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

Every custom object built into an ECC landscape over the years deserves a documented decision — retain, redesign, replace, or retire — and it is the undocumented Z-code, not the documented kind, that quietly breaks migration budgets.

Every mature SAP ECC landscape contains custom code that nobody currently at the organization fully remembers commissioning. A pricing exception written for a customer relationship that ended years ago. A report built for a regulatory requirement that has since changed. An interface patched repeatedly to accommodate a partner system that was itself replaced. None of this code is inherently a problem — much of it, in fact, represents genuine, defensible business logic that reflects how the organization actually operates, distinct from SAP’s generic standard processes. The problem is not that custom code exists. The problem is that most organizations cannot say, with confidence, which of it still matters.

An SAP S/4HANA migration forces that question to be answered, because custom code does not migrate automatically or safely by default. Every custom object needs a decision, and the decisions that get made by default — because no one had the information to make them deliberately — are where migration budgets and timelines most often break.

SAPinsider’s 2025 benchmark research is direct about this: among all the tasks organizations rated for difficulty during their S/4HANA migration, adapting custom code scored 5.88 — the single highest-difficulty