SAP Clean Core in 2026: What It Means and How to Achieve It

Photo by AlphaTradeZone on Pexels

I have sat in enough SAP transformation steering committees to recognize a recurring pattern: the conversation starts with ambitious plans for a clean, modern core, and within six months it devolves into an argument about which of the fifteen hundred Z-programs need to be "just slightly modified" for S/4HANA. The argument is never really about the code. It is about organizational identity, switching costs, and the uncomfortable reality that years of custom development represent years of organizational knowledge encoded in ABAP — knowledge that may not have been adequately documented anywhere else.

SAP Clean Core is, at its heart, a philosophy for breaking that cycle. It is also a concrete set of technical constraints, tooling, and architectural patterns that SAP has built into its platform. In 2026, with Rise with SAP adoption accelerating and cloud deployments overtaking on-premise new installations, Clean Core is no longer a theoretical ideal — it is the operating model that determines whether your next upgrade takes three months or three years.

This article covers everything from the official definition to the implementation realities, including the political problems that the technical guidance tends to omit.

1. What SAP Clean Core Actually Means

The official SAP definition of Clean Core states that a clean core is an SAP system that is "upgraded without modification" — where customizations follow standard extension methods, data is correct and complete, integrations use stable APIs, and operations follow SAP's standard processes. SAP summarizes this as five dimensions: Process, Software, Data, Integration, and Operations.

The reality in most organizations is significantly more complicated. The phrase "without modification" sounds absolute, but the practical interpretation is: modifications are acceptable when they use SAP's supported extension framework, specifically ABAP Cloud for on-stack extensions. The distinction matters enormously because it determines what needs to be rewritten and what can be refactored.

The Official vs. Practical Definition

The official definition focuses on upgrade compatibility. If your customizations use released APIs and follow ABAP Cloud rules, SAP commits to maintaining those interfaces across upgrades. Your code will not break when SAP updates the underlying standard objects. That is the contract.

The practical definition, which I find more useful when advising customers, is: Clean Core is the set of practices that ensure your SAP system's total cost of ownership decreases over time rather than increasing. Every custom program that directly modifies standard tables, every enhancement that uses internal APIs, every integration that calls deprecated function modules — these are technical debt entries with compound interest. Clean Core is the strategy for not accumulating more debt and for systematically reducing what you already carry.

A useful analogy: Clean Core is less like cleaning a messy room and more like switching from a manually managed filing system to a database with referential integrity. The immediate effort is painful. The long-term operational benefit — predictable behavior, reliable search, no phantom dependencies — changes the fundamental economics of the system.

2. Why Clean Core Matters: The Upgrade Complexity Problem

The business case for Clean Core is straightforward when you have access to upgrade project data. In my experience working with SAP customers, the elapsed time for an on-premise ECC to S/4HANA migration correlates more strongly with the size of the custom code footprint than with almost any other factor. Organizations with hundreds of Z-programs requiring review and remediation face multi-year transformation programs. Organizations that had maintained stricter custom code discipline face programs measured in months.

The financial impact follows the same pattern. A 2023 SAP user group study found that organizations with significant custom code modifications spent, on average, 2.3x more on their S/4HANA migration than organizations that had kept closer to standard. The multiplier compounds when you account for the ongoing cost of maintaining custom code through continuous upgrades — in a cloud world, SAP releases four major updates per year. Testing and validating custom code against four annual releases, multiplied across a large Z-program portfolio, becomes a significant ongoing operational expense.

The Total Cost of Ownership Argument

TCO in an SAP context has a component that rarely appears in formal cost models: the cost of organizational knowledge trapped in custom code. When an experienced ABAP developer who built a critical custom module leaves the organization, some portion of the business logic embedded in that code may not be recoverable from documentation. Organizations have made significant business decisions — changes to pricing logic, regulatory compliance implementations, workflow alterations — and documented them only in ABAP. This is not hypothetical. I have been in migration projects where the team spent weeks reverse-engineering Z-programs to understand what business rule they implemented, because the original developers were no longer available and no functional specification had been maintained.

Clean Core addresses this by pushing complexity to documented, standard processes wherever possible, and by constraining extensions to frameworks that produce more maintainable, self-documenting artifacts.

3. The Five Dimensions of Clean Core

Photo by fauxels on Pexels

SAP structures Clean Core across five dimensions. Understanding each dimension and the practical interventions available in each is essential for building a credible Clean Core roadmap.

Dimension 1: Process

