I’m leading our S/4HANA 1809 transformation and facing the classic dilemma between clean core principles and business requirements. Our cost accounting module needs significant customization for industry-specific allocations that standard BADIs don’t fully support.
Management is pushing for ABAP Cloud and clean core to ensure smooth future upgrades and cloud readiness. However, our legacy system has 200+ custom programs and enhancements that business relies on daily. Some finance users are concerned about losing functionality if we strictly follow clean core.
I’d like to hear from others who’ve navigated this balance. How do you decide when classic enhancement techniques are justified versus forcing fit into clean core extensibility? What’s your framework for making these architectural decisions?
Let me synthesize this into a practical framework that addresses all three dimensions:
Clean Core Extensibility Strategy:
Adopt a tiered extension model. Tier 1 uses SAP’s released APIs, RAP-based custom objects, and ABAP Cloud development. This should handle 60-70% of requirements including standard cost accounting enhancements like custom allocation cycles via released BADIs and custom CDS views for reporting. Tier 2 leverages key user extensibility and custom fields through in-app extensions - perfect for master data extensions without code. Tier 3 reserves classic modifications for genuine gaps where business value exceeds technical debt cost.
Classic Enhancement Techniques - When Justified:
Use the “3-3-3 rule” for classic extensions: justified only if modification touches fewer than 3 SAP objects, impacts fewer than 3 business processes, and alternative solutions would require 3+ months development time. For your cost accounting scenario, implicit enhancements and new BADIs should be preferred over modifications. If you must modify, use enhancement spots and explicit enhancement implementations to maintain upgrade stability. Document every classic extension with business justification, technical debt assessment, and planned migration path to clean core alternatives.
Upgrade and Compliance Balance:
Implement a quarterly review process using SAP’s Custom Code Migration app and ATC checks with clean core restrictions enabled. Track your “clean core score” - percentage of extensions using released APIs versus classic modifications. Set realistic targets: 70% clean core in first year, 85% by year three. For compliance, establish a governance board with business and IT representation that approves any new classic extensions using your decision matrix. Factor in not just immediate upgrade impact but long-term cloud readiness.
For your 200 custom programs, run usage analytics first - SAP’s ABAP Test Cockpit can identify unused code. Then categorize remaining programs: process automation candidates (move to BTP), reporting needs (CDS views), and true business logic (evaluate against released APIs). You’ll likely find 30-40% can be eliminated, 40-50% modernized to clean core, and only 10-20% require classic extensions as interim solutions.
The goal isn’t perfection but continuous improvement toward clean core while maintaining business operations.
Appreciate all perspectives. The categorization approach and decision matrix are helpful frameworks. I think we’ve been too binary in our thinking - either pure clean core or traditional modifications. The middle ground options deserve more exploration.
From a business perspective, I’d challenge whether all 200 custom programs are truly necessary. We audited ours and found 40% were unused workarounds for problems that no longer exist or can be solved with standard S/4HANA functionality. Focus your effort on the genuine gaps. For cost accounting, look at the new margin analysis and profitability features in S/4HANA - they might eliminate some customization needs.
The reality is ABAP Cloud extensibility is still maturing. Released APIs cover maybe 70% of common scenarios. For cost accounting specifically, check if your requirements can be met through custom CDS views and released business events. If you need direct table modifications or non-released function modules, you’re stuck with classic extensions for now. Document these as technical debt and plan migration paths as SAP releases more APIs.
We faced identical challenges last year. Our approach: categorize all customizations into three buckets - critical business differentiators, process workarounds, and nice-to-haves. Only the first category justified classic extensions. Everything else we forced into clean core or eliminated entirely. This reduced our custom code by 65%.
Consider the total cost of ownership angle. Classic extensions create upgrade friction, but forcing everything into clean core might mean rebuilding functionality as side-by-side extensions or BTP apps. That’s expensive too. We use a decision matrix: if modification touches fewer than 3 standard objects and has clear business ROI exceeding 200K annually, classic extension is acceptable. Otherwise, clean core or eliminate. Also factor in your cloud timeline - if you’re staying on-premise for 3+ years, you have more flexibility.
Don’t forget the middle ground: key user extensibility and custom fields/logic via in-app extensions. These maintain clean core principles while providing flexibility. For cost accounting, custom fields on cost center master data and allocation rules can often be configured without code.