Clean Core After 2027: What SAP Actually Expects

SAP has set a deadline. Mainstream maintenance for ECC ends in 2027. After that, organisations on ECC can pay for extended maintenance, but SAP's investment, its roadmap and its support energy shift entirely to S/4HANA.

Most conversations about this deadline focus on migration timelines. This piece focuses on what comes after: what does a clean S/4HANA core look like in practice, what does SAP expect you to maintain, and where do the organisations that have already migrated run into trouble?

This piece is for SAP programme leads, enterprise architects and CTOs managing an S/4HANA landscape or planning a migration.

The short version

Clean Core is not a one-time migration decision. It is an operating discipline that determines whether your S/4HANA system stays upgrade-safe or drifts back into the customisation debt that made ECC painful. SAP expects you to keep the core untouched and extend through approved channels.

• Clean Core means no modifications to SAP standard code, business objects or database tables.
• Extensions go through RAP, BTP or approved extension points — never through direct core changes.
• Custom code that exists today needs to be classified: keep, refactor to an extension, or retire.
• SAP will enforce Clean Core compliance through upgrade checks and certification.
• The discipline is ongoing. Every enhancement request is a Clean Core decision.

This article sits inside the sap s/4hana, clean core and rap cluster, where the wider argument is set out in full.

What Clean Core actually prohibits

Clean Core is a clear set of rules about what you may not do inside S/4HANA:

No modifications to SAP standard code. You may not change delivered ABAP programs, function modules, classes or methods. No modification assistants, no user exits that alter standard logic, no implicit enhancements on standard code.

No custom database tables that shadow standard tables. Custom Z-tables that duplicate data from standard tables, often used to work around performance issues or missing fields in ECC, are not part of Clean Core.

No direct access to standard database tables from custom code. Custom programs should access data through released CDS views and APIs, not through direct SQL on SAP tables. SAP reserves the right to change internal table structures; code that accesses them directly breaks during upgrades.

No custom transactions that bypass standard processes. Custom ABAP reports that read from or write to SAP tables without going through the standard business object layer undermine the integrity of the core.

These rules are not new ideas. SAP has recommended them for years. What changes after 2027 is enforcement. SAP is building compliance checks into the upgrade process. Systems that violate Clean Core principles will face harder upgrades, and some cloud features will require compliance.

Should your organisation do this now?

• Yes, if you have migrated to S/4HANA and have not classified your custom code.
• Not yet, if you are still on ECC and the migration has not started.
• Instead, first: plan the migration; Clean Core classification is part of that planning.
• Measure it by: percentage of custom code classified as keep, refactor or retire.

The custom code conversation

Every ECC system accumulates custom code. A typical large ECC landscape has between five thousand and fifty thousand custom objects — programs, function modules, includes, enhancements. Most of them were written to solve a real problem at the time. Many of them are no longer used or relevant.

The Clean Core discipline requires classifying every custom object into one of three categories:

Retire. Code that is no longer used, references obsolete processes, or duplicates standard functionality that now exists in S/4HANA. In my experience, this is forty to sixty per cent of custom code. Nobody misses it.

Refactor to an extension. Code that provides genuine business value but violates Clean Core principles. It accesses standard tables directly, modifies standard logic, or sits inside the core where it blocks upgrades. This code must be rewritten as an extension using RAP, deployed to BTP, or restructured to use released APIs and extension points.

Keep as-is. Code that provides business value and already complies with Clean Core — it uses released APIs, does not modify standard objects, and does not access internal tables. This code can stay, but it still needs an owner and periodic review.

The hardest category is refactor. It requires understanding what the code does, why it was built, whether the underlying business need still exists, and how to achieve the same outcome through approved extension points. This is skilled, time-consuming work.

RAP: the extension model SAP is betting on

The RESTful Application Programming Model (RAP) is SAP's framework for building extensions that stay outside the core. It provides:

Business object definitions. A structured way to define custom business objects with CDS views, behaviour definitions and service bindings. These objects are self-contained and do not modify standard SAP business objects.

Strict mode. RAP can run in strict mode, which enforces Clean Core compliance at development time. Code in strict mode cannot access unreleased SAP objects, cannot use obsolete ABAP statements, and cannot bypass the framework's architectural rules. This is SAP's way of making Clean Core enforceable in the development environment.

Cloud-ready development. RAP on S/4HANA Cloud uses a restricted ABAP language version that excludes statements and features incompatible with the cloud. Even on S/4HANA on-premise, developing in this restricted mode prepares code for a future cloud transition.

RAP has a learning curve. Developers accustomed to classical ABAP reports, BAPIs and user exits need to learn a new architecture. The investment is worthwhile because RAP-compliant code is upgrade-safe by design.

