Key Highlights
- Fewer than half of SAP customers have completed the move to S/4HANA, but mainstream maintenance for SAP ECC ends on 31 December 2027. The planning window is closing faster than the backlog is clearing.
- Gartner expects around 17,000 organisations to still be on ECC at the 2027 deadline, and roughly 13,000 to still run it in 2030. The holdouts skew towards larger, more heavily customised enterprises.
- The risk most likely to be underfunded in a rushed move is user adoption. Going from SAP GUI to Fiori changes how people work, not just what they log into.
- Programmes that treat training and change management as a final line item leak value after go-live through errors, workarounds, and a spike in support tickets.
- Workflow-based simulation before go-live, plus in-app guidance at cutover, is a practical way to protect adoption when the timeline is tight.
The deadline is fixed. Readiness isn’t.
For most enterprises, the SAP S/4HANA question has moved from whether to when. The trouble is that the window is closing faster than the backlog is clearing. SAP has confirmed that mainstream maintenance for SAP Business Suite 7, including ECC 6.0 enhancement packages 6 to 8, ends on 31 December 2027. Optional extended maintenance runs to the end of 2030 at a premium, and only a narrow set of complex customers on a RISE agreement can arrange support to 2033. SAP has said repeatedly that these dates aren’t moving.
Progress hasn’t kept pace. By the end of 2024, only about 39% of SAP’s roughly 35,000 ECC customers had started the move to S/4HANA, and at the current rate Gartner projects around 17,000 holdouts, nearly half the base, at the 2027 deadline, with roughly 13,000 still on ECC in 2030 (Gartner, reported by CIO). Migration has been steady but slow, and the customers still waiting tend to be the larger, more heavily customised ones, for whom complexity and cost are the two biggest barriers.
That last group is the one to watch. These are the enterprises with the most customisation, the most integrations, and the least slack in the calendar, and they’re the ones most likely to compress a multi-year programme into a scramble. The damage from that scramble tends to land in one place above all: the people expected to use the new system on day one.
Why so many enterprises are still waiting
The delay is rarely down to indifference. It reflects real difficulty, and the same three causes come up again and again.
Complexity and custom code. Years of tailored ABAP, bespoke transactions, and process workarounds live inside the ECC core. Moving to S/4HANA is a database migration that, depending on the route, forces business-process re-engineering and custom-code remediation. Research among SAP users by ASUG, the Americas’ SAP Users’ Group, found business-process change to be the single biggest barrier to migration, named by 49% of those surveyed, with organisational inertia close behind at 37%.
A tight talent market. Experienced S/4HANA specialists are scarce, especially for data migration, finance configuration, testing, and cutover. Demand for them concentrates as the deadline nears, and the best delivery architects get booked first. Waiting doesn’t only delay the project. It raises the price of the people who deliver it.
Budgets that underestimate scope. Migration costs routinely land higher than approved. Gartner notes these migrations routinely run longer than planned, and the cost scales with complexity, from a couple of million dollars to as much as a billion for the largest, most heavily customised installations (Gartner, via CIO). The thread running through all of it is treating migration as a technical replatform rather than a business transformation.
None of these is a reason to panic into a poorly planned cutover. They’re reasons the time that’s left has to be spent well.
The risk a rushed move tends to miss
Compress a programme of this size and the technical risks are the ones everyone plans for: escalating day rates, custom code discovered mid-project, data-quality problems that surface late. The risk that slips is quieter, and it shows up only after go-live. It’s whether people adopt the new interface.
Going from SAP GUI to Fiori is a change of interaction model, not a reskin. Role-based apps and a launchpad replace transaction codes and the dense screens people know by heart. A finance clerk who has posted invoices in the same GUI transaction for a decade is being asked to relearn a daily task. Research on Fiori adoption points to long-term GUI users’ resistance and skill gaps as leading obstacles, not footnotes (JENRS, 2026).
The failure mode is well understood. A technically successful migration can still fail on user acceptance, with resistance surfacing as workarounds, spreadsheets, and shadow systems that no database migration removes on its own. Airbus’s head of digital, Catherine Jestin, made the underlying point plainly: a purely technical migration that doesn’t rethink and simplify processes delivers little efficiency or return, and only buys time (via The Register). It fits the wider pattern McKinsey has measured, where enterprises capture only about a third of the value they expect from digital transformations. When adoption slips, the effects are concrete. Support tickets climb, processes slow, and an error made early in a cross-application workflow like Procure-to-Pay or Order-to-Cash ripples across every team downstream.
In a rushed programme, training and change management are scheduled last and cut first. That’s the wrong order.
Planning your SAP training and adoption approach? Our guide covers how modern enterprises scale training, boost adoption, and reduce support costs.
What a rushed migration costs
The bill for compressing the timeline arrives in three places.
The first is direct programme cost. Later starts mean higher day rates and thinner access to the best delivery architects. Rate escalation alone can add double digits to the system-integration line before anyone changes a line of code.
The second is lost productivity after go-live. Push users onto a new interface without enough hands-on practice and throughput drops during the period the business can least afford it. An error early in a workflow, a mismatched purchase order or a missed goods receipt, blocks invoices and delays payments downstream.
The third is support and rework. Under-prepared users lean on colleagues and raise tickets instead of resolving issues themselves. That load is a training gap, not a system fault, and it persists until the gap is closed. Organisations that treat migration as purely technical end up paying for it here, in the months after go-live, in the part of the programme that never made the critical path.
How to protect adoption without missing the deadline
The aim isn’t to slow down. It’s to put effort where it pays back, which means giving user readiness a slot on the plan rather than whatever time is left at the end.
Build training around processes, not the app catalogue. Work through the end-to-end flows people run, Order-to-Cash, Procure-to-Pay, Record-to-Report, so a user learns how their step feeds the next across the new interface and the simplified data model. A walk through the Fiori launchpad teaches the menu. A run through the process teaches the job.
Give users real repetitions on the new screens first. You can’t rehearse hundreds of users on a production S/4HANA system, and a set of screenshots won’t build the recall a daily transaction needs. Assima’s object-based cloning produces an editable, true-to-life copy of the Fiori workflow, so users practise the full sequence, exceptions included, on a copy that reacts like the real system. Assima Train packages those clones as guided practice. Schneider Electric shows the approach at scale: as part of a programme that replaced 130 applications across 18 countries, its teams built more than a thousand SAP simulation exercises and trained tens of thousands of staff on clones, blending classroom sessions with self-service practice they could repeat at their desks, and cut annual training costs by 30 per cent against dedicated training environments. The pattern holds mid-migration too. Mubea, an automotive components manufacturer, trained its people on a new SAP environment in phases, three to four weeks before each business unit went live, building the lessons on clones while the live system was still being finalised, so training was ready ahead of cutover rather than racing to catch up with it.
Put help where the work happens at cutover. The opening days on Fiori are when errors and support calls climb, and a user stuck mid-transaction won’t break off to read a manual. Assima Assist prompts them through the step inside the live system, and Assima In-App Search pulls the right process guide onto the screen they’re already on.
Judge readiness by capability, not attendance. The question is whether a user can carry a full process from start to finish, not whether they sat through a session. That answer tells you far more about how cutover will go than any completion report.
Conclusion
The 2027 deadline isn’t moving, and the backlog is real. But a deadline is a constraint, not a strategy. The enterprises that come through this well won’t be the ones that cut the most corners to hit the date. They’ll be the ones that protect the part of the transformation most likely to be sacrificed under pressure: whether people can use the new system.
A migration succeeds when users adopt what’s delivered. Going from SAP GUI to Fiori changes daily work for thousands of people, and no database migration closes that gap on its own. Give users realistic practice before go-live and support inside the live system afterwards, and a tight timeline becomes manageable rather than dangerous. Skip it, and the cost doesn’t disappear. It moves downstream, to the months after go-live, where it’s hardest to recover.
Don’t Let User Adoption Become Your Migration Risk!
Frequently Asked Questions
Let’s Answer Some of Your Questions.
Mainstream maintenance for SAP ECC 6.0 (enhancement packages 6 to 8) ends on 31 December 2027. Optional extended maintenance is available until the end of 2030 at an added cost, and a limited RISE-based transition option can extend support to 2033 for select complex customers. After mainstream maintenance ends, systems move to customer-specific maintenance, which doesn’t include new security patches or legal updates.
Fewer than half have completed the move. Gartner estimated that only around 39% of SAP’s roughly 35,000 ECC customers had started the move by the end of 2024, and projects around 17,000 holdouts at the 2027 deadline, with roughly 13,000 still on ECC in 2030.
The most under-managed risk is user adoption. Going from SAP GUI to Fiori changes how people work day to day, and programmes that underfund training and change management often see errors, workarounds, and rising support volumes after go-live, even when the technical migration succeeds.
Fiori uses role-based apps and a launchpad instead of the transaction codes and dense screens long-term users know. It’s a different interaction model, so experienced GUI users effectively relearn familiar tasks. Research consistently names this resistance and the related skill gaps as leading obstacles to Fiori adoption.
Design training around end-to-end business processes, let users practise on realistic simulations of the new system before go-live, and provide in-app guidance during the first weeks of cutover. Simulation and digital adoption tools let people build confidence without touching live systems or real data, which lowers errors and reduces the post-go-live support load.