Process Clean Core means adopting SAP standard processes rather than building custom processes. This is the most contested dimension because it touches organizational change management directly. Business units that have operated on custom workflows for a decade resist being told that the standard process is better. Often they are right that the standard process does not perfectly match their current operations — but the question is whether the current operations represent a genuine competitive differentiator or simply historical practice that has calcified.

The analytical framework I use: for each custom process, ask whether this process is something the organization would list as a competitive strength in a customer conversation. Accounts payable processing that uses a custom dunning workflow is unlikely to be a competitive differentiator. A custom pricing algorithm that reflects a genuinely unique go-to-market model might be. The former should adopt standard; the latter deserves careful consideration of extension options.

Dimension 2: Software

Software Clean Core focuses on the custom code footprint in the SAP system. The principle is: extensions should use ABAP Cloud (in-app, on-stack) or BTP extensions (side-by-side) rather than direct modification of SAP-delivered objects. This dimension is the most technically concrete of the five, which is why most Clean Core tooling and measurement focuses here.

Key practices include: not using SAP internal APIs (those prefixed with underscore or marked as "not released"), not modifying standard tables directly, not using classic BAdIs or user exits where released BAdI definitions exist, and following ABAP Cloud's syntax and object restriction rules.

Dimension 3: Data

Data Clean Core encompasses master data quality, data governance, and ensuring that data conforms to SAP's standard data model rather than being shaped to accommodate custom processes. In practice, this often means reducing duplicate material master records created by poor governance, standardizing customer and vendor hierarchies, and removing custom fields added to standard tables (which create upgrade risk and can cause performance issues).

Data quality work is often underestimated in transformation projects. I have seen migration timelines slip by six months purely because the data cleansing required to migrate from a non-standard legacy data model into S/4HANA's simplified data structures was more extensive than initial assessments suggested.

Dimension 4: Integration

Integration Clean Core means using SAP's stable, released APIs for all integrations — both inbound and outbound — rather than database-level integrations, RFC calls to internal function modules, or point-to-point connections that bypass the standard integration layer. SAP's API Business Hub catalogs the released APIs available for each product. The principle is simple: if the API you are calling is not in the Business Hub as a released API, you are taking an upgrade compatibility risk.

In practice, integration is often the dimension with the most legacy technical debt. Many organizations have integration landscapes built over fifteen years that include IDOC-based integrations, custom RFC calls, direct table reads, and file-based interfaces. Bringing these to Clean Core standard requires a systematic integration inventory and a migration path for each interface.

Dimension 5: Operations

Operations Clean Core means adopting SAP's standard operational tooling — monitoring, alerting, transport management, system landscape management — rather than building or buying custom operational tools that create dependencies outside SAP's supported framework. In a Rise with SAP cloud context, this dimension also encompasses adopting SAP's cloud ALM (Application Lifecycle Management) platform rather than maintaining separate operational tooling.

4. ABAP Cloud: The Technical Foundation

ABAP Cloud is SAP's specification for clean, upgrade-safe ABAP development. It is not a new programming language but a constrained development model that enforces Clean Core rules at compile time and during static analysis. Understanding ABAP Cloud is essential for any ABAP developer working on an S/4HANA system in 2026.

Core Constraints

ABAP Cloud enforces three principal constraints:

Use only released APIs. ABAP Cloud objects can only consume development objects that have been explicitly released by SAP or by the customer's own released API layer. Attempting to use a non-released SAP function module in an ABAP Cloud program produces a syntax error or ATC error, not a runtime warning. This is enforcement at the development tool level, not just a guideline.

Use only the ABAP Cloud language subset. Certain ABAP statements that are incompatible with cloud deployment or that have been superseded by cleaner alternatives are not available in ABAP Cloud objects. Examples include direct Open SQL without client-safe constructs, certain legacy data type declarations, and statements that assume single-system deployment.

Respect the system boundary. ABAP Cloud objects in a customer extension must remain within the defined extension layer. They cannot modify SAP-delivered repository objects.

ABAP Cloud Development Objects

In practice, ABAP Cloud development uses a specific set of object types: ABAP classes and interfaces (not function groups or classic includes), CDS (Core Data Services) views with released annotations, RAP (RESTful Application Programming) business objects for transactional applications, and released BAdI definitions for enhancement spots.

The RAP model deserves particular attention because it represents the most significant architectural change for ABAP developers. RAP provides a standardized way to build transactional applications with built-in support for draft handling, optimistic locking, and OData exposure — capabilities that previously required significant custom implementation work. Once a team understands RAP, development velocity for standard business object extensions typically improves. The learning curve, however, is real and should be factored into any Clean Core roadmap timeline.

5. Released APIs: The Principle and the Practice

