Concept card

Clean Core Principle

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Clean Core Principle?

Clean Core replaces 5,000-50,000 lines of in-core ABAP customization with three extension models (70% key-user, 25% developer, 5% side-by-side) living outside the core.

What is the clean core principle in SAP?

Short answer above

Clean Core is the architectural discipline that keeps an S/4HANA (and, by extension, a Business Data Cloud) landscape upgradable without a multi-month regression project every time SAP ships a release. The principle is simple to state and hard to enforce: nothing the customer builds should modify SAP-delivered objects, and everything custom should live in a clearly separated extension layer that SAP's release process cannot touch. For a consultant, Clean Core is less a technology and more a governance posture — the difference between a landscape that treats quarterly upgrades as routine maintenance and one that treats them as a dreaded, expensive event.

What it is and why it matters

Before Clean Core became doctrine, the typical ECC customer accumulated years of custom ABAP sitting directly inside or alongside SAP's namespace — modified standard programs, appended tables, user exits threaded through core logic. A landscape like that could easily carry five thousand to fifty thousand lines of custom code coupled tightly enough to the core that every quarterly release forced regression testing, and not infrequently forced patching or outright refactoring before the upgrade could proceed. That coupling is the single biggest reason S/4HANA and BW modernization projects run long: the migration isn't blocked by the new platform, it's blocked by untangling what customers built on top of the old one.

Why it matters

Zero modification to SAP-delivered code or tables is the first of five invariants — the rule that turns quarterly upgrades from multi-month regression projects into routine cloud events.
70% of typical extensions fit key-user extensibility with no code and no transports — most 'custom requirement' tickets don't need a developer at all.
Side-by-side-first as default guidance means: when in doubt, push the extension to BTP rather than into the core — the fallback decision every architect needs pre-agreed.

Key points

Three extension models: key-user (70%) · developer RAP (25%) · side-by-side BTP (5%).
Five invariants: no SAP-namespace mods · customer namespaces only · released APIs only · side-by-side first · quarterly upgrade discipline.
Legacy custom-code refactoring split: 60-80% retire · 15-25% migrate · 5-10% redesign.
Pre-Clean-Core upgrade cost: €5-15M / 6-18 months. Post: ~€0 / 2-week regression cycle.
Break-even after €2-10M refactoring investment: 18-30 months.
Datasphere CDS views (C032) are Clean Core compliant — analytics depends on Clean Core upstream.
Brownfield migration (C034) inherits legacy debt; greenfield (C035 hybrid) starts clean.
30-50× upgrade-overhead reduction over 5 years for Clean-Core-compliant Tier-1 customers.
Clean Core Principle is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

Clean Core: SAP architectural principle that S/4HANA upgrades must stay frictionless — extensions OUT of core, configuration over modification.
Key user extensibility: No-code extension via Fiori UI tools — custom fields, forms, simple apps. 70% of extension cases.
Developer extensibility (RAP): ABAP RESTful Application Programming in customer namespaces with strict released-API contracts. 25% of cases.
Side-by-side extension: Full app on BTP (Cloud Foundry, Kyma) consuming SAP via OData/events. Maximum decoupling. 5% of cases.
Customer namespace: Z*, Y*, or customer-registered namespaces where custom code lives. SAP namespace modifications are forbidden.
Released API: Stable, versioned API SAP commits to maintain across releases. Custom code consumes only released APIs.
Brownfield drag: Cost of inheriting legacy ABAP-in-core during S/4 migration — typically €2-10M of refactoring.
Quarterly upgrade discipline: Clean-Core practice of absorbing each S/4 cloud release within 2 weeks of regression testing, no skipping.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.