If your go-live plan ends at “train the users on Fiori,” you haven’t decided anything. You’ve deferred the decision to the users — and they’ll decide to keep using SAP GUI.
Every S/4HANA program we’ve worked on across the GCC and North America has shipped a beautiful Fiori launchpad. Most still have a meaningful share of users quietly running transactions in SAP GUI six months after go-live. The reason isn’t that Fiori is worse. It’s that SAP never forced the issue — and most transformation teams didn’t either.
GUI never actually left
The technical fact buried in go-live decks: SAP GUI didn’t leave with S/4HANA. SAP GUI for HTML (WebGUI) lets classic transactions run inside a browser and be embedded as tiles directly in the Fiori launchpad, no re-platforming required, and SAP continues to maintain the SAP GUI family — GUI for Windows and SAP Business Client — across on-premise and private-cloud S/4HANA. One adjacent technology, NWBC for HTML, is being discontinued starting with S/4HANA 2025, but that is specifically NWBC for HTML — tot SAP GUI, which continues, with the Fiori launchpad offered as the recommended destination.
So the old interface isn’t a legacy artifact users must fight to reach. It’s one click away, sanctioned by SAP, and often faster for a power user who already knows the transaction code. If go-live arrives and a buyer finds ME21N sitting on their launchpad next to “Create Purchase Order,” the outcome is predictable: they use the screen they already know. That isn’t rebellion — it’s the path of least resistance, and it’s built into the architecture.
The launchpad is a mirror, not a fix
Fiori was designed from the outset as role- and persona-based: rather than one dense transaction exposing every field to everyone, an app shows only what a role needs — a buyer sees procurement fields, finance doesn’t see the technical ones, even though both sit on the same EKKO/EKPO tables. That design only works if the underlying role model is disciplined. In practice it frequently isn’t. SAP’s own launchpad guidance is a quiet confession of how often this goes wrong: it warns against oversized catalogs and undifferentiated roles precisely because they produce overloaded, sluggish, duplicate-riddled launchpads. When a user meets a launchpad that’s slow, cluttered, or missing the app they need, that’s a role-engineering failure, not a user-competence failure — but it gets labeled the latter, and “just let them use GUI” hardens from temporary bridge into permanent policy.
Why adoption actually fails
The failure pattern is consistent, and rarely about the software:
- Skill gaps go untreated because launchpad orientation is skipped in favor of jumping straight into module process training, leaving users navigationally lost before they learn the process.
- Power users — the informal experts colleagues turn to — often default to GUI themselves, and their influence spreads resistance faster than any formal training counters it.
- New tech, old operating model: organizations adopt the interface but leave approval chains, role definitions, and process ownership untouched, so Fiori sits on top of the old way of working instead of replacing it.
- Change management arrives late. SAP practitioner analysis of S/4HANA programs finds that late business-user involvement increases resistance, generic training fails against real-world usage, and adoption problems surface only after go-live — because change was treated as a support activity, not a core workstream. The same source is blunt about the fix: measure adoption, not just technical readiness, and train on business impact, not system features.
The complication nobody plans for
To make it harder, GUI and Fiori aren’t fully interchangeable, so “just pick one” isn’t a strategy either. Some S/4HANA innovations — certain bank-connectivity configuration, newer asset-accounting functions, select finance configuration — are Fiori-only, with no GUI equivalent. Conversely, a meaningful set of transactions and technical fields still live only in GUI, and SAP’s own “Identifying Classic User Interfaces” guidance tells customers to check case by case whether a given classic screen is sanctioned for continued use rather than assuming it’s safe. That’s exactly why “GUI vs. Fiori” is the wrong framing. The real question is: which transactions, for which roles, move to Fiori now; which stay in GUI by deliberate exception; and which need both because the functionality is genuinely split.
Reframing the problem
Fiori adoption is not a UX problem — the UX is, for the tasks it was designed around, genuinely better: fewer clicks, role-relevant fields, mobile access. It fails as a behavior-change program because most organizations treat go-live as a screen swap: turn on the launchpad, run a training deck, hope habits follow. They don’t. Habits follow role clarity, repeated reinforcement, and a workforce told explicitly which old screens are gone and why — not left to discover on their own that GUI is still sitting there, one click away and faster for the task they already know.
A pre-go-live plan that actually moves roles off GUI
| Workstream | What “done” looks like before go-live |
|---|---|
| Role/persona redesign | Every target role’s launchpad reviewed for tile count, catalog overlap, and missing apps — not templated from SAP defaults |
| GUI retirement decisions | A documented, role-by-role list of which transactions are retired, which stay as sanctioned exceptions, and which require GUI due to functional gaps |
| Launchpad orientation | A dedicated navigation session before module training — so users learn the launchpad model, not just the process steps |
| Power-user enablement | Power users trained and certified as Fiori-first advocates ahead of the broader population, so informal influence reinforces the new model |
| Operating-model alignment | Approval chains, role definitions, and process ownership updated to match the new interface — that left running on the old model underneath |
| Adoption measurement | Launchpad usage analytics and GUI-access logs tracked from week one, with named accountability for closing the gap when users revert |
The organizations that get this right don’t ask “is Fiori adopted?” a year after go-live. They know the answer in week two — because they measured it, decided in advance which transactions were non-negotiable, and treated the launchpad as an operating-model decision, not a UI update.
### Sources – SAP Community — NWBC for HTML Will Be Discontinued (S/4HANA 2025; SAP GUI continues): https://community.sap.com/t5/technology-blog-posts-by-sap/nwbs-for-html-will-be-discontinued/ba-p/13807408 – Pathlock — SAP GUI vs SAP Fiori (coexistence, WebGUI): https://pathlock.com/blog/sap-fiori/sap-gui-vs-sap-fiori/ – HEFLO — SAP Fiori Launchpad Explained: Tiles, Roles, Spaces, Pages and Apps: https://www.heflo.com/blog/sap-fiori-launchpad-explained – SAP Community — SAP Fiori for S/4HANA: Identifying Classic User Interfaces available for continued use: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-fiori-for-sap-s-4hana-identifying-classic-user-interfaces-available-for/ba-p/13445236 – SAP Community — Accelerating S/4HANAAx Success: Why Techical Excellence Alone Is Not Enough (change management, measure adoption): https://community.sap.com/t5/technology-blog-posts-by-members/accelerating-s-4hana-success-why-technical-excellence-alone-is-not-enough/ba-p/14302427 – Qorelo — SAP Change Management & User Adoption: https://www.qorelo.com/insights/sap-change-management-user-adoption-success