ECC end of maintenance: turning the constraint into an opportunity.

Everyone knows the deadline. It still keeps catching companies off guard. SAP has set the end of mainstream maintenance for ECC at the end of 2027; a paid extension remains available until 2030 for companies that choose it. Three years of runway, on paper. In reality far less: a core-system transformation has to be scoped, decided, contracted and then executed, and each of those steps consumes entire quarters. We see it with every one of our clients: those who think in terms of the end-of-maintenance date are already a step behind. Those who think in terms of their program’s launch date stay in control.

Why waiting keeps getting more expensive

Faced with an imposed deadline, the first reflex is to push it back. The extension to 2030 exists precisely for that, and we do not condemn it: it can be a rational choice, provided it is a choice, backed by a trajectory. Too often, it serves as an alibi for putting the decision off. Meanwhile the meter is running, and on far more lines than extended maintenance.

• The legacy gets heavier. Every custom development added to an ECC on borrowed time is debt the future migration will have to repay, with interest.
• Resources are getting scarcer. As the deadline approaches, the whole market converges on the same profiles: integrators, architects, conversion experts. Latecomers will be negotiating their program when availability is at its worst.
• The opportunity cost keeps compounding. As long as the core stays frozen, real-time analytics, automation and AI on enterprise data remain stuck at the pilot stage. That delay is not measured in euros of maintenance; it is measured in years of capabilities never built.
• Deciding under constraint means deciding badly. A program launched in a rush simply reproduces the existing system, for lack of time to rethink anything. Hard to imagine a worse use of a transformation budget.

Conversion, greenfield, hybrid: beyond the caricatures

Public debate likes to pit technical conversion, "fast and risk-free", against greenfield, "ambitious but endless". The reality of the programs we observe is less clear-cut. There are three families of trajectories, and the right choice depends on your existing landscape, not on doctrine.

Conversion (brownfield)

Converting the existing system to S/4HANA preserves history, processes and custom developments. That is its strength; it is also its limit. The approach suits companies whose ECC core has stayed reasonably healthy: harmonized processes, custom code under control, correct data. Converting a disorderly system amounts to moving house without opening the boxes. The mess arrives intact in the new home, where it costs more.

Greenfield

Starting from a brand-new system makes it possible to adopt the S/4HANA standards, purge years of custom code and rebuild processes on a clean foundation. It is the most transformative path, and therefore the most demanding: it assumes the company is willing to change how it works as much as it changes its tool. A greenfield run like a conversion in disguise, where every departure from the legacy is renegotiated line by line, stacks up the costs of both approaches with the benefits of neither. We have seen it happen.

Hybrid (selective data transition)

Between the two, selective approaches make it possible to sort: keep what still holds value, the history or the mature processes, and rebuild what no longer does. For multi-entity groups with heterogeneous landscapes, where no single answer exists, it is often the relevant route. It is also the most demanding in terms of architecture, and the one that forgives improvisation least.

Before it is a migration date, 2027 is a deadline for deciding who you want to be as an operating company.

How to decide, and at what level

The choice of path is not a matter of doctrine. It follows from an honest diagnosis across four dimensions. The state of your processes: are they harmonized, or does each entity live its own life? The weight of custom code: what does it actually do, and for whom? The quality of your data: can it be carried over as is without importing the liabilities? And finally, absorption capacity: what can your teams genuinely take on, alongside their day-to-day operations?

Above all, the decision must be made at the right level. As long as the S/4HANA trajectory remains an IT department matter, it will be settled on IT costs, and the cheapest short-term scenario will win, whatever its real cost. We say it plainly to our clients: this is a C-suite decision, because it commits the operating model. Which processes to standardize? Which differences to preserve because they create value? What architectural discipline, the famous clean core, to impose so that the new system does not reproduce the drift of the old one?

Where to start

Our conviction: the first step is neither a tender nor a tool choice. It is a short, decisive scoping exercise that delivers three things to leadership. To locate your starting point in five minutes, our 12-question self-assessment is a useful preamble.

• An unvarnished baseline review of the existing system: processes, custom code, data, costs, risks. A diagnosis that draws conclusions, rather than one more inventory.
• Scenarios that are genuinely compared, priced in full costs and expected benefits, with their success conditions made explicit. A scenario without success conditions is a sales pitch.
• A roadmap in waves, sequenced by dependencies and absorption capacity, in which every stage delivers intermediate value. The first budget squeeze kills the programs that deliver nothing before completion; better to guard against that when you sequence.

This scoping changes the balance of power. A company that knows what it wants, in what order and on what conditions, chooses its partners instead of enduring them. And that is where the constraint becomes an opportunity: the 2027 deadline offers what no transformation program obtains easily, the alignment of the whole company on a single date. It would be a shame to make it nothing more than a migration.

To go further: our approach to SAP transformation, our S/4HANA offering, and our reading of AI use cases on SAP, all of which begin with a digital core in working order.