SAP ECC end of maintenance: S/4HANA is not the only answer

The SAP ECC end of maintenance does not switch your system off. SAP's own maintenance commitment says mainstream maintenance for SAP Business Suite 7 core applications runs until the end of 2027, that optional extended maintenance follows until the end of 2030, and that customers who skip or outlive extended maintenance move to customer-specific maintenance. Nothing in that text ends with the lights going out.

That matters because the deadline is routinely used to compress a decision that deserves twelve months of thought into a procurement cycle. Here is what SAP actually commits to, and then the argument this post exists for: for a mid-market company, the question is not which S/4HANA route to take, but whether the modules you genuinely run justify an S/4HANA programme at all.

The dates, and exactly what they cover

Phase	Period	What SAP says
Mainstream maintenance	Until end of 2027	Covers SAP Business Suite 7 core applications, "including the latest three enhancement packages of" SAP ERP 6.0, CRM 7.0, SCM 7.0, SRM 7.0 and Business Suite powered by SAP HANA
Extended maintenance	Beginning of 2028 to end of 2030	Optional, three years, at "a premium of two percent points on the maintenance basis for all support offerings"
Customer-specific maintenance	After that, or instead of extended	Applies to customers who do not opt for extended maintenance, or where extended maintenance has ended
S/4HANA innovation commitment	Until end of 2040	"Until 2040, there will always be at least one release of SAP S/4HANA in maintenance"

Two precision points before anyone budgets against this. First, the mainstream commitment covers the latest three enhancement packages. If your ERP 6.0 system sits below that line, the 2027 date is not the one that applies to you — your release is outside the commitment already, and the only reliable answer is your own entry in the Product Availability Matrix rather than a slide from a system integrator.

Second, the extended maintenance premium is "two percent points on the maintenance basis", which is not the same thing as a 2% increase on your invoice. It is points added to the maintenance rate you already pay, applied to the Business Suite 7 scope. SAPinsider's read of the deadlines is that SAP does not publish the resulting cash figure, so the only number you can plan with is the one your account team puts in writing against your contract. Treat any percentage quoted at you by a third party as a conversation starter.

The strongest case for S/4HANA, stated properly

Any honest comparison has to put the vendor's case at full strength first, because for a real share of companies it wins.

The 2040 horizon is genuine. SAP commits that at least one S/4HANA release will be in maintenance until the end of 2040. No bespoke platform comes with a fourteen-year vendor commitment, and for a board that has been burned by an abandoned product, that sentence is worth money.

Statutory content arrives as a product. This is the argument that defeats most build cases and it deserves to. E-invoicing mandates, indirect tax changes, country localisations and payroll law updates land in a packaged ERP as standard content maintained by someone else. In a custom system, every one of those is a ticket on your backlog, forever, including the ones announced with eight weeks' notice.

Encoded complexity is real complexity. If you run multi-plant production planning, split valuation, group consolidation across dozens of legal entities or a supply chain with genuine variant configuration, the standard product contains decades of resolved edge cases. Rediscovering them is not a project, it is a decade.

The ecosystem is a cost you avoid. Auditors know what to ask for. Your suppliers' EDI expectations are already met. You can hire people who have used the system before.

All four are correct. The question is whether they are decisive for you, and that turns on one piece of evidence almost nobody brings to the meeting.

Where the mid-market case breaks down

Quotes for an S/4HANA programme are scoped to the product and to the state of your current system — custom code to remediate, data history to carry, interfaces to rebuild. They are not scoped to how much of the product you use. So a company whose actual ECC footprint is finance, inventory, purchasing and one production module routinely receives a programme priced for a business running the full suite.

We see this pattern in the companies that come to us for custom ERP development after a first round of quotes: a system of record that has been live for fifteen years, a module list on paper that nobody has reconciled against reality, and a transformation proposal whose scope was inferred from the licence agreement rather than from usage. The conversation changes completely once someone pulls the numbers.

The numbers are already in the system. Your Basis team can export workload and usage statistics showing which transactions were actually executed over the last twelve months, by how many distinct users, at what frequency. Do that before the next vendor meeting. In our experience the list of things in daily use is far shorter than the list of things people believe is in use, and the gap between those two lists is the whole commercial argument.

Then count the edges rather than the modules. The expensive part of replacing an ERP is almost never the ledger; it is the forty interfaces to banks, carriers, shop-floor equipment, tax portals, dealer systems and the warehouse. A build decision that ignores the integration surface is a build decision that will be wrong.

Four routes, not three