Should your organisation do this now?

• Yes, if you are building new extensions for S/4HANA and not yet using RAP.
• Not yet, if your developers have not been trained on RAP and CDS.
• Instead, first: invest in RAP training before your next extension project.
• Measure it by: percentage of new extensions built with RAP versus classical development.

The ongoing discipline

Clean Core is not a project. It is a standing policy that applies to every change request, every enhancement, every bug fix.

Every time someone asks for a change to the SAP system, the answer must pass through a Clean Core filter:

1. Can this be done with standard configuration? If yes, configure it. No custom code needed. 2. Can this be done with a released extension point? If yes, build the extension using RAP or a BTP extension. 3. Does this require modifying the core? If yes, push back. Find an alternative approach, or accept the limitation. Only in genuinely exceptional circumstances — and with documented architectural approval — should a core modification be considered, and even then, understand that it will create an upgrade burden.

This filter needs to be enforced by the enterprise architect or the SAP Centre of Excellence, not by individual developers. Developers face pressure from business users to deliver fast. Without institutional support for Clean Core, the pressure wins and the core gets dirty again.

What happens if you ignore it

Organisations that do not maintain Clean Core discipline will face three consequences as SAP evolves:

Harder upgrades. SAP releases updates and feature packs on a regular cycle. Customised cores require regression testing for every update, and some updates will conflict with modifications. The upgrade effort scales with the number of core modifications.

Excluded from cloud features. SAP is investing in cloud-native capabilities that assume a clean core. Organisations with modified cores may not be able to adopt these features, or may need significant rework to qualify.

Higher support costs. SAP support for issues caused by custom modifications is limited. If a problem occurs in code that SAP did not write or in a modification that SAP did not approve, the support case may be closed as a customer responsibility.

None of these consequences are immediate. They accumulate over years. That is what makes them dangerous — the cost is easy to defer and hard to see until it is very large.

Before you commit

Checklist:

• Complete custom code inventory with usage data from production.
• Classification completed: retire, refactor or keep for every custom object.
• RAP development standards documented and training completed for SAP developers.
• Clean Core compliance check added to the change management process.
• BTP evaluation completed for extensions that do not fit RAP on S/4HANA.
• Architecture review board with authority to reject core modifications.

Questions to ask:

• Your SAP team: how many custom objects are in the system, and what percentage are actively used?
• Your developers: are new extensions being built with RAP, or with classical ABAP?
• Your architect: do we have a policy for rejecting core modifications, and is it enforced?
• Your SAP account manager: what is the timeline for Clean Core compliance checks in upgrades?
• Your business: which custom processes would be affected if we retired unused custom code?

How to measure it

• Custom code retirement. Percentage of custom objects classified as "retire" that have been removed. Baseline: classification results. Owner: SAP Centre of Excellence. Review: quarterly. Leading.
• RAP adoption. Percentage of new extensions built with RAP. Baseline: current development. Owner: development lead. Review: quarterly. Leading.
• Core modification count. Number of active core modifications. Baseline: current inventory. Owner: enterprise architecture. Review: quarterly. Leading.
• Upgrade readiness. Time required for upgrade regression testing. Baseline: last upgrade. Owner: SAP basis team. Review: per upgrade. Lagging.
• Clean Core compliance score. SAP's own compliance measurement when available. Baseline: first assessment. Owner: SAP Centre of Excellence. Review: semi-annual. Lagging.

Mistakes that cost the most

Treating Clean Core as a migration activity

The core is cleaned during migration and then modifications restart.

• Why it happens: Clean Core was positioned as part of the migration project, not as ongoing discipline.
• Prevention: establish Clean Core as a standing policy with enforcement.
• Early warning: core modifications requested within six months of migration.

Not training developers on RAP

Developers continue building extensions with classical ABAP techniques.

• Why it happens: RAP training was not prioritised alongside the migration.
• Prevention: complete RAP training before the first extension project on S/4HANA.
• Early warning: new custom code that does not use CDS views or behaviour definitions.

Retiring code without checking usage

Code classified as unused turns out to be running a critical month-end process.

• Why it happens: usage analysis was based on daily transaction logs, missing periodic processes.
• Prevention: measure usage over a full business cycle, minimum twelve months.
• Early warning: retired code causes a production issue.

What to do next

Run a custom code inventory with usage statistics from production. Classify each object into retire, refactor or keep. Start with retirement — it is the lowest-risk, highest-impact step. Then read the related piece on your BTP decision and the SAP Clean Core topic page.

Last reviewed: 14 October 2026.

Views are my own and do not represent my employer.