The released API principle is intellectually simple: only use what SAP has committed to maintaining. The practice is more nuanced because the released API catalog is not complete. There are functional areas where business requirements exist but no released API covers them. In those cases, the options are:

1. Submit an API request to SAP (viable for standard requirements that other customers likely share)
2. Use a side-by-side BTP extension that accesses only the data exposed through released APIs
3. Accept the upgrade risk of using a non-released API, document the dependency, and plan for migration in a future release
4. Reconsider whether the requirement genuinely needs to be met through custom code

Option 3 exists in practice even in the most disciplined organizations — SAP's released API coverage, while improving with each release, is not exhaustive. The key is making the decision explicitly and knowingly, rather than discovering undocumented non-released API dependencies during an upgrade project.

Traditional ABAP Development vs. ABAP Cloud: Key Differences

Dimension	Traditional ABAP	ABAP Cloud
API usage	Any SAP function module or class	Released APIs only; enforced at compile time
Object modification	Direct modification of SAP objects permitted	SAP objects read-only; extension via BAdI/RAP
Upgrade compatibility	Manual review and remediation per upgrade	SAP-committed compatibility on released APIs
Development model	Function groups, includes, classic classes	Classes, interfaces, CDS, RAP business objects
Testing support	Limited; test doubles require significant effort	ABAP Unit with test doubles, ABAP Test Cockpit
Cloud deployment	On-premise or private cloud only	Compatible with public cloud deployment
SAP update impact	Potential breaking changes require manual validation	Breaking changes prevented by SAP compatibility commitment

6. BTP Extension Patterns: Side-by-Side vs. In-App

Photo by Ron Lach on Pexels

When custom requirements cannot be met through standard configuration or in-app ABAP Cloud extensions, SAP BTP (Business Technology Platform) provides the side-by-side extension pattern. Understanding when to use each pattern is one of the more consequential architectural decisions in an S/4HANA implementation.

In-App Extensions (ABAP Cloud)

In-app extensions run inside the S/4HANA system, written in ABAP Cloud. They are appropriate when:

• The extension requires tight transactional coupling with core SAP data — for example, custom validations on sales order creation that must execute within the same database transaction
• Performance requirements demand proximity to the core data — additional hops to an external BTP service introduce latency that is unacceptable for the use case
• The extension primarily enriches or validates standard SAP objects rather than building new standalone applications
• The development team has deep ABAP expertise and limited cloud-native skills

The constraint is that in-app extensions are limited to ABAP Cloud's released API surface. If the required integration point has no released API, in-app extension is not viable through compliant means.

Side-by-Side Extensions (BTP)

Side-by-side extensions run on BTP, separate from the S/4HANA system, communicating via standard APIs. They are appropriate when:

• The extension involves significant business logic that is conceptually separate from core SAP processes
• The extension needs to integrate data from multiple SAP systems or third-party sources
• The development team includes cloud-native developers (Node.js, Python, Java) without deep ABAP expertise
• The extension needs capabilities not available in the ABAP stack: machine learning, document processing, complex workflow orchestration
• The extension should be independently deployable and scalable from the core SAP system

The tradeoff is operational complexity. A side-by-side extension requires BTP infrastructure management, API connectivity configuration, identity propagation, and monitoring that is separate from the core SAP system operations. Organizations that adopt BTP extensively should invest in a BTP platform team and BTP operational practices, not just BTP development skills.

7. Custom Code Migration Tool: Your Starting Point

SAP's Custom Code Migration Tool (CCMT) is the standard starting point for any serious Clean Core assessment. It connects to a source ECC or S/4HANA system, analyzes the custom code repository against a set of defined target scenarios (S/4HANA on-premise, S/4HANA Cloud public edition, etc.), and produces a remediation report categorizing each custom object.

The output categories are:

• Compatible: No changes required for the target scenario
• Adapted: Object can be adapted with defined changes
• Replaced: Object should be replaced by standard functionality
• Removed: Object is no longer needed or used
• Side-by-side: Object should be reimplemented as a BTP extension

In my experience, the CCMT report is a necessary input to a Clean Core roadmap but not a sufficient one. It tells you what the technical state of each object is, but not the business priority of remediating it. Overlaying usage data — which Z-programs are actually being executed, with what frequency, by how many users — is essential for prioritization. An object that CCMT flags as non-compliant but that runs zero times per month is a different remediation priority than a non-compliant object that processes thousands of transactions daily.

