"Clean core" gets presented to executives as an architecture principle, at which point it stops being interesting to them — which is unfortunate, because it is one of the few technical positions that can have material lifecycle-cost consequences.

Here is the practical version. Clean-core patterns reduce direct core remediation, while extensions and integrations still require impact analysis and regression testing. Nothing is exempt from testing — what changes is how much of the work is unavoidable rework inside the core versus verification of something built to a supported interface. Clean core is the discipline of keeping the first kind of cost from compounding.

Where a change is placed, and who carries it afterwards Four ways of placing a change, compared left to right as coupling to the core increases in the opposite direction. Standard configuration uses delivered behaviour, and SAP owns upgrade impact; the lifecycle cost sits in configuration. A supported on-stack extension built on released interfaces shares upgrade impact between SAP and the customer, and the cost sits in the release cycle. A side-by-side extension on SAP BTP puts upgrade impact on the customer, and the cost sits in the extension. Integration through SAP Integration Suite puts upgrade impact on the interface contract, and the cost sits in the contract between systems. Coupling to the core decreases → 01 Standard configuration Delivered behaviour Upgrade impact SAP Lifecycle cost In configuration you already own 02 On-stack extension Released interfaces Upgrade impact Shared Lifecycle cost In your release cycle 03 Side-by-side extension SAP BTP Upgrade impact You Lifecycle cost In the extension own lifecycle 04 Integration SAP Integration Suite Upgrade impact The contract Lifecycle cost In the interface between systems Where a change is placed, and who carries it afterwards Four ways of placing a change, compared left to right as coupling to the core increases in the opposite direction. Standard configuration uses delivered behaviour, and SAP owns upgrade impact; the lifecycle cost sits in configuration. A supported on-stack extension built on released interfaces shares upgrade impact between SAP and the customer, and the cost sits in the release cycle. A side-by-side extension on SAP BTP puts upgrade impact on the customer, and the cost sits in the extension. Integration through SAP Integration Suite puts upgrade impact on the interface contract, and the cost sits in the contract between systems. Coupling decreases ↓ 01 Standard configuration Delivered behaviour Upgrade impact SAP Lifecycle cost In configuration you already own 02 On-stack extension Released interfaces Upgrade impact Shared Lifecycle cost In your release cycle 03 Side-by-side extension SAP BTP Upgrade impact You Lifecycle cost In the extension own lifecycle 04 Integration SAP Integration Suite Upgrade impact The contract Lifecycle cost In the interface between systems
The question is not simply “extend or don’t extend”. It is where the change is placed, and who is holding it at the next upgrade.

What SAP actually says

SAP's guidance is that changes to the functionality it delivers should be built outside the core using supported extensibility. Two established extension models are side-by-side extensibility, where extensions run as separate applications on SAP Business Technology Platform, decoupled from the ERP system; and on-stack extensibility with ABAP Cloud, where extensions live within the system but are built against released, upgrade-stable interfaces.

SAP has also moved past treating clean core as binary. Its clean-core level model grades extensions by architectural integrity and upgrade safety: Level A uses released APIs and extension points; Level B uses classic APIs and extension points; Level C accesses internal objects and is conditionally clean; and Level D is not recommended and not clean core. The purpose is to understand where each extension sits before deciding what should change.

Why the binary framing did damage

The earlier framing produced two equal and opposite failures.

The first is paralysis. An organization inventories eight hundred custom objects, concludes it cannot possibly become "clean", and stops. The inventory is filed. Nothing changes, and the liability keeps compounding.

The second is over-correction: a remediation programme that rebuilds everything on BTP because BTP is where clean things go. This replaces a known maintenance cost with an unknown one, plus a new platform to operate, plus integration that didn't previously exist. Relocating an extension side-by-side without confirming that it is still used moves cost rather than removing it.

The level model supports the answer both failures miss. An assessment distinguishes the modifications that are upgrade-relevant from those that are dormant or low-impact, and identifies a middle band worth converting on the next occasion the code is touched anyway. Grade them, cost them, and move the ones that pay for themselves.

The integration consequence

Building outside the core means building across a boundary, and boundaries need governance.

SAP Integration Suite is SAP's integration platform-as-a-service for connecting applications, data, events and partners across SAP and non-SAP environments. Adopting it is straightforward. Governing it is not.

One failure mode is specific: several teams build point-to-point integrations independently, each reasonable, and eighteen months later nobody can say what depends on what. The next upgrade then becomes an archaeology exercise — which is exactly the cost clean core was supposed to eliminate. The liability moved; it didn't disappear.

If you take one operational rule from this note: decide who owns integration standards before the second team starts building. Not what the standards are — who owns them. The standards will change; the ownership is what makes that survivable.

What this looks like as a decision

Clean core is worth treating as a forecast of future upgrade effort rather than a cleanup project:

  • Inventory by usage, not by count. Custom objects that haven't executed in a year are a deletion conversation, not a remediation one.
  • Grade what remains against SAP's clean-core levels, so "how clean are we" has an answer that isn't a feeling.
  • Cost the top band in upgrade-effort terms. This converts an architecture debate into a business case.
  • Set the boundary rule for new work now. New modifications inside the core should require a named approver, which clarifies who owns the change and what it is worth.
  • Name the integration owner before the second builder arrives.

None of this requires a transformation programme. It requires a decision about what you will stop doing.

Scope of this note

This describes assessment, grading, costing and governance design. No SAP BTP or SAP Integration Suite implementation reference is published on this page.

BTP, data and AI readiness