Route	Best when	What the pitch leaves out
S/4HANA conversion, on-premise or self-managed private cloud	Deep SAP-shaped process complexity, in-house SAP skills, long horizon	Custom code remediation is the budget line that moves, and it is discovered late
RISE with SAP	You want SAP to run the platform and you are converting anyway	It is still a conversion programme; the subscription starts and does not stop
GROW with SAP	Midsize company willing to adopt standard process on public cloud	"Adopt standard" means dropping process you may currently compete on
Scoped custom build plus integrations	Narrow genuine module usage, modest statutory surface, process is a differentiator	You own the roadmap, the compliance updates and the support model permanently

SAP positions GROW with SAP at midsize customers specifically, bundling S/4HANA Cloud public edition with preconfigured best practices and adoption services, and says customers can go live in as little as four weeks. If your processes are close to standard, that is the shortest credible path on this table and you should take it seriously before you consider building anything.

The fourth route is the one that rarely appears on a comparison slide, because nobody on the slide sells it. Build the handful of capabilities you actually run, integrate everything else to the systems that already do it well, and keep the statutory functions in packaged software where the vendor carries the update burden. That is legacy application modernisation as a scoping exercise rather than a lift-and-shift.

We have shipped this shape. Our custom ERP for a large-scale industrial client unified HR, CRM, inventory and finance into a single browser-based platform across four departments, with one source of truth and no data silos after launch. That is the honest limit of what we will claim: it is evidence that a scoped build can carry a real industrial operation's core, not evidence that it is cheaper than S/4HANA for your business. We have also written up what Odoo really costs against a custom ERP in India, which is the same arithmetic applied to a smaller starting point and is worth reading if your footprint is narrow.

We are deliberately not quoting a cost range for an S/4HANA programme here. The public ranges come from vendors and integrators, they vary by an order of magnitude, and a number that wide is not evidence — it is decoration. Your usage export and three quotes written against your real scope will tell you more than any published figure.

What the SAP ECC end of maintenance does not mean

Four things that get asserted and are not in SAP's text.

It does not mean ECC stops running. Not on 31 December 2027 and not at the end of 2030. SAP's own wording routes customers who decline extended maintenance, or who reach the end of it, into customer-specific maintenance for their Business Suite 7 applications. The scope of that phase differs from mainstream maintenance, so read SAP's note on support after the end of mainstream maintenance before you assume what you would still receive.

It does not mean 2030 is the last date available. SAP's SAP ERP, private edition, transition option is "a time-bound subscription offering designed to provide business continuity from 2031 to 2033". The conditions are narrow and worth quoting: SAP HANA is the only supported database, there is a "minimum 2 TB for systems subscribed", systems "must be migrated to SAP ERP, private edition on SAP HANA before December 31, 2030", and the option is available only in combination with the max success plan during 2031–2033. It is a runway for large systems already committed to SAP, not a mid-market escape hatch.

It does not mean extended maintenance is automatic. It is optional and contracted, and SAP describes it as available for three years from the beginning of 2028.

It does not mean staying put is free. Running a business-critical ERP outside mainstream maintenance is a risk position involving security patches, statutory updates, and how your auditors and insurers view it. That is a question for your own advisers, with the answers in writing, and it should be priced like any other risk you carry deliberately.

The inventory that settles the decision

1. Export twelve months of transaction usage. Which transactions ran, how often, and how many distinct users touched them. This is the document the whole decision rests on.
2. List every interface in and out, with its owner, protocol and what breaks if it stops. Count them before you count modules.
3. Split functionality into statutory and operational. Statutory work is the strongest argument for staying with packaged software. Operational work is where your process may actually be a differentiator worth building around.
4. Get three quotes written against your scope, not the product's: a conversion, a public-cloud move, and a scoped build with integrations. Insist that each one states what it assumes about your custom code.
5. Ask the reversibility question. For each option, what does leaving in five years cost, and who holds your data model? We treat that as a reversibility test rather than a vendor question, and it separates the options more cleanly than price does.

When a scoped custom build is the wrong answer

Say it plainly, because a post that only argues one side is marketing. Do not build if you carry a heavy multi-country statutory surface — payroll in several jurisdictions, complex indirect tax, regulated reporting — because you will spend your engineering capacity chasing legislation instead of your business. Do not build if your manufacturing or supply chain genuinely needs what the standard product encodes. Do not build if nobody internally will own a product roadmap for the next decade, or if a customer or auditor contractually requires a named ERP.

And do not build as a reaction to a quote you found insulting. The decision that works is the one made from the usage export, which is also the one that tends to survive a change of CFO. If your conclusion is a staged modernisation rather than a replacement, our write-up on modernising legacy systems without breaking the business covers the sequencing we use.

So the next step is not a vendor meeting. It is the usage export, the interface list and the statutory split, produced by your own team, in the next three weeks. With those three documents in hand the 2027 date stops being a countdown somebody else is running and becomes a dated input to a decision you control — which is the only position from which the fourth route is even visible.