The Risk of Accelerating SAP Development Without Clean Core Discipline

Speed Is a Multiplier, Not a Strategy

Acceleration does one thing reliably. It produces more of whatever your pipeline already produces, at a higher rate. If the pipeline produces compliant, upgrade-stable extensions, acceleration produces more of those. If it produces ungoverned custom objects, acceleration produces more of those, and nobody notices the difference until the invoice arrives.

The grading does not care how the code was made. Since SAP introduced the clean core level concept in August 2025, every custom extension lands somewhere on the scale from level A to level D, and every line of AI-generated ABAP passes through the same ABAP test cockpit checks as every line a developer types. A tool that doubles your output of level D objects has doubled your production of technical debt, with a better user interface.

What ungoverned pipelines actually accumulate is a matter of record. SAP's own published analysis of typical ERP systems found that roughly 60 percent of custom code, sometimes more, is never used productively. Six of every ten objects in the average landscape are pure carrying cost. That is what years of deadline-driven creation look like before anyone speeds it up.

The rest of this piece prices the risk in three specific debts. Each one has a published date or an SAP note number attached, because vague warnings are easy to ignore and scheduled ones are not. The full lifecycle these debts live inside is covered in our guide to SAP SDLC automation.

Faster is only a virtue when the thing you are producing is worth having more of.

Debt One: The Upgrade Toll

SAP's release rhythm turns technical debt from a one-time cost into a toll paid at every upgrade, and SAP has committed to that rhythm for a long time to come. Starting with SAP S/4HANA 2023, released in October 2023, the product moved to a two-year release cycle with seven years of mainstream maintenance per release. Behind that cadence sits a longer promise: SAP has stated that until 2040, there will always be at least one release of SAP S/4HANA in maintenance. The platform will keep moving for at least the next fourteen years.

Nobody is forced to upgrade every two years. The seven-year windows mean each team chooses its own rhythm. What no team chooses is what happens inside each upgrade it does take: every custom object in the landscape gets re-tested against a moved platform, and the objects that were never built to a standard are the ones that fail in interesting ways.

The level mechanics make this concrete. Level C extensions rest on SAP internal objects, which SAP describes as subject to change without notice or compatibility guarantees. Between releases, SAP can reclassify an internal object upward into a stable classic API or downward into the not-recommended category, which moves your extension between levels without you touching a line of code. SAP publishes a changelog precisely so teams can check their exposure before each upgrade, which means a level C object is a recurring homework assignment, not a settled decision. Level D objects need no reclassification to hurt you. Modifications, direct writes to SAP tables, and implicit enhancements carry the concentrated risk by definition. We covered what each level means for leadership in our article on SAP clean core as a continuous practice; for this piece, the point is narrower. Every object below level B is a toll booth you built for yourself, and the road has traffic scheduled through 2040.

Debt Two: The Shrinking Safety Net

When mainstream maintenance ends, SAP stops adapting a release to external requirements, and the support that remains is thinnest exactly where undisciplined teams need it most: their own custom code.

The timeline is fixed and public. Mainstream maintenance for SAP Business Suite 7 core applications, which include SAP ECC, ends on December 31, 2027. Customers can buy extended maintenance through the end of 2030 at a premium of two percentage points on their maintenance basis. After that, or immediately after 2027 for those who decline the premium, customer-specific maintenance begins automatically.

SAP's own training material describes what that phase means: the release is no longer adjusted to meet external requirements, which SAP illustrates with two examples that should concentrate any executive's attention, the implementation of legal changes and the support of new technologies. SAP describes customer-specific maintenance plainly as offering the least support of any phase. The full restriction scope is documented in SAP Note 52505, and one mechanic in it matters more than the rest for this piece: problem resolution narrows to problems SAP already knows, and resolving new ones can come at the customer's expense, a limitation that applies particularly to customer-specific enhancements.

Read that mechanic twice. The code most likely to produce novel problems is heavily customized code, and heavily customized code is exactly what the remaining support covers least. Standard functionality at least degrades predictably after 2027, because its problems are the ones SAP is most likely to know already. Ungoverned Z-programs lose their safety net first, at the same moment the organization is busiest with its S/4HANA move. Decline the extended- maintenance premium, and a tax rule changes in one of your markets in 2029 while the system that runs your books no longer receives the update. That is not an outage. It is quieter than an outage, and it lands on the compliance function before IT ever sees it.

Debt Three: The Bridge That Closed

If the first two debts feel theoretical, SAP has already run the experiment once, in public, with a published ending. Compatibility packs were temporary usage rights that let certain classic SAP ERP functionalities keep operating inside SAP S/4HANA, a bridge built so customers could migrate without rebuilding everything on day one. The expiry was documented in SAP Note 2269324 and, in SAP's own words, extensively communicated for years. The original end date was December 31, 2025. On the last day of 2025, SAP's head of customer support announced one final five-month transition period, moving the deadline to the end of May 2026, and framed it exactly that way: final.

