Customizations

How organizations adapt SAP S/4HANA Cloud Public Edition to their own requirements without modifying the standard core — and why that distinction matters

Discover the capabilities of Custimizations

SAP S/4HANA Cloud — Customizations, a Scheer IDS topic on SAP S/4HANA Cloud Public Edition

SAP S/4HANA Cloud Public Edition does not support the kind of direct, in-system customization familiar from on-premise ERP or SAP ECC. Classic modification of the core system is not available in the Public Edition at all. Instead, every adaptation follows the Clean Core principle: the standard core stays as SAP delivers it, and organization-specific requirements are built as clearly separated extensions.

There are two supported ways to extend SAP S/4HANA Cloud Public Edition.

In-app, or on-stack, extensions are built inside the tenant itself, using the SAP Extensibility Wizard: custom fields, custom logic, custom business objects, and adjusted forms, all created through defined, SAP-supported extension points.

Side-by-side extensions are built outside the core entirely, on SAP Business Technology Platform, using ABAP, Java, Node.js, or other supported languages, and connect back to S/4HANA Cloud Public Edition through APIs rather than direct access to the database or code.

Which route an organization uses depends on the scope and nature of the requirement — a small field addition is typically in-app; a full custom process or application is typically side-by-side.

In-app versus side-by-side extensibility

In-app extensions live inside the SAP S/4HANA Cloud Public Edition tenant and are the right choice for smaller, localized adjustments: an extra field on a sales order screen, a validation rule, a custom report built on standard data. Because they use SAP's defined extension points, they are automatically upgrade-compatible with the twice-yearly releases, without additional testing overhead.

Side-by-side extensions live on SAP Business Technology Platform, fully decoupled from the core. They are the right choice for larger custom processes, applications with their own user interface, or logic that needs to combine S/4HANA Cloud Public Edition data with data from other systems. Because they run separately from the core, they can be built, tested, and deployed on their own schedule, independent of S/4HANA Cloud release cycles.

SAP also defines a set of Clean Core levels, from A to D, that describe how closely a given extension adheres to best practices — the higher the level, the lower the long-term technical debt and the simpler future upgrades become. Most organizations aim for the highest level practical for a given requirement, rather than treating it as all-or-nothing.

Clean Clore principle

The Clean Core principle is a trade-off: less freedom to customize the core system, in exchange for a faster, lower-maintenance path to a standardized ERP. Because SAP S/4HANA Cloud Public Edition implementations follow GROW with SAP's Fit-to-Standard approach, the practical question during a project is rarely "Can we customize this?" but "Does this requirement need an in-app extension, a side-by-side extension, or does the standard process already cover it?"

Getting that call right, requirement by requirement, is what determines how disruptive or smooth each future release becomes. Explore our functional scope guide to see how standard coverage varies by module and where extension decisions typically come up.

Discuss your need for customizations