What is Clean Core Architecture? SAP's Vision for the Future

What is Clean Core?

If you have been in the SAP ecosystem for any length of time, you have heard the term "Clean Core" thrown around in keynotes, architecture reviews, and vendor pitches. But what does it actually mean in practice, and why should you care?

At its simplest, Clean Core is SAP's architectural mandate that the S/4HANA core should remain as close to standard as possible. Custom modifications, enhancements, and extensions should not live inside the core system. Instead, they belong on the SAP Business Technology Platform (BTP) or within well-defined, upgrade-safe extension points.

The core principle is straightforward: if SAP delivers it, do not modify it. If your business needs something SAP does not deliver, build it in a way that does not break when SAP ships the next update.

This is not just a philosophical preference. It is a technical architecture pattern backed by tooling, governance frameworks, and a fundamentally different development model called ABAP Cloud. SAP has made Clean Core the prerequisite for staying on the innovation path with S/4HANA Cloud and, increasingly, S/4HANA Private Cloud and on-premise editions.

For Basis consultants and architects, Clean Core changes the conversation from "how do we fit our customizations into the upgrade window" to "how do we architect so the upgrade window is irrelevant."

The Problem Clean Core Solves

Let's be honest about where most SAP landscapes are today. The average enterprise S/4HANA or ECC system carries tens of thousands of custom objects. Z-programs, BAdI implementations wired into core processes, modified SAP standard code, custom function modules called from everywhere. The technical debt is staggering.

The Custom Code Trap

Here is how it typically plays out:

A business user requests a change to a standard process
A developer modifies SAP standard code or builds a tightly coupled enhancement
The modification works perfectly for the current release
SAP ships an update that touches the same code path
The upgrade team spends weeks analyzing conflicts, testing regressions, and patching workarounds
The business delays the upgrade because the risk is too high
The system falls further behind on patches, features, and security fixes
Repeat for 10 to 20 years

This cycle is why so many companies are still running ECC 6.0 with enhancement packs from 2012. Every customization that touches the core creates upgrade friction. Enough friction and the system becomes effectively frozen.

The Real Costs

The financial impact goes beyond the upgrade project itself:

Security exposure from running unpatched systems
Missing innovation because new SAP features require a current release
Developer burnout from maintaining code that fights the platform
Integration brittleness where custom interfaces break on every support pack
Audit and compliance risk from undocumented modifications

Clean Core is SAP's answer to all of this. It is not just a best practice recommendation. It is a structural rethinking of how custom functionality coexists with the standard product.

Clean Core Principles

Clean Core rests on four foundational principles. Understanding these is essential before you touch a single line of code.

1. Keep the Core Standard

No modifications to SAP standard code. No access keys for object modifications. No custom code in SAP namespaces. The delivered S/4HANA system should be deployable and upgradeable without any customer intervention.

2. Extend on BTP

Business logic that goes beyond the standard belongs on the SAP Business Technology Platform. This means building CAP applications, workflow extensions, integration flows, and custom UIs as side-by-side extensions that communicate with the core through APIs.

3. API-First Development

All communication between extensions and the core happens through released, stable APIs. No direct table access. No calling internal function modules. No reading SAP structures that might change in the next release. If SAP has not released an API for your use case, you request one or find an alternative approach.

4. Upgrade Compatibility

Every piece of custom code must be upgrade-compatible by design. This means using only released objects, following the ABAP Cloud development model, and testing against the ABAP Test Cockpit (ATC) with the Cloud-readiness checks enabled.

The Clean Core Architecture

The Clean Core architecture follows a layered model that separates concerns cleanly.

At the center sits the S/4HANA Core. This is the standard system with SAP-delivered business logic, data models, and processes. You do not modify anything here. You configure it using SAP's standard customizing tools, Fiori app configuration, and business rules frameworks.

Surrounding the core is the API Layer. SAP exposes business functionality through a growing catalog of released APIs: OData services, SOAP services, RFC-enabled function modules marked as released, and increasingly, RAP-based (RESTful ABAP Programming) business objects. This API layer is the contract between the core and everything outside it.

On the outer ring sits the Extension Layer, primarily on BTP. This is where your custom applications, integrations, workflows, and UIs live. They consume the core's APIs, but they have no direct dependency on the core's internal implementation.

