SAP ECC Maintenance Ends 31 December 2027: A Price Step, Not a Switch-Off

On 31 December 2027, SAP ends mainstream maintenance for SAP ECC 6.0 and the other core applications of SAP Business Suite 7. Nothing switches off on 1 January 2028. Your system keeps running, your users keep posting invoices, and SAP will still sell you support. What changes is how much you pay for it and what you get.

That distinction matters, because a lot of the advice in circulation treats 2027 as a cliff. For most companies still on ECC it is not, and they know it: the largest group of remaining ECC users is planning for 2030. The real risk is a different one. The work that actually decides the date (custom ABAP, interfaces, data) gets scoped late, and 2030 turns out to be as tight as 2027 was.

This is for CIOs and SAP leads at mid-size companies, most of them in German-speaking markets, who still run ECC and have to decide what the next three years look like.

What SAP Actually Committed To

The terms are on SAP's maintenance strategy page and were first announced in February 2020:

• Until 31 December 2027: mainstream maintenance for the Business Suite 7 core applications, SAP ERP 6.0 among them, on the latest three enhancement packages. If your system sits on an older enhancement package, check SAP Note 2881788 (linked from that page) before you build a plan on the 2027 date.
• 1 January 2028 to 31 December 2030: optional extended maintenance, at "a premium of two percent points on the maintenance basis". Put simply, the maintenance rate you pay today goes up by two points.
• If you do not take extended maintenance: you move automatically to customer-specific maintenance. What that covers is described in SAP Note 52505, linked from the same page. Read it before you assume it is enough.
• For S/4HANA: SAP has committed to maintenance until the end of 2040.

There is a further route for a smaller group. In August 2025 SAP set out the SAP ERP, private edition, transition option: a time-bound subscription that carries ECC from 2031 to 2033 inside SAP's private cloud. The conditions are strict. "Systems must be migrated to SAP ERP, private edition on SAP HANA before December 31, 2030." HANA is the only supported database, the option comes only together with the max success plan for 2031 to 2033, and SAP sets a minimum of 2 TB for systems subscribed under it. SAP says it is meant for "our largest and most complex SAP ERP customers". The "commercially equivalent terms" SAP offered were for customers who committed to private edition by the end of 2025.

Whichever level you choose, put one question to SAP and your partner in writing: which legal changes (tax, payroll, e-invoicing formats) will still reach your ECC system, and until when. For a German company, that answer alone can decide whether staying put is viable.

What the Rest of the Market Is Doing

DSAG, the German-speaking SAP user group, ran its Investment Report 2026 with 198 respondents between 8 December 2025 and 21 January 2026. Of those, 54 percent still run ECC or the older Business Suite, down from 68 percent in 2024.

On timing, almost half of respondents plan to switch to S/4HANA by the end of 2030, which DSAG points out means paying for extended maintenance. Another 37 percent want to switch by the end of 2027, and just 4 percent are aiming for 2033 and the private edition transition option.

DSAG's chairman, Jens Hungershausen, gave the reasons plainly: skills shortages, parallel transformation projects and limited budgets are pushing schedules back, "even if this results in higher maintenance costs".

Public buyers are moving too. Our own count of EU public tender notices finds roughly 200 S/4HANA migration procedures per half-year through 2025 and 2026, and more than 300 in 2026 by the start of October, most of them in Germany. The work is happening. It is spread over a longer runway than the 2027 headlines suggest.

Where the Work Actually Is

The technical conversion from ECC to S/4HANA is well tooled by SAP and its partners. If you run a lightly customised ECC with a handful of standard interfaces, your integrator has done this many times and most of what follows is not your problem.

It becomes your problem in proportion to how much you built yourself.

Custom ABAP: where projects slip

S/4HANA is not ECC on a new database. Parts of the data model changed. Customers and suppliers become business partners. Finance and inventory postings were consolidated into fewer, wider tables. Some transactions and functions were removed or replaced.

Custom code that reads tables directly, relies on an exit that moved, or quietly assumes a sort order (HANA does not promise one unless the query asks for it) can pass a syntax check and still do the wrong thing. That last kind is what hurts, because it shows up in integration testing or after go-live, not in the code scan.

The process that works:

1. Measure usage first. Switch on usage logging in production (the ABAP call monitor, transaction SCMON) and leave it running through a full year-end close. In long-lived systems a sizeable share of custom objects often never runs. Code nobody executes gets deleted, not migrated.
2. Run the analysis tools against what remains. SAP's checks find candidate issues. They cannot tell you which ones matter to the business.
3. Classify every object. Retire it, replace it with standard functionality, fix it in place, or rebuild it outside the core. One decision per object, with a named business owner.
4. Test by process, not by object. Changing the code is the cheap part. Proving that order-to-cash and month-end close still produce the same numbers is the expensive part.

