Every S/4HANA project eventually faces the same decision point: do we extend the SAP standard using clean core principles, or do we use a classic modification approach? The wrong choice doesn’t just create technical debt — it can block your next upgrade, increase your ATC check failure rate, and make the entire codebase harder to hand over.
This guide gives you a structured decision framework based on real project patterns, not just SAP’s official positioning.
First: What Do We Actually Mean by “Clean Core”?
SAP’s clean core concept means keeping the SAP standard as unmodified as possible, placing all custom logic outside the core using only released APIs and extension points. The practical outcome: your system can absorb SAP upgrades without a custom code regression cycle.
Classic extensibility, by contrast, uses modification frameworks (user exits, BADIs with classic implementation, function module substitutions, direct table writes) that are tightly coupled to SAP’s internal implementation — and that coupling breaks during major releases.
The Decision Framework: 5 Questions to Ask First
1. Is there a released BAdI or RAP extension point for what you need?
This is always question one. SAP releases new BAdIs and CDS extensibility annotations with every release. Before designing any extension, check the SAP Extension Point Catalog in the ADT (Eclipse) or via SAP’s documentation. If a released BAdI covers your use case, use it — this is always the cleanest path.
Decision: Released BAdI exists → Clean Core (BAdI implementation via ABAP Cloud)
2. Do you need to add fields to SAP standard objects?
Custom fields are one of the most common requirements. In S/4HANA Cloud and clean core on-premise, you have three compliant options: Custom Fields & Logic (CFL) app for simple fields, CDS View Extension for analytical fields, and Business Add-In (BAdI) with custom include tables for complex field structures. Classic approach would use append structures to DDIC tables — still possible on-premise, but a blocker for the cloud.
Decision: Cloud → CFL/CDS only. On-premise → CFL preferred; append structure acceptable if no cloud path planned.
3. Is your system on the cloud upgrade path (S/4HANA Cloud or Public Cloud)?
If you’re on S/4HANA Public Cloud or planning to move there, the decision is made for you: only released APIs and SAP-provided extension frameworks are available. There is no “classic” option. All extensions must be implemented in ABAP Cloud (ABAP for Cloud Development language version) or as BTP side-by-side extensions.
For on-premise S/4HANA customers, the same discipline makes future migrations tractable. Projects that go clean core now spend significantly less effort during selective or greenfield moves to the cloud.
4. What is the performance profile of the requirement?
Clean core extensions that run as side-by-side BTP services introduce network latency. For mass data processing — batch jobs, IDocs, or large-scale postings — synchronous remote calls to BTP are often not viable. In these cases, an in-process ABAP implementation (via released BAdI or RAP action) is the right architectural choice, even if a BTP service could technically handle the logic.
Decision: High-volume in-process → Use released in-ABAP extension point. Low-volume or async → BTP side-by-side is viable.
5. Does the requirement touch core financial postings, legal relevance, or audit trails?
Modifications to FI, CO, or legally relevant processes carry the highest risk. Classic modifications here (substitutions, validation exits, direct FI table manipulation) are notoriously difficult to maintain across releases and can cause data integrity issues. This is precisely where Document Splitting BAdIs, Substitution BAdIs, and the Business Eventing framework shine — they give you the required hook without owning the posting logic.
The Decision Matrix
| Scenario | Recommended Approach | Why |
|---|---|---|
| Released BAdI covers the use case | Clean Core (BAdI) | Upgrade-safe by design |
| Custom field on standard entity | CFL app or CDS extension | No DDIC modification needed |
| Complex business logic, in-process | RAP action or released BAdI | Performance + clean separation |
| Integration with external system | BTP Integration Suite or CAP | Decouples SAP from external API |
| UI enhancement on Fiori app | Fiori Adaptation Project (SAPUI5 flex) | No OData modification required |
| Legacy process, no released exit | Classic exit (short-term only) | Document as technical debt, plan migration |
| S/4HANA Cloud / PCE | Clean Core only — no exceptions | Platform constraint, not preference |
The “It’s More Complex” Cases
No Released Extension Point Exists
This happens more often than SAP’s documentation suggests. When no released BAdI covers your requirement, you have three real options: (1) redesign the business process to work within the standard, (2) implement a classic modification and document it explicitly as technical debt with a migration plan, or (3) raise a customer influence request with SAP for a new extension point.
Option 1 is underused. Many “we can’t do it clean core” conclusions are actually “we haven’t challenged the business requirement against the standard process hard enough.” A good architecture workshop often surfaces that the standard does cover 80% of the case, and the remaining 20% can be handled with a side-by-side BTP service.
Legacy Code You Inherited
If you’re taking over a system with extensive classic modifications, don’t attempt a “big bang” migration to clean core. Use ATC (ABAP Test Cockpit) with clean core checks activated to get a prioritized view of your modification landscape. Focus migration effort on the highest-risk objects: objects that SAP marks as “changed in release” frequently, and modifications that touch released APIs.
Common Myths Debunked
- “Clean core is only for cloud customers” — False. On-premise S/4HANA customers benefit equally: cleaner upgrade cycles, better audit traceability, and lower regression testing effort.
- “RAP is too complex for simple requirements” — RAP has a learning curve, but for simple field derivation or validation, a RAP managed BO with a single determination takes less time to build than a classic user exit if your team knows the tooling.
- “We can’t migrate because the modification is too deep” — Deep modifications are exactly what clean core governance should prevent in new development. Legacy migrations require a phased approach, not a blocker mindset.
Practical Starting Point
If you’re starting a new S/4HANA extensibility effort today: activate ATC clean core checks in your development system, review the Extension Point Catalog for your target process area, and default to clean core for all new development — with documented exceptions only when no released exit exists.
The architecture investment pays back within the first upgrade cycle, typically with 30–50% less custom code regression testing effort compared to classically extended systems.
Unsure which extensibility approach fits your specific scenario? We offer targeted architecture assessments for S/4HANA teams facing exactly these decisions.