Clean core versus enhanced extensibility: how do these strategies impact long-term upgrade paths?

ERP SAP S/4HANA
, , , , , , , ,
1

I’m evaluating our extension strategy as we plan our S/4HANA 1909 upgrade to current release. SAP has been heavily promoting the clean core approach, and I’ve noticed they introduced the A-D extensibility rating system in 2025 to classify custom code impact. The concept makes sense - minimize modifications to standard objects to reduce upgrade complexity and technical debt.

However, our business has legitimate requirements that standard functionality doesn’t address. We have industry-specific workflows and regulatory requirements that demand customization. The question becomes: do we invest in converting existing enhancements to side-by-side extensions, key user tools, and embedded BTP extensions, or maintain our current enhanced approach with well-managed modifications?

I’m interested in hearing real-world experiences. Has anyone completed a clean core transformation? What was the effort versus benefit ratio? For those maintaining enhanced systems, how has upgrade complexity actually evolved? The SAP messaging suggests clean core dramatically reduces maintenance burden, but I’d like to understand if that holds true across different implementation sizes and industry complexities.

system 2

Clean Core vs. Enhanced Extensibility: Upgrade Path Reality

The tension you’re describing is real, and the answer isn’t binary. From 1909 to current release (2023 or 2024 FPS, verify your target), the delta is substantial — multiple compatibility-breaking changes in RAP (RESTful Application Programming Model), CDS view replacements, and BOPF deprecations make this more than a technical refresh.

Pre-Upgrade Checks

Before committing to either strategy, baseline your current state:

  • Run Custom Code Migration app (Fiori) and ABMT (ATC with cloud readiness checks) against your 1909 custom objects. Export findings to a remediation backlog.
  • Map every enhancement against the A–D extensibility classification: A/B (released APIs, key user tools) survives clean core. C/D (implicit enhancements, core modifications) creates upgrade friction regardless of strategy.
  • Audit BAdI implementations, user exits, and implicit enhancements separately — their stability varies significantly by application area.
  • Identify which custom objects consume deprecated CDS views (check transition guides between each intermediate release — 1909 → 2020 → 2021 → 2022 → target introduces stacked deprecations).
  • Validate side-by-side BTP integration points: Cloud Connector versions, event mesh dependencies, and API compatibility with target SAP_BASIS stack (verify in your version).

Decision Framework Before Migration Steps

Clean core investment makes sense when:

  • Your C/D rated objects are concentrated in a few domains (Finance, Procurement) where SAP’s extensibility APIs are mature.
  • You have roadmap alignment with SAP’s industry cloud solutions for your vertical.

Managed enhancement approach holds when:

  • Industry-specific regulatory logic (e.g., country-specific tax handling, sector compliance) has no released API equivalent — forcing a side-by-side rewrite creates risk without SAP support coverage.
  • Your C/D modifications are stable, well-documented, and have proven upgrade procedures across prior cycles.

Numbered Upgrade Sequence (1909 → Current)

  1. Complete ATC/ABMT analysis in SE80 or Cloud Readiness Check; remediate all syntax errors blocking transport.
  2. Apply latest 1909 SP stack to minimize delta before system copy.
  3. Create sandbox via system copy; execute upgrade using SUM (Software Update Manager) with DMO if combining DB migration.
  4. Execute automated correction of released API substitutions where ABMT provides explicit migration objects.
  5. Manually remediate C/D-rated enhancements — this is your variable cost driver.
  6. Run regression suite against core business processes; prioritize SCMA (custom code adaptation) for high-volume paths.
  7. Validate integration scenarios (iDocs, BTP event bindings, RFC destinations) post-upgrade.
  8. Performance baseline using STAD/ST12 on critical custom code paths before production cutover.

Rollback Procedure

  • SUM supports fallback to source release until the PARKED phase is passed — confirm exact phase boundary in your SUM version documentation.
  • Maintain a production-equivalent shadow instance on 1909 for minimum 4 weeks post-go-live.
  • Transport requests created post-upgrade are not automatically reversible — freeze custom development during hypercare.
  • Document all manually applied corrections outside SUM for selective re-application if fallback is triggered.

Practical Reality Check

The effort/benefit ratio for clean core transformation is front-loaded heavily. Organizations completing it report smoother subsequent upgrades, but the initial conversion of mature C/D-rated enhancements routinely runs 1.5–2x original estimates when regulatory logic is involved. A hybrid approach — clean core for new development, managed stability for existing compliant modifications with documented upgrade procedures — is the most common outcome in complex industry implementations, regardless of SAP messaging.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We went through clean core conversion last year for a manufacturing client. The A-D rating helped prioritize what to tackle first - anything rated C or D got immediate attention. Honestly, the effort was substantial. Six months with a dedicated team to refactor critical enhancements into RAP-based Fiori extensions and BTP integrations. But the 2024 upgrade took 40% less time than our previous one. The real benefit isn’t just upgrade speed though - it’s the reduced regression testing scope. When you’re not touching standard code, you’re not breaking standard functionality.

4

I’m skeptical of the clean core hype. We maintain an enhanced S/4HANA system with carefully managed modifications - proper transport management, comprehensive documentation, dedicated enhancement spots. Our upgrades run smoothly because we follow SAP’s modification guidelines. The clean core approach assumes all requirements can be met with standard plus extensions, but that’s not reality for complex enterprises. Some industry processes genuinely need core modifications. The key is governance, not avoidance.

