SAP GUI Transactions Replaced by Fiori as Primary UX
In S/4HANA, the SAP Fiori launchpad becomes the intended primary interface, with role-based apps replacing many classic transaction codes. SAP GUI is not switched off and many tcodes still run, but new functionality, new fields, and SAP's own development effort increasingly land only in Fiori apps, while a growing list of classic transactions are marked not for productive use.
This page covers the shift from SAP GUI transaction codes to Fiori apps as the default working interface in S/4HANA, and what that shift actually breaks in a conversion project: authorizations, GUI-scripted interfaces, batch input jobs, and user habits. It focuses on what to check before cutover rather than what Fiori looks like.
Published 16 Sept 2026· 1,124 words
Classic ECC behaviour
In ECC, SAP GUI was the default and, for most users, the only working interface. Navigation ran through the SAP Easy Access menu and memorised transaction codes: VA01, ME21N, FB60, MIGO, and so on. Power users built personal favourites folders and chained tcodes together from muscle memory; training materials and work instructions were written as tcode sequences. Authorizations were built heavily around S_TCODE checks, sometimes as the only real gate on a function. Screen variants and transaction variants (via SHD0) let teams simplify or lock down a screen without touching the underlying transaction. Mass data entry relied on batch input sessions and call transaction routines that replayed GUI screen sequences programmatically. NetWeaver Business Client and early Fiori 1.0/2.0 apps existed in some ECC landscapes as an added layer, usually for approvals or dashboards, but they sat alongside GUI rather than replacing it. Back-office finance, logistics, and MM/SD processing stayed GUI-native almost everywhere.
S/4HANA behaviour
In S/4HANA, the Fiori launchpad is positioned as the primary UX: role-based catalogs and tiles replace the tcode-driven Easy Access menu as the intended entry point. Classic transaction codes largely still exist and can still be called directly, and SAP GUI remains installed and usable, particularly for configuration, expert-mode processing, and some cross-module transactions that never got a Fiori equivalent. What changes is direction of investment: a meaningful number of classic transactions are flagged as not for productive use going forward, some because the underlying data model changed (business partner replacing separate customer/vendor master maintenance is the clearest example), others simply because SAP stopped extending them. New fields, new business logic, and new checks increasingly appear only in the Fiori app, not in the GUI screen that technically still runs. Authorization design shifts from pure S_TCODE control toward Fiori catalogs, groups, and the OData services behind each app, which is a materially different security model, not just a UI skin change. Search help, My Inbox-style workflow, and personalization are native to Fiori with no GUI equivalent at all.
Project impact
- Custom reports and interfaces built on call transaction, batch input sessions, or GUI scripting against transactions that get deprecated or restructured break silently, sometimes only under production data volume, not in a small UAT dataset.
- Authorization roles built purely on S_TCODE do not carry over cleanly: users can be assigned the right role and still see an empty launchpad or a tile that opens but fails on the underlying OData service.
- Power users who built years of speed around chained tcodes and keyboard shortcuts lose that speed on day one; resistance concentrates in high-volume finance and logistics processing roles, not casual approvers who tend to prefer the tiles immediately.
- Period-end and month-end automation scripts (eCATT, WinGUI scripting, recorded batch input for closing tasks) that depend on a specific screen sequence fail when that sequence shifts, and this is often discovered during the first live close, not in testing.
- Fiori apps do not yet cover every variant, configuration option, or rare field combination that the classic transaction supported, forcing a GUI fallback for edge cases and leaving helpdesk staff supporting two UX paradigms for the same process.
- Training material, work instructions, and onboarding decks written as tcode sequences become misleading or wrong, and nobody owns rewriting them until a new hire gets stuck.
Migration actions
- Inventory every custom program, interface, and batch job using call transaction, batch input sessions, or GUI scripting against transactions likely to be superseded; treat this inventory as a pre-conversion gate, since these fail at cutover, not gradually.
- Cross-reference the simplification item list for any transaction in that inventory flagged as obsolete or redirected in the target release, and treat a not-for-productive-use flag as a hard blocker requiring remediation, not a note to revisit later.
- Redesign authorization roles to combine S_TCODE with Fiori catalogs, groups, and the OData/service authorizations behind each app, and test with representative business users, not IT staff who already have broad access.
- Rebuild GUI-scripted interfaces on the API/BAPI/OData layer instead of screen automation wherever technically possible; this is the durable fix, GUI scripting against a moving target is not a stable long-term integration pattern.
- Run a per-process UX gap analysis: for each business process, identify whether a Fiori equivalent exists, whether it covers the full variant set the business actually uses, and decide GUI fallback versus custom app versus process redesign where it does not.
- Split training and change management by user population: casual and approval users typically adopt Fiori without resistance; high-volume processing users need dedicated retraining and, in some cases, negotiated exceptions to keep a GUI path.
- Test the redesigned roles and rebuilt interfaces at production data volume and during a simulated period-end close, because list apps, mass processing apps, and authorization checks behave differently under real load than in a small functional test.
Whose problem this is
Both functional and technical, with the architecture or platform team owning the overall decision because it cuts across every module. Functional leads decide which Fiori apps are mandatory replacements versus optional; Basis and security own the authorization redesign; the ABAP/integration team owns remediation of GUI-scripted interfaces. No single module lead can own this alone.
Common pitfalls
- Teams migrate the functional process but leave GUI-scripted interfaces untouched on the assumption that 'the transaction still works'; true at go-live, until a later screen adjustment breaks the recorded sequence with no advance warning.
- Role redesign tested with a handful of test users passes UAT cleanly; mass role assignment at go-live then exposes catalog and group errors across whole departments simultaneously.
- Fiori list and report apps often filter, paginate, or aggregate differently from the classic GUI list transaction; a report that looks correct against fifty test records times out or returns incomplete results at real month-end volume.
- Users quietly fall back to whatever SAP GUI transaction still runs for anything unfamiliar in Fiori, which defeats the Fiori-first intent and leaves the organisation permanently running two overlapping UX paths.
- A rare business scenario, an unusual payment term, an obscure movement type, surfaces a field or variant the Fiori app never implemented, and this is discovered by an end user in production, not by the project team in testing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/sap-gui-transactions-superseded-by-fiori-apps-as-the-primary-uxERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.