Clean Core Strategy: Why Extensibility Matters
Every long-running SAP estate contains a modification someone made for a good reason a decade ago, which is now the thing preventing an upgrade. Nobody remembers the requirement. The developer has left. The test evidence is in a shared drive that was migrated twice. And so the upgrade slips another quarter.
Clean core is the discipline that prevents this. It is not a product and not a certification. It is a set of rules about where your custom logic is allowed to live.
What clean core actually requires
The principle is simple: the standard SAP core stays standard, and everything you add attaches through released, versioned interfaces rather than by modifying delivered objects. In practice that means four things:
- No modifications to SAP-delivered code, and no access to unreleased objects or tables.
- Extensions consume public APIs and released extension points, which SAP commits to keeping stable across upgrades.
- Custom data lives in custom structures, not in appended fields on standard tables that then collide at upgrade.
- Integrations go through the managed integration layer, not direct database reads from a neighbouring system.
Each rule sounds obvious. Each is broken routinely, usually under deadline pressure, usually by someone who intends to clean it up later.
In-app or side-by-side
Once you accept the rules, the design question becomes where a given extension belongs. The honest answer is that both options are correct, for different things.
In-app extensibility — custom fields, logic in released BAdIs, adapted Fiori apps — belongs to changes that are tightly coupled to a standard transaction and need to run inside its commit. If the logic must participate in the same database transaction as the standard process, it belongs in-app.
Side-by-side extensibility on SAP BTP belongs to everything with its own lifecycle: a different release cadence, a different team, a user interface that spans more than one back end, or workloads that need to scale independently of the ERP.
The test is not technical difficulty. It is whether the extension and the core should be allowed to change on different days.
The cost you are actually avoiding
The case for clean core is usually made as "faster upgrades", which understates it. What you are really buying is optionality. A clean core estate can adopt a new SAP capability when it ships rather than eighteen months later. It can move to a different hosting model without a rewrite. It can absorb an acquisition without a six-month reconciliation of two sets of modifications.
The organisations that feel this most acutely are the ones midway through an S/4HANA migration who discover that the custom code analysis has found four hundred objects, of which a meaningful fraction cannot be automatically remediated. That discovery is always expensive and almost always avoidable.
If your core is already not clean
Most are not, and that is a starting position rather than a verdict. The sequence that works: inventory the custom objects and rank them by whether they still serve a live business process; retire what is dead, which is usually more than anyone expects; remediate what is load-bearing onto released interfaces; and put a governance gate in front of new development so the problem stops growing while you fix it.
The order matters. Teams that start remediating before they inventory spend real money modernising code that nobody has executed since 2019.