Clean Core is not optional: the architecture case for S/4HANA
The debt hiding inside your custom code
Every SAP landscape older than a few years carries custom code that once solved a real business problem and now quietly blocks the next one. Modifications to standard objects, custom logic wedged into user exits, Z-tables that became load-bearing — none of it looked risky when it shipped. It becomes risky the day you want to upgrade, move to the cloud, or connect an AI agent to the process it touches.
Clean Core is SAP's answer: keep the digital core close to standard, and push extensions to a side-by-side or on-stack layer with defined, versioned interfaces. It is frequently pitched as a best practice you can adopt gradually. In our experience running S/4HANA transformations, it behaves less like a best practice and more like a precondition — for upgradeability, for BTP extensibility, and increasingly for AI.
Why AI raises the stakes
An AI agent that calls into SAP needs a stable, well-defined surface to call into. If the process it is automating is entangled with undocumented custom logic, the agent inherits that fragility — every model call becomes a bet on code nobody has fully mapped. Clean Core extension points (BAdIs, CDS views, RAP-based APIs) give both humans and AI clients a contract to rely on.
This is also why we treat Clean Core and Business AI as one architectural conversation, not two. An MCP server exposing SAP capabilities is only as trustworthy as the interfaces behind it. Clean Core is what makes those interfaces trustworthy in the first place.
What we actually do
In practice, a Clean Core program starts with an honest custom code inventory — usage data, not assumptions — followed by a disposition per object: retire, replace with standard functionality, or migrate to a side-by-side extension on BTP using CAP or RAP. The hard part is rarely technical; it is prioritizing which entanglements to unwind first given a live business that cannot pause.
We sequence this against your S/4HANA transformation timeline rather than treating it as a separate initiative, because the two share almost every decision: what stays in the core, what moves to the platform, and what interface connects them.