Think of it as a series of concentric rings:

Inner ring: S/4HANA standard (untouched)
Middle ring: Released APIs and extension points (the contract)
Outer ring: BTP extensions and custom applications (your innovation)

The key insight is that the middle ring acts as a stability boundary. SAP commits to maintaining released APIs across upgrades. As long as your extensions only depend on released APIs, upgrades should not break them.

Where Custom Code Lives Now

This is the practical question every SAP team asks: if we cannot modify the core, where does our custom code go? Clean Core provides three main patterns.

In-App Extensions (Tier 1)

Some customization still lives inside the S/4HANA system, but only within strict boundaries. These are called in-app extensions and they follow the ABAP Cloud model:

Key-User Extensibility: Business users and power users can create custom fields, custom logic (via BAdIs designed for key users), custom CDS views, and custom analytical queries using the Fiori-based extensibility tools. No ABAP development required.
Developer Extensibility: ABAP developers can build custom RAP business objects, CDS views, and services inside the S/4HANA system, but only using released SAP objects. The ABAP Cloud development model enforces this at compile time.

In-app extensions are appropriate for functionality that is tightly coupled to core transactional processes and where latency or data locality matters.

Side-by-Side Extensions (Tier 2)

For anything that does not need to live inside the core, side-by-side extensions on BTP are the preferred pattern:

Custom applications built with SAP CAP (Cloud Application Programming Model)
Workflow extensions using SAP Build Process Automation
Integration flows using SAP Integration Suite
Custom UIs using SAP Build Apps or SAPUI5 on BTP
Data analytics and reporting extensions using SAP Analytics Cloud

Side-by-side extensions communicate with S/4HANA exclusively through APIs. They have their own lifecycle, their own deployment pipeline, and their own scaling characteristics.

The Decision Framework

Use this simple decision tree:

Does SAP standard handle the requirement? Configure it, do not code it.
Does the requirement need real-time access to core transactional data? Consider in-app developer extensibility.
Can the requirement be served by an API call to the core? Build it as a side-by-side extension on BTP.
Is the requirement entirely independent of SAP data? Build it outside the SAP ecosystem entirely.

The ABAP Cloud Model

ABAP Cloud is the development model that makes Clean Core enforceable, not just aspirational. It is the single most important technical concept for ABAP developers to understand.

ABAP Cloud vs. Classic ABAP

In classic ABAP, a developer can access virtually any SAP object: internal tables, function modules, classes, database tables. There are no guardrails. If you know the object name, you can use it.

ABAP Cloud changes this fundamentally. In ABAP Cloud, you can only use objects that SAP has explicitly released for customer use. The development environment enforces this through syntax checks and ATC rules. Try to call an unreleased function module, and the code will not compile.

This is not a guideline. It is a hard technical constraint.

Released APIs and Objects

SAP maintains a catalog of released objects accessible through the Released Objects view in ADT (ABAP Development Tools). These include:

Released CDS views (marked with C1 contract)
Released BAdI definitions
Released RAP business objects
Released classes and interfaces
Released function modules

The catalog is growing with every S/4HANA release. Where gaps exist, SAP has a process for customers to request new released APIs through the SAP Influence program.

The Tier Model

SAP's tier model for ABAP development in S/4HANA looks like this:

Tier 1 (ABAP Cloud, restricted): Only released objects. Full upgrade compatibility. This is the target state for all new development.
Tier 2 (ABAP Cloud, with local APIs): Uses released objects plus customer-defined wrapper objects around unreleased SAP functionality. This is a transition pattern for scenarios where released APIs do not yet exist.
Tier 3 (Classic ABAP): Unrestricted access to SAP objects. This is the legacy model and should only be used for existing code that has not yet been migrated.

The migration path is clear: move everything to Tier 1 over time. Use Tier 2 as a stepping stone when needed. Eliminate Tier 3 usage entirely.

Implementing Clean Core

Moving to Clean Core is not a weekend project. It is a multi-phase transformation that touches development practices, governance, architecture, and organizational culture. Here is a practical implementation approach.

Step 1: Assess Your Current State

Before you can plan a migration, you need to know where you stand:

