Mainstream maintenance for SAP ECC 6.0 (enhancement package 6 and higher) ends on 31 December 2027. That's about two years away, which sounds like plenty until you add up what a move to S/4HANA involves: a decision on the path, a hard look at custom code, data clean-up, testing, and training people on new screens. Most of that work can start now, whichever path you pick.
What actually ends in 2027
After 31 December 2027, ECC leaves mainstream maintenance. You can keep running it, but you're no longer on the standard support terms that most companies take for granted, including regular fixes and legal updates.
SAP offers two ways to buy more time. Extended maintenance runs until the end of 2030, at a premium of two percentage points on your maintenance basis. After that, customer-specific maintenance applies, which is narrower and covers far less.
The third option gets the most attention and is often misread. SAP ERP, private edition, transition option lets some customers run ECC-based systems until the end of 2033. It's aimed at large, complex customers. It needs a RISE with SAP contract, the systems have to move to SAP ERP, private edition before the end of 2030, and the transition period itself runs from 2031 to 2033. SAP has also said that customers who sign for SAP ERP, private edition by the end of 2025 can move to the transition option in 2031 without an uplift, so if you're in that group, that decision is only weeks away.
For a mid-sized company running ECC on-premise, the realistic plan is still to be on S/4HANA before the end of 2027, or to budget for extended maintenance and be there before 2030.
The three usual paths
Most moves to S/4HANA follow one of three paths.
- A new implementation (often called greenfield) starts S/4HANA fresh and redesigns processes. It's the cleanest result and the biggest change for users.
- A system conversion (brownfield) converts your existing ECC system, keeping your configuration, history and much of your custom code.
- A selective data transition sits between the two. You choose which processes to redesign and which data to bring across, usually with a specialist tool.
There's no universally right answer. The deciding factors are usually how much of your current process you'd keep, how much history you need, and how much custom code you rely on.
SAP DEVELOPERSFiori and ABAP developers, ready in 1–2 weeks.Talk to us →
Start with your custom code
Whichever path you choose, custom code decides a lot of the effort. ECC systems that have run for ten or fifteen years tend to carry hundreds or thousands of custom objects: Z reports, enhancements, forms, interfaces and modified standard code. Some of it is critical. A good share of it, in most systems we've seen, is no longer used at all.
A sensible first pass looks like this:
- Collect usage data for a few months, so you know which custom objects actually run in production.
- Run the custom code checks for S/4HANA in the ABAP test cockpit, against SAP's simplification list, to see which objects break or need changes.
- Put every object in one of three groups: retire it, rework it, or replace it with standard SAP or a new app.
- Estimate the rework group properly. That's the number that moves your budget.
Doing this before you choose a partner or a path gives you a far better conversation, and a more honest quote.
Look at the screens people use every day
S/4HANA comes with SAP Fiori, and moving is a good moment to retire the dense SAP GUI transactions your teams work around. Look for the places where people re-key data between SAP and spreadsheets, export reports to Excel every week, or track approvals in email. Those are usually the best candidates for a focused Fiori app, and they're often the changes users notice most.
Our SAP Fiori modernization checklist walks through how to pick them.
A 12-month plan
- Agree the target path and a realistic go-live window, with 2027 as the hard edge.
- Finish the custom code analysis and the retire, rework and replace list.
- Clean up master data, especially customers, vendors and materials, because conversion surfaces every inconsistency.
- Pick two or three Fiori apps that remove real manual work, and build them early so users see the benefit.
- Line up the people. Experienced ABAP and Fiori developers get scarce as the deadline gets closer.
How we help
We're a small team of SAP developers. We don't sell licences or run whole migrations. We do the hands-on development work that migrations depend on: analysing and reworking ABAP custom code, building Fiori and SAPUI5 apps with OData services, and replacing manual GUI steps with focused apps. Developers can join your team or your implementation partner's team within one to two weeks.
See our SAP development services, read how we replaced a manual SAP pricing process, or get a quote.
