SAP Clean Core

Sometime around 2018 SAP finally realized that migrating from classing ECC to S/4 is not that easy for a customer. ECC systems are usually heavily customized, bloated with custom code, flooded with numerous background jobs - not clear what data they process and wired in with many interfaces that it is not possible to track what data they bring in/out.

Back then the SAP’s introduced a clean core strategy (remembers TechEd slogan – Keep the core clean). It is a modernization approach designed to keep the ERP system (especially SAP S/4HANA) as close to standard as possible. That means minimizing invasive customizations and technical debt. It aims to make systems upgrade-safe, cloud-ready, and innovation-friendly by shifting custom logic and extensions outside the core, typically to SAP Business Technology Platform (BTP).

Clean core principles:

·        Standardization of Business Processes – Adopt SAP Best Practices to reduce complexity.

·        Decoupled Extensions – Move custom logic outside the ERP core using BTP.

·        Integration via APIs – Ensure reliable, upgrade-safe connectivity.

·        Data Governance – Maintain clean, consistent data for analytics and compliance.

·        Efficient Operations – Reduce maintenance costs and security risks.

However, what SAP really wanted back then was to a kind of "cloud mandate" to their customers. For years there has been a pushback of that. Still many customers prefer to stay on-premise for various reasons. It makes no sense to dig to those reasons here now but surveys by ASUG/DSAG confirmed it many times. S/4 adoption did not go a pace SAP wanted it.

Now we are in 2025 when SAP comes with the lates iteration of the clean core strategy – document Clean core extensibility for SAP S/4HANA Cloud. To simply put it - they came from cloud mandate to practical reality the customers live in. Seems SAP finally gets the customers issues and they do not demonizing a custom development rather they address it more pragmatic and customer friendly approach. Within the latest strategy SAP introduces A–D extensibility model replacing old tiers for compliance and upgrade safety. Finally, a classic ABAP APIs and ABAP technologies (e.g. customer exits, SAP Script, Smart Forms, classic workflow, web dynpro ABAP) are classified as clean core compliant at level B which means are upgrade-stable.

 

Level A: Fully Compliant Extensions done with SAP Build by using only publicly released, stable interfaces backed by formal stability contracts.

·        Side-by-Side: Develop on SAP BTP using pro-code and low-code tools for applications and process automation.

·        On-Stack: Build within SAP Cloud ERP Private using the ABAP Cloud model and approved APIs.

 

Level B: Classic API-Based Extensions - Utilize SAP’s classic APIs and technologies with well-defined, documented, and generally upgrade-stable interfaces.

 

Level C: Partially Compliant Extensions - Depend on SAP internal objects for flexibility in legacy scenarios. SAP provides object change logs to help identify incompatible changes early and plan upgrades proactively.

 

Level D: Not recommended extensions not considered “clean” that use explicitly non-recommended objects or techniques (e.g., objects marked as “noAPI” in the Cloudification Repository, modifications to SAP objects, direct write access to SAP tables, or

implicit enhancements). These represent the highest risk and create significant technical

debt.

 

Level D: Non-Compliant Extensions (Not recommended/considered as clean core because it is the upgrade risk/technical debt.) - Use non-recommended objects or techniques such as:

·        Objects marked “noAPI” in the Cloudification Repository

·        Modifications to SAP objects

·        Direct table writes or implicit enhancements

 

More information:

Clean core extensibility for SAP S/4HANA Cloud

3578329 - Frameworks, Technologies and Development Patterns in Context of Clean Core Extensibility

Cloudification Repository Viewer – BW classic components listed here, none of BW artefacts has a successor in fact, but they won’t be missed as in modern BW (e.g. BW4/HANA, SAP Datasphere and BDC) replaces those old technologies completely.

SAP S/4HANA Cloud Public vs Private Edition?

SAP S/4HANA Cloud is an enterprise resource planning (ERP) suite offered by SAP, and it comes in two primary deployment options: Public Edition and Private Edition. Each offers different features, levels of customization, and deployment flexibility to cater to various business needs. In general, below is a breakdown of the differences between the two:

SAP S/4HANA Cloud Public Edition is better deal for organizations that want a standardized, effective, and quickly deployable ERP solution with minimal customization needs.

On other hand its Private Edition is better suited for organizations that require a highly customized ERP environment, need control over their system updates, and are willing to invest in a more flexible and powerful deployment model.

3 Tier Model to get to ABAP Cloud

Customers who want to migrate tier SAP ERP systems to a cloud need to embrace the cloud from ABAP perspective too. This shift is needed as within on premise SAP ERP systems Classic ABAP extensibility options (user/customer exits, BADIs, enhancement points, modifications, append, structure, menu exits, etc.). All of these were used to tailor SAP systems to meet specific business requirement. But since the introduction of cloud the Classic ABAP extensibility options are not supported anymore in the cloud bases SAP ERP systems.

Apparently majority of SAP customers won’t start with move to the cloud by having a new greenfield implementation of ERP system like S4/HANA Could is. Therefore, SAP had to come up with something that would enable the cloud transition for the existing customer running their ERP systems on premise. It is a 3-tier Extensibility Model. Its purpose is to enable the transition from Classic ABAP to ABAP Cloud. It is also intended to manage a coexistence of these different extensibility models.

Remember much used term - "clean core"? Well as it means up2date, transparent, unmodified SAP system. All these adjectives describe a system that is cloud compliant. Reason why it is important is that as in the cloud all the customers use same base code line and changes are applied to all customers simultaneously. Therefore, there is a no way to allow each individual customer to implement enhancements in the same way that they could in their on premise systems.

 

Tier 1 – Cloud development: default choice for all new extensions and new custom applications following the SAP S/4HANA Cloud extensibility model. Goal is to get to this tier form the lower tiers.

 

Tier 2 – Cloud API enablement / API layer: if there are any objects (BAPI, Classes, Function Modules, Core Data Services) that are not yet released by SAP and are required in tier 1 a custom wrapper is created for them. By this a missing local public APIs or extension points are mitigated. The custom wrappers are built and released for cloud development. Once there is SAP released public local API, the custom one can be set as obsolete and removed. ABAP Test Cockpit (ATC) can be leveraged inhere to force ABAP Cloud guidelines. Also via ATC exemptions violation of the ABAP Cloud rules can be managed.

 

Tier 3 – Legacy Development / classic ABAP development: classic extensibility based on classic ABAP custom code that is not supported in the ABAP Cloud development model. E.g. BAPIs, user exits, modifications, SAP GUI, file access, reports writing to GUI, etc. The goal is to avoid developments in this tier and follow the ABAP Cloud development mode. However, as the customer is at this stage the classic objects are to be modernized and moved to the tier 1. Those need to be refurnished one-by-one there is no any tool for that.

 

Now when it comes to real (re)development of the objects in the particular tiers. A concept of software components is used in here. By creating its own component, the object is separated from the others (e.g. non-clean core components – remember clean core). This is because the component puts stricter ABAP Cloud rules to the objects thus separation is needed.

For all the details how to work with the object within specific tier follow below SAP official guidelines.

 

More information:

Clean Core

ABAP Cloud API Enablement Guidelines for SAP S/4HANA Cloud, private edition, and SAP S/4HANA - overview

ABAP Extensibility Guide - overview

ABAP Cloud - How to mitigate missing released SAP APIs in SAP S/4HANA Cloud, private edition and SAP S/4HANA – The new ABAP Cloud API enablement guide

SAP S/4HANA Extensibility: All You Need to Know