The clean core is the defining architectural constraint of SAP S/4HANA Public Cloud. It is not a feature, it is the foundational rule that makes continuous, automatic updates technically possible. Every other architectural decision in a Public Cloud implementation flows from it.

What Clean Core Means Technically

In SAP S/4HANA Public Cloud, no custom ABAP code exists in the core system. There are no Z-programs, no modified standard SAP objects, no custom database tables in the core schema. The S/4HANA Public Cloud instance that SAP delivers to your organization is identical in structure to every other customer’s instance. This standardization is what enables SAP to push mandatory quarterly updates across all tenants simultaneously without breaking any individual customer’s system.

This is a hard technical constraint enforced at the platform level, not a best-practice recommendation.

Where Customization Lives: SAP BTP

All custom business logic, differentiating workflows, and third-party integrations are built and operated on SAP Business Technology Platform (BTP) completely outside the core. Two extensibility paths are available:

  • In-App Extensibility – Custom fields, Business Add-Ins (BAdIs), and key user tools built within S/4HANA’s standard extensibility framework and fully upgrade-safe.
  • Side-by-Side Extensions on BTP – Full custom applications and services (SAP CAP, ABAP RAP, Build Apps) deployed on BTP runtimes. Communicates with S/4HANA via published APIs only. Architecturally isolated from the core.

Clean Core vs. Traditional On-Premise 

The clean core is not a constraint on what you can build. It is a constraint on where you build it.

Why It Matters for Your Upgrade Strategy

In a traditional SAP on-premise environment, custom code in the core creates upgrade risk. Every SAP update must be regression-tested against all custom objects. The more Z-programs exist, the longer and more expensive every upgrade cycle becomes.

The clean core eliminates this entirely. Because SAP’s code and your extensions never co-exist in the same layer, SAP can deliver Feature Pack Stacks twice per year automatically. Your BTP extensions communicate with the updated core via stable, versioned APIs with SAP’s formal deprecation policy governing any breaking changes.