The Clock Everyone Is Watching
There is a date circulating in manufacturing IT departments right now that is doing more to shape ERP budgets than any business case: December 31, 2027. That is when SAP ends mainstream maintenance for ECC 6.0 on enhancement packs 6 through 8, and SAP has stated it does not intend to move that date again.
That date is not the only clock running, and the other one is instructive. Compatibility packs — the temporary usage rights that let customers who had already moved to S/4HANA on-premise keep running classic ERP functionality — expired for most customers at the end of May 2026, after a final five-month extension from the original December 2025 deadline. The destination has deadlines of its own. That is worth knowing before treating migration as the obviously safe choice.
A vendor deadline is a real constraint, but it is not a strategy, and the difference between those two things is where a great deal of money gets spent badly.
A vendor deadline is a real constraint, but it is not a strategy, and the difference between those two things is where a great deal of money gets spent badly. The deadline tells you when you must decide. It does not tell you what to decide, and the vendor who set it is not a neutral party in that question.
What End of Maintenance Actually Means
Some of the urgency in the market is manufactured, so it is worth being precise about what actually stops.
End of mainstream maintenance does not mean your system switches off. It means the vendor stops shipping security patches, regulatory and legal change updates, and defect fixes. For a manufacturer, the legal change piece is often the sharpest edge: payroll rules, tax treatments, and compliance reporting change whether or not your ERP is supported, and an unsupported system quietly becomes your problem to patch.
There is a paid path to more time. Extended maintenance runs to December 31, 2030 at roughly a two percent premium over your standard rate, and it is genuinely narrower than what you have today. It covers security patches and selected quality improvements. It does not include new functionality, it does not guarantee legal change packages, and it does not guarantee kernel updates for new operating system or database versions. That last one matters more than it sounds: your infrastructure lifecycle does not pause because your ERP did.
So extended maintenance is not a reprieve. It is a purchased delay with declining value, and it is worth exactly as much as what you do with the time it buys.
The Three Options Nobody Lays Out Side by Side
Most manufacturers we talk to have been presented with one option and a countdown. There are three, and an honest evaluation puts them on the same page with the same assumptions.
The first is to buy time deliberately. Take extended maintenance, accept the narrowed scope, and use the runway to do the evaluation properly rather than under duress. This is a legitimate choice when your current system genuinely fits the business and the constraint is bandwidth rather than capability. It is a bad choice when it is chosen by default, because you will arrive at 2030 having paid a premium for three years and still owing the same decision.
The second is to follow the vendor's upgrade path. This is the default and, for a meaningful share of manufacturers, the right answer. Your processes are already shaped around the vendor's model, your people know it, and the migration tooling and partner ecosystem are mature. The honest caveat is that a migration is not an upgrade. Timelines commonly run eighteen to thirty-six months, and the projects that go badly are almost always the ones sold as a technical exercise that turn out to require business process redesign under a deadline.
The third is to test the market. The small and mid-market ERP landscape looks materially different than it did when most ECC systems were implemented. Cloud-native platforms have closed much of the functional gap for discrete and process manufacturing, total cost of ownership models have changed, and a forced migration is the one moment when the switching cost of leaving is not much higher than the cost of staying. Choosing not to look is a decision. It should be a deliberate one.
Why the Default Choice Is Usually the Unexamined One
The uncomfortable pattern is how rarely option three gets a real hearing, and it is not because it always loses on the merits.
It is because of who is in the room. The incumbent vendor has account teams, migration assessments, funded workshops, and a commercial interest in a specific outcome. The systems integrator with the deepest bench in your current platform is proposing the migration they are best positioned to deliver. None of this is dishonest. It is simply that everyone advising you has already picked a side, and the analysis you receive is shaped accordingly.
The second reason is timing. A team that starts evaluating twelve months out does not really have three options, because two of them cannot be executed in twelve months. The window closes quietly, and the choice that remains gets recorded as a decision when it was actually a consequence of waiting.
The third is that the migration gets framed as a technology project when the expensive part is organizational. Data migration, process redesign, retraining, and adoption are where these programs run over, and none of them are on the vendor's slide.
What an Honest Evaluation Looks Like
An evaluation worth the name is not a feature comparison. Feature grids are the most reliably misleading artifact in enterprise software selection, because every mature platform can tick every box and the ticks say nothing about fit.
Start with your actual constraints rather than a requirements list. What does your business genuinely do that is unusual, and how much of your current customization exists to support that versus to preserve a habit? Most manufacturers discover that a meaningful share of their customizations are fossils, built for a process or a customer that no longer exists. Retiring them changes the migration scope considerably, and it is work that pays off no matter which platform you land on.
Then model total cost honestly across all three options over the same horizon, including the costs that vendors leave out: internal staff time, the productivity dip after go-live, integration rebuild, data remediation, and the license trajectory in years three through seven rather than year one. A two percent maintenance premium looks cheap next to a migration until you carry it three years and still have to migrate.
Finally, be specific about what you want the system to do that it cannot do today. If the answer is nothing, the migration is a maintenance exercise and should be scoped and priced as one. If the answer is substantial, then the deadline is not the reason you are moving, and the business case should stand on its own.
The Timeline Math You Cannot Argue With
The single most useful thing to do this quarter is to work backward from the date, because that math forecloses options faster than most teams expect.
If a migration takes eighteen to thirty-six months and mainstream maintenance ends December 31, 2027, then a program starting after the middle of 2026 is already compressed against the short end of that range. Industry estimates through 2026 have consistently put a majority of ECC customers as not yet started, with well under half having licensed S/4HANA at all. These are vendor-ecosystem and analyst figures rather than audited counts, but every version of them tells the same story. That is a lot of organizations converging on the same partner capacity, the same scarce skills, and the same eighteen-month window at the same time.
Two things follow. Implementation capacity gets more expensive and less available the longer you wait, which is a cost that never appears in the initial quote. And evaluation itself takes time — a proper vendor-independent selection runs a few months, not a few weeks — so the decision about how to decide has to happen well before the decision itself.
The practical answer is to separate the two. Decide by the end of this year what you are going to do, and give yourself all of 2027 to execute it. That sequencing keeps all three options genuinely open, which is the only real leverage you have in the negotiation that follows.
The Bottom Line
A vendor end-of-life date is a legitimate forcing function. It is not a recommendation, and it is not neutral advice, because the party that set it has a preferred answer and a commercial interest in you reaching it quickly and without comparison.
Staying on extended maintenance, following the upgrade path, and evaluating the market are all defensible choices for different manufacturers. What is not defensible is arriving at one of them by running out of time. The manufacturers who handle this well decide early, evaluate with someone who does not get paid differently depending on the outcome, and treat the deadline as the moment they gained leverage rather than lost it.
At Cherry Street, this is the work we do. We are vendor-independent by design, which means we have no license revenue riding on which system you choose. We help manufacturers separate the customizations worth carrying forward from the ones worth retiring, model the real cost of staying against the real cost of moving, and run a selection that stands up to scrutiny. If the only analysis you have seen so far came from someone with a product to sell, that is the gap worth closing before you commit seven figures and two years.
Found this useful? Share it.
Share on LinkedIn