Clean core: why architectural discipline has become a matter for the C-suite.

The principle fits in one sentence. In a clean system, the core stays compliant with the vendor’s standard; everything the company adds lives alongside it, on extension platforms designed for the purpose, behind documented interfaces. SAP has made this the official doctrine of S/4HANA and RISE, and it would be a mistake to write it off as a sales argument: the promise of regular updates only holds if no one has welded the core shut from the inside. But the real reason to care has nothing to do with the vendor. It is in your accounts.

Every custom development is debt

A custom development is always born of a good intention. A process that keeps jamming, a clumsy screen, a business request someone wants met quickly: a few days of development and the matter is settled. The day it is written, a custom development looks almost free. The cost comes later.

It costs at every upgrade: everything that touches the core must be analyzed, adapted and retested, and the bill repeats for as long as the code lives. In a RISE world, where the vendor pushes its updates at its own pace, that burden stops being a once-every-five-years event and becomes a recurring toll. It costs in innovation: the capabilities SAP ships, embedded AI first among them, rely on standard processes and data structures; a core riddled with exceptions watches them go by. It costs, finally, in dependency: over the years, knowledge of a custom development concentrates in two or three heads, and the day they leave, the company discovers it can no longer explain its own system.

None of these costs appeared in the estimate for the initial development. That is what makes the argument so hard to win: the spend is visible and modest, the debt is invisible and long. An executive team that ignores it will pay it all the same.

The test: a proven differentiator, or the standard

Should custom code be banned outright, then? No, and the all-standard purists get it as wrong as anyone. Some processes win customers, margin or days of cash precisely because they look nothing like anyone else’s. Those deserve to be defended, built cleanly outside the core, and maintained as assets.

Everything hinges on the criterion. Ours is simple to state and uncomfortable to apply: a custom development is justified if the process it carries is a demonstrable business differentiator. Demonstrable, not felt: who can say what the company would concretely lose by moving to the standard? If no one can answer, the answer is the standard, and it is the process that adapts. Our experience of custom-code inventories is consistent on this point: the vast majority fail the test. They reproduce a habit, rarely an advantage.

The right question is not "what does this custom development do?" but "what would the company be worth without it?" If the answer is "the same," it has no business in the core.

What the discipline demands of governance

A criterion is not enough; someone has to hold it. This is where the subject leaves the technical sphere for good, because holding a criterion means saying no. No to a business director in a hurry, no to a project that has already made promises, no to the easy fix that would reopen the core. An architecture authority that cannot lean on executive leadership will give way. Politely, and every time.

The governance that works rests on three practices, and we find them in every company that lasts. First, a decision forum where the business comes to argue its case, with the differentiator test posted in advance as the rule of the game. Second, a register of exemptions: every accepted custom development is recorded there with its owner, its justification and its review date, because debt is hard to manage when no one keeps the books on it. Third, a review at every upgrade: a custom development has to re-earn its place at each milestone, or it goes. Without that checkpoint, the drift comes back within a few years, through an accumulation of small exceptions, each perfectly reasonable on its own.

2027, the purge that will not come around again

That leaves the calendar, and the calendar is what makes this urgent. The end of mainstream maintenance for ECC, set for late 2027 with a possible extension to 2030, forces every company through a move to S/4HANA. And a conversion is the only moment when purging costs less than keeping: every development has to be inventoried, analyzed and retested anyway. Sorting on that occasion is a marginal effort; carrying everything over means converting your debt along with your system, and repaying it for ten more years. The opportunity will not come around again at 2027 prices.

That is why we argue for fixing the custom-code doctrine at the scoping stage, before the scenario and the integrator are chosen, rather than discovering it mid-program, when every trade-off delays a milestone. The company that arrives at the negotiating table with its rule of the game, its register and its purge list chooses its program. The other endures it.

To read on: our view of the 2027 deadline, our S/4HANA offering and our approach to SAP transformation, where this discipline gets decided and given the tools to hold.