Practical tip: SAP provides usage data through the Custom Code Analysis in CCMT, which integrates with system measurement data. Before any remediation sprint, run a combined analysis that shows both the Clean Core compliance status and the execution frequency of each object. Prioritize remediating high-frequency, non-compliant objects first — these represent both the highest risk and the highest ROI for remediation effort.

8. ATC Clean Core Validation: Continuous Compliance

The ABAP Test Cockpit (ATC) is SAP's static analysis framework for ABAP, and its Clean Core checks are the primary mechanism for continuous validation of ABAP Cloud compliance. ATC can be configured to run automatically on every code transport, blocking non-compliant code from progressing through the landscape.

The default ATC configuration includes general code quality checks, but Clean Core compliance requires explicitly enabling the "ABAP Cloud readiness" check categories. Once enabled, ATC will flag:

• Usage of non-released APIs
• Direct modification of SAP standard objects
• Use of deprecated ABAP syntax not compatible with ABAP Cloud
• Missing or incorrect C1 or C2 API release declarations on customer-created APIs

The ATC-in-transport configuration — where ATC checks run automatically when a developer releases a transport request — provides a gating mechanism that prevents new Clean Core violations from being introduced. This is the ABAP equivalent of a CI quality gate: catching violations at commit time rather than at upgrade time.

For existing codebases with a large legacy footprint, enabling strict ATC blocking immediately will halt development. The recommended approach is to start with warning mode, establish a baseline of existing violations, and then set an improvement target — for example, no increase in the violation count, with a quarterly reduction goal. New development in dedicated Clean Core packages can be held to a stricter standard from day one.

9. Rise with SAP and Clean Core: Why the Connection Is Structural

Rise with SAP is SAP's bundled offering for cloud transformation, including S/4HANA Cloud private or public edition, BTP entitlements, and services. The connection to Clean Core is not incidental — Rise with SAP cloud deployments are maintained by SAP, and SAP cannot maintain a system with arbitrary custom modifications. Clean Core is a prerequisite for being on a SAP-managed cloud deployment, not a best practice alongside it.

For S/4HANA Cloud public edition — the highest level of standardization — the constraint is even more direct. Public cloud edition does not support custom ABAP development inside the core at all. Extensions must be ABAP Cloud extensions delivered through the extensibility framework, or side-by-side BTP extensions. Organizations that have relied on traditional ABAP modifications for critical business processes must either find released API equivalents or move those processes to BTP before a public cloud migration is feasible.

This is the structural reason why Clean Core has become a strategic priority rather than a technical recommendation. The cloud deployment model that SAP is standardizing on requires it. Organizations that ignore Clean Core are not simply taking on technical debt — they are constraining their future deployment options.

10. Evaluating Legacy ABAP: Refactor, Reimplement, or BTP

When a legacy ABAP program is identified as non-Clean Core compliant and as a high-usage, business-critical process, the remediation decision is rarely straightforward. Three options exist, each with different cost and risk profiles.

Refactor to ABAP Cloud

Refactoring reuses the existing business logic but rewrites it to comply with ABAP Cloud rules. This is appropriate when the program's logic is sound, the business process it implements is one the organization wants to keep, and the non-compliance is primarily about API usage patterns rather than architectural structure.

The prerequisite for successful refactoring is thorough test coverage — ideally ABAP Unit tests — that validates the business logic before and after refactoring. Organizations that lack automated tests for critical custom programs face significant regression risk when refactoring, because there is no automated way to verify that the refactored version produces the same outputs as the original.

Reimplement Using Standard Functionality

Reimplementation using standard SAP functionality is appropriate when the original custom program was built to fill a functionality gap that SAP has since closed in later releases. S/4HANA includes functionality that did not exist in ECC, and many custom programs from ECC migrations are solving problems that S/4HANA solves natively.

Identifying these cases requires close collaboration between functional consultants (who understand current standard functionality) and the business users who use the custom program (who can validate whether the standard equivalent meets their needs). In my experience, approximately 20–30% of high-usage custom programs in ECC-origin systems can be replaced by standard S/4HANA functionality with configuration, rather than custom code.

Reimplement on BTP

BTP reimplementation is appropriate when the program implements genuinely custom business logic that has no standard equivalent, and when the logic is complex enough that BTP's richer development environment (modern languages, microservices, event-driven patterns) is an advantage over ABAP. This path has the highest initial investment but produces an extension that is fully decoupled from the S/4HANA core upgrade cycle.

Decision framework:

Use refactor to ABAP Cloud when: logic is correct, API compliance is the primary issue, team has ABAP expertise, transactional coupling is required.

Use standard reimplementation when: standard functionality in S/4HANA covers the requirement, user acceptance of the standard process is achievable.

