Clean Core
An architectural principle promoted by SAP requiring that the S/4HANA standard core remain unmodified, with all extensions implemented through released APIs, the BTP extension framework or side-by-side extensions, so that the core can evolve smoothly during system upgrades.
Timeline (last 90 days)
SAP's community guidance acknowledges that the old binary view (Clean Core vs. not Clean) is too strict for systems with large amounts of classic custom code.
ABAP Test Cockpit (ATC) is SAP's built-in static code inspection framework, which can identify syntax risks, performance anti-patterns, security vulnerabilities and usages that violate Clean Core standards, producing a list of objects that must be rewritten and those that can be downgraded or retired.
Custom code remediation (to comply with Clean Core principles) may cost $200,000 to $4 million one-time, with the difference depending almost entirely on the composition of the custom code rather than its volume.
The typical distribution in industry migration assessments shows that about 45% of enterprise custom code is unused dead code, about 25% duplicates standard functionality, about 20% can be trivially replaced, and about 10% is genuinely differentiating logic.
Audit results still require business confirmation and cannot be mechanically deleted, because some code is only triggered during annual settlement or extreme exceptions.
Advancing Clean Core should be tied to business goals such as S/4 migration, new AI capabilities or operating model transformation, rather than being a standalone "virtue project".
An enterprise cannot clean up twenty years of accumulated custom code in one project; it can only stop making it worse and let time do the work.
Before moving code, first define its behavioral contract with an OpenAPI specification; if a team cannot write an OpenAPI document for a piece of logic, it means they do not understand the real requirements of that logic.
The official definition of Clean Core contains three levels: no modification (not directly changing standard code), no implicit extension (not relying on unpublished internal interfaces, tables or function modules), and contract-based extension (all custom logic interacting with the core through published APIs, BAdIs or BTP services).
AI can collaborate with anything that has a contract, but cannot collaborate with "folklore"-style extensions that have no documentation and no contract; Clean Core is the process of turning folklore into contracts.
2 more timeline events
All Facts (12)
SAP's community guidance acknowledges that the old binary view (Clean Core vs. not Clean) is too strict for systems with large amounts of classic custom code.
50%UnverifiedABAP Test Cockpit (ATC) is SAP's built-in static code inspection framework, which can identify syntax risks, performance anti-patterns, security vulnerabilities and usages that violate Clean Core standards, producing a list of objects that must be rewritten and those that can be downgraded or retired.
50%UnverifiedCustom code remediation (to comply with Clean Core principles) may cost $200,000 to $4 million one-time, with the difference depending almost entirely on the composition of the custom code rather than its volume.
50%UnverifiedThe typical distribution in industry migration assessments shows that about 45% of enterprise custom code is unused dead code, about 25% duplicates standard functionality, about 20% can be trivially replaced, and about 10% is genuinely differentiating logic.
50%UnverifiedAudit results still require business confirmation and cannot be mechanically deleted, because some code is only triggered during annual settlement or extreme exceptions.
50%UnverifiedAdvancing Clean Core should be tied to business goals such as S/4 migration, new AI capabilities or operating model transformation, rather than being a standalone "virtue project".
50%UnverifiedAn enterprise cannot clean up twenty years of accumulated custom code in one project; it can only stop making it worse and let time do the work.
50%UnverifiedBefore moving code, first define its behavioral contract with an OpenAPI specification; if a team cannot write an OpenAPI document for a piece of logic, it means they do not understand the real requirements of that logic.
50%UnverifiedThe official definition of Clean Core contains three levels: no modification (not directly changing standard code), no implicit extension (not relying on unpublished internal interfaces, tables or function modules), and contract-based extension (all custom logic interacting with the core through published APIs, BAdIs or BTP services).
50%UnverifiedAI can collaborate with anything that has a contract, but cannot collaborate with "folklore"-style extensions that have no documentation and no contract; Clean Core is the process of turning folklore into contracts.
50%UnverifiedClean Core is an architectural principle that SAP has heavily promoted in recent years, whose core requirement is to keep the S/4HANA standard core unmodified by customers (no modifying standard code, no directly writing to standard tables), with all extensions implemented through released APIs, the BTP extension framework, or side-by-side extensions.
50%UnverifiedThe promise of Clean Core is that upgrades do not break standard functionality, and combined with the continuous improvement delivery model, this ensures that once AI extensions are built, they will not have to be torn down and rebuilt because of the next upgrade.
50%