Run the Custom Code Migration App in S/4HANA to analyze all custom objects
Identify which custom objects use unreleased SAP APIs
Classify custom code by business criticality (critical, important, nice-to-have, obsolete)
Measure your current modification count and enhancement footprint
Document all direct database access patterns (SELECT on SAP tables)

Step 2: Classify Custom Code

Sort every custom object into one of these categories:

Retire: Code that is no longer needed or duplicates standard functionality. This is typically 30 to 50 percent of the total.
Remediate: Code that can be refactored to use released APIs while staying in-system. Replace direct table access with CDS views, swap unreleased function modules for released equivalents.
Relocate: Code that should move to BTP as a side-by-side extension. Typically applies to custom applications, reporting tools, and integration logic.
Retain (temporarily): Code that must stay as-is in the short term but gets wrapped in Tier 2 patterns to isolate the unreleased API dependency.

Step 3: Plan the Migration

Build a phased roadmap:

Phase 1: Retire obsolete code and establish Clean Core governance for all new development
Phase 2: Remediate high-impact custom code to use released APIs
Phase 3: Relocate side-by-side extension candidates to BTP
Phase 4: Wrap remaining unreleased API usage in Tier 2 patterns
Phase 5: Continuous improvement as SAP releases new APIs

Step 4: Execute

Follow these technical practices during execution:

Enable ABAP Cloud development model for all new custom code packages
Configure ATC checks with Cloud-readiness rules in your CI/CD pipeline
Build wrapper classes around unreleased SAP objects you cannot avoid today
Establish API governance so new integrations use released OData or SOAP services
Set up BTP subaccounts and entitlements for side-by-side extension development

Step 5: Establish Governance

Clean Core is not a one-time cleanup. It is an ongoing discipline:

Gate all new custom development through Clean Core architecture reviews
Run monthly ATC reports to track Clean Core compliance metrics
Maintain a backlog of unreleased API dependencies targeted for elimination
Review SAP release notes for newly released APIs that enable migration of remaining Tier 2 code

Clean Core Maturity Model

Use this five-level framework to assess and communicate your organization's Clean Core progress.

Level 1: Unmanaged

Custom code is everywhere. No governance over modifications. Upgrades are painful multi-month projects. The organization has no inventory of custom objects or their dependencies.

Level 2: Aware

The organization has inventoried its custom code. Business criticality classifications exist. There is awareness of Clean Core principles, but no active migration. New development may or may not follow Clean Core patterns.

Level 3: Governed

Clean Core governance is in place for all new development. ATC Cloud-readiness checks are enforced in the development pipeline. Obsolete custom code is being retired. A migration roadmap exists with committed timelines.

Level 4: Compliant

The majority of custom code follows ABAP Cloud Tier 1 patterns. Side-by-side extensions on BTP handle most custom functionality. Remaining Tier 2 wrappers are documented with migration plans. Upgrades are low-risk, predictable events.

Level 5: Optimized

The core is fully standard. All extensions use released APIs or run on BTP. Upgrades are automated or near-automated. The development team innovates rapidly using BTP services without core dependencies. The organization fully benefits from SAP's continuous innovation cycle.

Most enterprises today fall between Level 1 and Level 2. The goal is to reach Level 4 within two to three years of starting the journey.

Real-World Examples

Scenario 1: Custom Pricing Logic

Before Clean Core: A manufacturer built custom pricing calculations by modifying the standard pricing procedure with a Z-routine that reads directly from custom Z-tables and calls unreleased pricing function modules. Every support pack requires regression testing of the entire order-to-cash process.

After Clean Core: The pricing logic is rebuilt using a released BAdI for pricing enhancements. Custom pricing data is stored in a custom RAP business object with a released API. The calculation logic uses only released CDS views for master data access. Support packs apply without pricing-related regression.

Scenario 2: Warehouse Integration

Before Clean Core: A custom RFC function module pulls inventory data by reading directly from MARD, MCHB, and LIPS tables. A custom ABAP program transforms the data and sends it to a third-party warehouse management system via a custom TCP/IP connection. The integration breaks regularly when SAP changes table structures.

After Clean Core: The inventory data flows through SAP's released Inventory Management OData APIs. An integration flow on SAP Integration Suite transforms the data and routes it to the warehouse system using a standard REST adapter. The core system has zero custom code for this integration.