That deadline has now passed. Support for compatibility scope ended the day the usage rights did, patches and legal changes included, and SAP reserved the right to make the functionality technically unavailable in future S/4HANA releases. Customers were told to ensure, by organizational or other measures, that the functionality would no longer be used. Arrangements differ for systems under RISE with SAP agreements and for a handful of named items, with the details in the note, but the shape of the story is the one that matters here.

Because the shape is familiar. A dependency gets created as a temporary measure. It works, so it stays. Teams build routine on top of it. The expiry feels distant until it is five months away, and then every program that treated the bridge as a destination is running a forced remediation project on someone else's schedule. Ungoverned custom code follows the same emotional logic, temporary becomes permanent, with one difference that makes it worse: no note number, no published date, nothing that forces the conversation before a migration or an upgrade forces it for you. Compatibility packs at least sent a save-the-date. Your undocumented Z-table modifications will not.

Here are the three debts side by side:

Debt What triggers the cost Published date or mechanism Who ends up paying The upgrade toll Every release upgrade you take Two-year cycle from S/4HANA 2023; at least one release in maintenance through 2040 Programs carrying level C and D objects forward The shrinking safety net End of mainstream maintenance December 31, 2027 for Business Suite 7; scope after per SAP Note 52505 Teams whose custom code produces new, unknown problems The bridge that closed Expiry of temporary usage rights End of May 2026 per SAP Note 2269324 Teams that treated a temporary dependency as permanent

The Timeline Every SAP Leader Should Have on One Page

The deadlines that price SAP customization risk are already published. Assembled in one place, they stop reading like a list of dates and start reading like a schedule of decisions.

Date What changes Source End of May 2026 Compatibility pack usage rights and their support ended for SAP S/4HANA on- premise SAP Note 2269324 December 31, 2027 Mainstream maintenance ends for SAP Business Suite 7 core applications, including SAP ECC SAP Support Portal 2028 through 2030 Optional extended maintenance at a two- percentage-point premium on the maintenance basis SAP Support Portal After extended maintenance Customer-specific maintenance: no legal changes, no new support packages, known-problems- only resolution SAP Note 52505 From S/4HANA 2023 onward Two-year release cycle, seven years of mainstream maintenance per release SAP News Through 2040 At least one SAP S/4HANA release always in maintenance SAP Support Portal

None of these dates moves for any individual customer's backlog. The only variable on the page is how much undecided custom code you are carrying when each one arrives.

The Discipline That Makes Speed Safe

The remedy is not slower delivery. It is governance applied at the moment code is created, and the machinery for it is documented and available today. Decision rights come from the SAP Application Extension Methodology and a standardization board that records why every deviation from standard was approved. Enforcement comes from ABAP test cockpit checks configured to block non-compliant code at the transport. Measurement comes from SAP's clean core dashboards, which turn debt into a number leadership can track release over release. We covered how the three layers fit together, and the four-question audit that tests yours, in our guide to SAP clean core governance. Teams with that machinery running can accelerate with confidence. Teams without it are about to multiply something they have not measured.

Three Decisions to Make Before You Accelerate

Before adding AI or automation to SAP delivery, make three decisions. Skip them and the acceleration will make them for you, later, at a worse price.

First, grade what you have. Run SAP's clean core readiness checks against your existing custom code; the preconfigured ABAP_CLEAN_CORE_READINESS check variant works against ECC and older S/4HANA systems, so nobody has to wait for a migration to know their exposure. The output turns your level C and level D share from a suspicion into a number, and numbers get budget lines where suspicions get deferred.

Second, decide each object's fate. Rebuild it clean, retire it, or consciously accept its risk, and record the decision with an owner. SAP's finding that roughly 60 percent of typical custom code is unused means retirement is usually the biggest early win available: the cheapest object to govern through 2040 is the one you delete in 2026. Every object without a recorded decision is a decision your migration team will make under deadline pressure instead.

Third, set the standard generation must meet before you switch generation on. Shared artifact templates and a blocking compliance gate come first, the accelerator second, because an accelerator reproduces the standard it is given, at scale. Reverse the order and you will spend the savings from acceleration on remediating its output.

Where SASA Fits

SASA is our SAP SDLC automation platform, and it exists on the position this piece argues: generation and governance evidence have to ship together or the speed is borrowed, not earned. SASA starts from a knowledge graph of your actual landscape, including the custom objects and Z-tables nobody has documented in years, so its output is grounded in how your system really works. It generates specifications, ABAP, and tests from shared templates with every artifact traceable to its requirement, aligned to Clean Core and validated before it moves. In our client engagements this approach has delivered results like twice-as-fast SAP delivery and up to 95 percent test coverage, figures from our own work that we will gladly walk through object by object. If the argument here holds, the evaluation question for any accelerator, ours included, is simple: show me the compliance grade that ships with the code. Start with SAP SDLC automation with SASA and its approach to SAP clean core automation.

The Next Step

Run the grading first. Your level D share tells you whether the next budget line is remediation, governance, or acceleration, and in which order, and finding out is cheap compared with learning it during an upgrade. When you have the number, our guide to SAP clean core governance includes the audit that shows which governance layer to fix first, or talk to our team about a governance-first pilot against your own landscape.

Frequently Asked Questions