Projects slip here for a boring reason: nobody counted early enough. The volume of custom code is known only roughly, the people who wrote it have often left, and the real findings arrive in the second test cycle, after the date has been announced internally.

Interfaces, and PI/PO on the same clock

ECC rarely stands alone. IDocs to the warehouse, RFC and BAPI calls from the shop floor, flat files to the bank and the tax advisor, a customer portal reading a database view somebody created in 2011. Every one of them has to be found, tested, and in some cases rebuilt.

If those interfaces run through SAP Process Integration or Process Orchestration, there is a second deadline on the same dates. SAP's Architecture Center says PI/PO is approaching "the end of standard maintenance in 2027", that customers can extend maintenance until 2030, and that SAP support ends after that. SAP points PI/PO customers to SAP Integration Suite, which comes with a migration assessment and wizard-based migration tooling.

The tooling helps with the standard objects. It does not tell you which interfaces still serve anything, and custom mapping logic still needs a person to read it. Build the inventory from middleware configuration, logs and scheduled jobs, not from a questionnaire. Then plan the ERP move and the middleware move together. Done one after the other, every interface gets tested twice.

Data migration

In a system conversion your data moves with the system, and so does its quality. The business partner conversion is usually the first collision: duplicate customers, suppliers who are also customers, addresses in free-text fields, tax numbers in the wrong place. All of that has to be cleaned before conversion, not during it.

In a new implementation you extract, cleanse, transform and load, and the hard part is reconciliation. Finance signs off when balances and open items match, not when the load job finishes. Build the migration as repeatable code that you can run a dozen times against steadily cleaner data, comparing results automatically on every run.

On either path, archive what you no longer need first. Less data means shorter conversion runs and a shorter downtime window.

Clean core extensions

The temptation in a deadline-driven project is to carry every modification across and promise to tidy up later. Later does not come.

SAP's name for the alternative is clean core: leave the standard system unmodified and build extensions against interfaces SAP publishes and keeps stable, either inside S/4HANA or alongside it on the SAP Business Technology Platform. Not everything can be clean on day one. The rule you can actually hold is simpler: nothing new gets built the old way. Every modification you avoid now is one you do not retest at every future upgrade.

A Decision Frame

There are three realistic paths, and a fourth that gets less attention.

Go live on S/4HANA by 31 December 2027. This fits companies that have already started, run a mostly standard system and have a partner booked. From today that is fifteen months, and few finance teams will accept a cutover in the middle of year-end close. If your custom code analysis has not been done, this is probably not your path.

Pay for extended maintenance and go live by 2030. This is where most of the market is heading. The cost is the two-point premium; confirm with SAP how it applies if you go live part-way through the period. The risk is treating 2030 the way 2027 was treated: as distant until suddenly it is not.

Take the private edition transition option to 2033. That means a RISE with SAP contract, HANA, your system moved to SAP ERP, private edition before 31 December 2030, the max success plan and the 2 TB minimum. For a mid-size company it is rarely the cheapest way to buy time.

Leave SAP. For some mid-size manufacturers and distributors a smaller ERP is a real option. The interface and data work does not shrink. It becomes most of the project.

The Next Six Months, Whichever You Pick

Between now and the end of March 2027, all of this pays off on every path:

1. Confirm your starting point. Enhancement package, database, maintenance contract. Ask your SAP account team in writing for the extended maintenance terms that apply to you.
2. Switch on usage logging now, so it captures the year-end 2026 close.
3. Run a custom code analysis and come out with a count, not an impression: how many objects, how many in use, how many touch the changed parts of the data model.
4. Build the interface inventory, including everything that runs through PI/PO, with an owner and a decision for each interface.
5. Start master data cleansing, customers and suppliers first.
6. Stop adding modifications. New development follows clean core from today.
7. Put the 2028 maintenance uplift in the 2027 budget as a known cost rather than a surprise.
8. Book capacity: the partner, your internal SAP team, and the developers who look after the systems around SAP. Skills shortages are one of the reasons DSAG's members give for slipping schedules.

Counting back from a 2030 go-live: test cycles and cutover rehearsals in 2030, build and remediation in 2029, design and data cleansing in 2028, analysis now. There is less slack in that than it looks.

Where to Get Help

We are not an SAP functional consultancy and we do not run S/4HANA conversions; we work beside the partner who does, on the interface inventory and rebuild, the data migration code and its reconciliation, and the applications built around ECC that have to survive the move. That work is described on our ERP modernisation page, and legacy system maintenance covers the systems that stay where they are until you move. If you want the estate around your ERP counted before you sign a programme, write to office@c9group.dev.