Use BTP reimplementation when: logic is genuinely complex and custom, team includes cloud-native skills, process can tolerate API-level rather than in-transaction integration.

11. Overcoming Organizational Resistance

Photo by fauxels on Pexels

The technical constraints of Clean Core are well-documented. The organizational resistance to adopting them is less discussed and, in my observation, is the primary reason Clean Core programs stall. Understanding the sources of resistance is necessary for addressing them effectively.

The "We Are Different" Objection

Business process owners frequently argue that their industry, their company, or their regulatory environment makes standard SAP processes inadequate. Sometimes this is true. More often, it reflects a combination of genuine process complexity, lack of familiarity with current standard functionality, and organizational inertia.

The effective response is not to argue that standard SAP is sufficient. It is to require a demonstration of the gap — specifically, what the standard process does and precisely what business outcome it fails to achieve. In my experience, this exercise regularly reveals that the "gap" is much smaller than assumed, or that it exists in a part of the process that represents a genuine competitive differentiator (and therefore deserves a proper extension) rather than a legacy practice that should be standardized.

The ABAP Developer Identity Problem

Experienced ABAP developers have built careers around deep knowledge of SAP's internal architecture — the standard tables, the internal APIs, the undocumented function modules that make complex things possible. ABAP Cloud threatens to devalue that knowledge by drawing a boundary around what is permitted. The resistance this generates is real and should be acknowledged rather than dismissed.

The most effective response I have seen is investment in upskilling: formal ABAP Cloud training, certification programs, dedicated Clean Core development sprints where developers practice the new patterns in a low-stakes context, and visible recognition of Clean Core expertise in career development conversations. Organizations that position Clean Core as an attack on their developers' expertise lose. Organizations that position it as a platform for building new expertise win.

The Short-Term Cost vs. Long-Term Benefit Problem

Clean Core remediation has costs that are immediate and visible — development time, testing effort, potential business disruption during process changes. The benefits — reduced upgrade costs, lower maintenance overhead, improved system stability — are deferred and harder to quantify. This is a classic organizational decision problem where the people bearing the immediate cost are often not the same people who will capture the long-term benefit.

Making the long-term benefit concrete is essential. I recommend building an upgrade cost model: estimate the cost of the next S/4HANA upgrade under two scenarios — current custom code footprint versus a target Clean Core posture. The difference between those two numbers is the business case for Clean Core investment. When that difference is twenty million dollars versus eight million dollars on the next upgrade, Clean Core remediation programs get funded.

12. Key Takeaways

Six things I have learned about SAP Clean Core implementation:

1. Clean Core is not about removing customization — it is about disciplining it. The goal is not a system with no custom code. The goal is a system where every piece of custom code uses supported, stable extension points that SAP has committed to maintaining.

2. Start with usage data, not compliance data. The CCMT report tells you which objects are non-compliant. Usage data tells you which ones matter. Prioritize remediation based on business impact, not alphabetical order.

3. ATC gating on transports is the structural control that prevents new debt accumulation. Everything else is catching up to existing debt. ATC enforcement stops the bleeding.

4. BTP is not a workaround for Clean Core — it is a legitimate extension channel. Side-by-side BTP extensions that use only released APIs are fully consistent with Clean Core principles. Organizations that think "move it to BTP" means avoiding Clean Core discipline are misunderstanding the model.

5. Rise with SAP cloud deployment makes Clean Core non-optional. If cloud is the destination, Clean Core is the prerequisite. The sooner this is communicated to business stakeholders as a constraint, not a preference, the earlier remediation work can begin.

6. Organizational resistance is the primary risk, not technical complexity. The technical path is clear. The change management work — with developers, with business process owners, with leadership — is where Clean Core programs succeed or fail.

Conclusion

SAP Clean Core in 2026 is no longer an aspirational roadmap item. For organizations moving to Rise with SAP or planning their next S/4HANA upgrade, it is an operational reality that determines how much that journey costs and how long it takes. The organizations that have invested in Clean Core practices — disciplined use of released APIs, ABAP Cloud development, BTP extensions for complex requirements — are compounding that investment with each SAP release. The organizations that have not are compounding their technical debt at the same rate.

The path forward does not require perfection from day one. It requires a credible inventory of the current state, a prioritized remediation plan based on usage data and business impact, ATC enforcement to prevent new violations, and a leadership commitment to treating Clean Core as a business requirement rather than a developer preference. That combination, sustained over two to three years, fundamentally changes the economics of SAP ownership.

Navigating SAP transformation? — Check out what I built