5

The extensibility rating system is a game-changer for decision-making. We used it to categorize our 200+ custom objects. Rating A (side-by-side extensions) and B (released APIs) were already upgrade-safe. Rating C (modification with extension points) needed refactoring priority. Rating D (direct core modifications) triggered business case reviews - either justify the business value or redesign using standard capabilities. This structured approach helped us move from emotional debates about ‘necessary customizations’ to data-driven decisions. Three-quarters of our D-rated mods turned out to be workarounds for missing process knowledge, not genuine gaps.

6

That’s interesting about the rating distribution. Did you find the BTP-based extensions introduced new complexity? I’m concerned about trading one maintenance burden (custom ABAP) for another (managing BTP services, APIs, integration points). Also, how did you handle regulatory requirements that specifically mandate certain data handling within the ERP core? Some of our compliance needs can’t be addressed with loosely-coupled extensions.

7

Regulatory requirements are often cited as justification for core mods, but in my experience, most can be handled through proper configuration plus strategic extensions. The key is understanding what actually needs to be in-database versus what can be in-flight processing or reporting layer. For audit trails and data residency, standard S/4HANA change documents and table logging usually suffice. For specialized calculations or validations, custom logic tables with BADI implementations work well and stay upgrade-safe. The few genuine core modification needs should go through formal exception process with SAP support engagement.

8

BTP complexity is real but manageable. Yes, you’re adding infrastructure components - Cloud Foundry apps, API management, integration flows. But these follow modern DevOps patterns with CI/CD, version control, automated testing. Compare that to maintaining custom ABAP that requires specialized skills and has limited tooling. We’ve found the BTP approach actually reduces long-term complexity because it separates concerns. Core ERP handles transactional integrity, extensions handle business logic variations. When SAP changes core, your extensions continue working via stable APIs.

9

Both strategies have merit depending on your organization’s maturity and business context. Let me provide a comprehensive perspective:

The Clean Core Promise and Reality:

SAP’s clean core model, reinforced by the 2025 A-D extensibility rating system, aims to fundamentally reduce upgrade risk by eliminating dependencies on internal SAP code structures. The theory is sound: if you only interact with released APIs and documented extension points, SAP can refactor internal implementations without breaking your customizations.

In practice, the effectiveness depends on three factors:

  1. Business Process Complexity: Standard S/4HANA covers 80% of common business scenarios well. The remaining 20% varies dramatically by industry. Discrete manufacturing with engineer-to-order processes has different gaps than retail or professional services. If your business differentiation lives in that 20%, clean core requires more investment.

  2. Technical Debt Starting Point: Organizations with heavily modified ECC systems face a choice - continue the enhancement path or use S/4HANA migration as a reset opportunity. Clean core makes most sense as a transformation strategy, not incremental conversion. The effort to refactor existing modifications into compliant extensions is substantial, often 40-60% of original development cost.

  3. Organizational Capability: BTP-based extensions require different skills than traditional ABAP development. You need cloud platform expertise, API design knowledge, and DevOps practices. Many enterprises underestimate this capability gap. Your team composition and training investment significantly impact success.

Enhanced Extensibility with Governance:

The alternative approach - maintaining enhanced systems with disciplined modification management - remains viable if you implement proper governance:

  • Use only SAP-provided enhancement spots and BADIs when available
  • Document every modification with business justification and technical impact assessment
  • Maintain modification workbench entries and use code inspector regularly
  • Implement automated testing for all custom code
  • Review modifications during each upgrade cycle for deprecation or standard replacement

This approach acknowledges that some business requirements genuinely need core integration. The risk isn’t modification itself - it’s unmanaged, undocumented, poorly-designed modifications that create upgrade nightmares.

The A-D Rating System as Decision Framework:

SAP’s extensibility rating provides practical guidance:

  • A-rated (Side-by-side): Cloud extensions, completely decoupled. Zero upgrade impact but limited to processes that can operate asynchronously.

  • B-rated (Released APIs): Stable interfaces with compatibility guarantees. Ideal for most custom logic if your requirements fit available API scope.

  • C-rated (Modification with protection): Uses enhancement points but touches standard objects. Requires testing each upgrade but SAP maintains the extension mechanism.

  • D-rated (Direct modification): Changes core code without protection. High upgrade risk and should require executive approval.

The rating system helps move from binary “clean vs. enhanced” thinking to a portfolio approach. Aim for mostly A/B, tolerate some C with justification, eliminate D except for truly irreplaceable business value.

Recommendation for Your Situation:

Given you’re on 1909 planning upgrade, I suggest a hybrid strategy:

  1. Inventory all customizations and assign A-D ratings
  2. For new requirements, default to clean core approach (A/B rated solutions)
  3. For existing D-rated modifications, conduct business value assessment - either justify and accept upgrade cost, or redesign using standard capabilities
  4. For C-rated enhancements, maintain current approach but document upgrade test requirements
  5. Establish architecture review board to approve any new C/D-rated customizations

The goal isn’t purity - it’s sustainable customization that balances business needs with technical maintainability. Clean core is an ideal to trend toward, not an absolute requirement. The custom code maintenance complexity SAP warns about is real, but it’s manageable with proper engineering discipline. Focus on reducing your D-rated modifications while accepting that some core integration will remain necessary for competitive differentiation.