Scenario 3: Employee Onboarding Portal

Before Clean Core: A custom BSP application embedded in the SAP GUI reads HR master data from PA infotypes directly. Custom workflow triggers are hardcoded into personnel action processing. The UI looks like it was designed in 2005 because it was.

After Clean Core: A modern onboarding application is built on BTP using SAP Build Apps. It consumes SuccessFactors APIs for HR data and S/4HANA released APIs for organizational data. SAP Build Process Automation handles the workflow. The application has its own release cycle and can be updated without touching the core.

Common Objections and Responses

"We need our custom code. Our business processes are unique."

Every organization believes its processes are unique. In most cases, 80 percent of custom code addresses requirements that SAP standard now handles or that could be met with configuration. The remaining 20 percent is genuinely differentiating, and that is exactly what BTP extensions and ABAP Cloud in-app extensions are designed for. Clean Core does not eliminate custom code. It puts it in the right place.

"BTP is expensive. We cannot justify the additional licensing costs."

This is a valid concern, but it requires a total cost of ownership analysis. Compare BTP licensing costs against the fully loaded cost of your current modification maintenance: developer hours for upgrade regression testing, delayed patches creating security risk, the opportunity cost of features you cannot adopt. For most enterprises, the math favors Clean Core within two to three years.

Also consider that SAP is increasingly bundling BTP credits with S/4HANA Cloud licenses. The commercial model is evolving to support the Clean Core architecture.

"Our developers only know classic ABAP. We do not have BTP skills."

This is a real barrier, but it is a training problem, not an architectural one. ABAP Cloud is still ABAP. Your developers' core skills transfer directly. The learning curve is about understanding the released API catalog and the RAP programming model, not learning a new language. For BTP development, SAP CAP uses JavaScript or Java, and many ABAP developers find the transition manageable with structured training.

"SAP does not have released APIs for everything we need."

This is true today, and it is the most legitimate objection. SAP's released API catalog has gaps. The Tier 2 wrapper pattern exists precisely for this reason. Wrap the unreleased dependency, document it, and plan to replace the wrapper when SAP releases the API. Meanwhile, actively request the APIs you need through SAP Influence. SAP is prioritizing API releases based on customer demand.

Getting Started

The right starting point depends on where your organization sits today.

If You Are Pre-S/4HANA Migration

You are in the best position. Build Clean Core principles into your S/4HANA migration from day one:

Use the Custom Code Migration App during your assessment phase
Adopt a "fit-to-standard" approach for process design
Mandate ABAP Cloud for all new custom development in the target system
Architect your BTP landscape alongside your S/4HANA deployment

If You Are on S/4HANA but Have Heavy Customizations

Start with governance and incremental improvement:

Enable ATC Cloud-readiness checks and run a baseline assessment
Implement Clean Core governance for all new development immediately
Prioritize retiring obsolete custom code since this is the fastest win
Build a migration roadmap for the remaining custom code

If You Are Already Cloud-Minded but Need Structure

Focus on maturity and optimization:

Formalize your Clean Core maturity assessment using the framework above
Set measurable targets for Tier 1 ABAP Cloud compliance percentage
Establish a Center of Excellence for BTP extension development
Automate your compliance monitoring with CI/CD-integrated ATC checks

Universal First Steps

Regardless of your starting point, these actions apply to everyone:

Run the Custom Code Migration App and export the results. You cannot manage what you do not measure.
Enable ATC Cloud-readiness checks in your development system. Even if you do not enforce them yet, visibility changes behavior.
Stop the bleeding. Mandate that all new custom development follows ABAP Cloud patterns. Do not add to the technical debt while you plan to reduce it.
Educate your team. SAP's Clean Core learning journey on SAP Learning is free and comprehensive. Get your developers through it.
Start one pilot. Pick a single custom application or integration and migrate it to the Clean Core pattern. Use it to build organizational muscle and demonstrate the approach.

Clean Core is not a theoretical framework. It is a practical architecture pattern with real tooling, real governance processes, and real benefits. The organizations that adopt it now will be the ones that can absorb SAP's innovation at the pace SAP delivers it. The ones that do not will find themselves in the same upgrade trap they have been in for the last two decades, just with a more modern system underneath.

The best time to start was when you first heard the term. The second best time is now.