Every SAP customer is making the same architecture decision right now, whether they realize it or not. Each customization request, each Z-table, each workaround that ships today becomes either an asset or a liability the moment the next major upgrade lands. For most of the last two decades, that distinction was mostly a matter of internal taste and budget. SAP has now made it explicit, scored, and very hard to ignore.
In August 2025, SAP retired its older three-tier extensibility model and replaced it with a four-level classification system, A through D, that grades every custom extension on exactly one criterion: how much risk it introduces at the next upgrade. The system carries a name that sounds aspirational, Clean Core, but underneath the branding it functions closer to a credit score for your ERP. And like a credit score, the number an organization ends up with by 2027 will be the result of thousands of small decisions made long before anyone called it a deadline.
Definition
What Clean Core Actually Means
Clean Core is often described loosely as keeping customizations out of the SAP core, but that framing undersells how specific the model has become. The underlying principle is simple: extensions should be avoided whenever a standard feature or configuration can meet the requirement, and where an extension is genuinely necessary, it should be built only on SAP’s released APIs, BAdIs, or RESTful extension points. What changed in 2025 is how SAP measures compliance with that principle. Instead of a binary clean-or-unclean label, every extension, brand new or decades old, now gets classified into one of four levels based on which APIs and technologies it actually touches.
Level A extensions use only released, publicly documented APIs, built either on-stack inside S/4HANA using ABAP Cloud or side by side on SAP’s Business Technology Platform. They are fully upgrade-safe by design and represent the target for all new development. Level B relies on classic SAP APIs that are stable and supported but not formally cloud-ready, generally safe with the right governance sign-off. Level C reaches into internal SAP objects that were never released or documented for customer use, carrying real upgrade risk and requiring a documented remediation plan. Level D covers direct modifications to standard code, implicit enhancements, and anything flagged as unsupported, the patterns most likely to break the moment SAP ships its next release.
Laid out side by side, the four levels read less like a compliance checklist and more like a risk gauge, and that is exactly how most architecture teams have started using them.
Reality
How Technical Debt Actually Accumulates
Almost no organization sets out to build a Level D core. Technical debt in SAP landscapes is rarely the product of one bad decision, it is the accumulated residue of hundreds of reasonable ones. A finance team needs a workaround before quarter close. A legacy integration gets lifted into the new system as-is because rebuilding it properly would slow the migration timeline. A data quality issue that should have been resolved in master data governance instead gets patched with custom validation logic, because that fix ships faster. None of these decisions feels like technical debt in the moment. Collectively, they are exactly that.
There is also a quieter, more strategic version of the same problem. SAP’s own user community has grown noticeably more cautious about ceding architectural control. Recent investment research from the German-speaking SAP user group found that, while overall IT budgets keep rising, spending on SAP software specifically is being allocated in a far more selective and critical way than in prior years, with a clear undercurrent of resistance to vendor lock-in inside expensive cloud contracts. Part of that resistance is showing up as interest in external large language models and independent platforms, an attempt to preserve digital sovereignty even while modernizing the core. Whichever side of that debate an organization lands on, the underlying signal is consistent: architecture decisions made under deadline pressure tend to trade short-term speed for long-term dependency, and enterprises are growing less willing to make that trade blindly.
There is also a forward-looking reason to care about this beyond the next upgrade cycle. SAP’s own AI agents, including its Joule copilot and the broader push toward agent-driven business processes, depend on clean, semantically consistent, well-structured data to produce reliable output. A Level D core does not just slow down upgrades, it actively undermines the data foundation that every future AI initiative will need. Clean Core, in that sense, is no longer purely an upgrade-readiness exercise. It is becoming a prerequisite for whatever comes after the upgrade.
Deadline
Why 2026 Closes the Window
None of this would carry the same urgency without a hard date attached to it. SAP’s mainstream maintenance for ECC, the legacy ERP core a large share of enterprises still run, ends in 2027. Extended maintenance remains an option after that point, but it comes at a meaningfully higher cost, with shrinking access to new SAP innovation and a widening gap between what the platform can do and what the organization is actually using. By most industry estimates, more than half of SAP’s customer base will have completed its move to S/4HANA by the end of 2026, which means the remaining cohort is not just facing a deadline, it is competing for a shrinking pool of resources to meet it.
That resourcing problem is already visible. Experienced S/4HANA consultants are in short supply, and the implementation partners with the strongest track records are booking their teams years in advance. Organizations that start planning now still have a real choice of approach, including the Bluefield migration pattern that has overtaken pure greenfield projects in popularity precisely because it lets a company retain its critical, well-functioning processes while modernizing everything around them, rather than rebuilding from a blank slate or dragging every piece of legacy customization forward untouched. Organizations that wait into 2027 increasingly will not have that choice. They will take whatever capacity is left, on whatever timeline that capacity allows.
Mapped against the calendar, the pattern is hard to miss: every year of delay narrows the field of options and raises the cost of whichever option remains.
Practice
The Governance Habit That Actually Protects You
Clean Core is frequently treated as a one-time audit: inventory the custom code, classify it against the four levels, fix what needs fixing, declare victory. That approach produces a clean snapshot and very little lasting change, because the system that produced the original technical debt is still in place and will simply produce more of it. The organizations that sustain a clean architecture treat it as an operating discipline owned jointly by architects and developers, not a project with an end date.
In practice, that discipline tends to include a few consistent habits. The ABAP Test Cockpit runs continuously across development environments rather than as a pre-go-live checkpoint, with high-priority findings blocking transports automatically. Every extension decision gets documented at the moment it is made, not retroactively, including which level it was assigned, what alternatives were considered, and what the remediation plan is for anything above Level B. New development defaults to a BTP-first evaluation, meaning before a developer reaches for a classic workaround, the first question is whether a released API or a side-by-side extension on SAP’s Business Technology Platform can do the job instead. Exemption logs, the record of extensions that knowingly fall outside policy, get reviewed on a fixed cadence rather than left to grow quietly, because a log that only ever expands is usually the earliest sign that governance is eroding.
The organizations that sustain a clean core treat documentation as a habit, not a deliverable, because the decision that protects an upgrade three years from now is being made by a developer today.
Path Forward
Treat the Architecture Decision, Not the Deadline, as the Driver
It is tempting to treat Clean Core compliance as a box to check before the 2027 deadline, in the same way many organizations once treated Y2K remediation: a fixed cost, absorbed once, then forgotten. That framing tends to produce exactly the outcome it is meant to avoid. A migration completed under deadline pressure, with extension decisions made quickly and left undocumented, simply relocates the technical debt rather than removing it, and the next upgrade cycle inherits the same problem with even less runway to fix it.
The organizations getting genuine value from this moment are doing the opposite. They are using the 2027 deadline as a forcing function to finally build the governance habits, the extension inventory, the documented decision trail, that should have existed all along, rather than as an excuse to rush. That is the work we focus on with clients across both Oracle and SAP landscapes: auditing what is actually running in the core today, building a realistic level-by-level remediation roadmap, and making sure the migration becomes the moment an enterprise’s architecture gets genuinely easier to run, not just technically current for another five years.
The deadline will pass either way. What an organization is left holding on the other side of it, a clean, governed core or a faster version of the same debt, is still very much a choice.
