T-code to Fiori transition in S/4HANA projects

The T-code did not disappear. It moved into a more complicated family arrangement with Fiori apps, CDS views, roles, catalogs and launchpad spaces.

A mature transition maps entry points by role and scenario. Business execution, support investigation and consultant configuration are not the same job, even if all three wear SAP badges.

Here is the project version: Many S/4HANA projects underestimate the practical transition from SAP GUI transactions to Fiori apps. The question is not whether Fiori is modern and SAP GUI is old. That sounds simple, which is how SAP topics lure us into underestimating them.

The real question is which entry point best supports the business role, the control requirement and the exception scenario.

The SAP evidence trail is less romantic: A transaction code is still valuable because it exposes technical heritage: report programs, screens, authorization traces, update behavior and customizing dependencies. In a clean demo this takes minutes; in production it asks for ownership, variants and a little courage.

A Fiori app is valuable because it can combine role-based navigation, embedded analytics, workflow tasks and exception handling. Both can exist in the same process, but they should not be trained as if they were interchangeable buttons.

This is where the support ticket usually starts: The safest method is to map each process step to its preferred user entry point. The screen is only the stage. The process is the plot.

For example, a key-user may create or monitor a document in Fiori, a support user may display technical detail in SAP GUI, and a consultant may use customizing transactions only during controlled change windows.

That distinction avoids giving business users broad transactions that are only needed by support or IT.

The control angle is the part worth underlining: Before replacing a T-code with a Fiori app, compare field availability, validation messages, workflow integration, output handling, authorization objects and audit expectations. A consultant should be able to explain this without opening a thirty-slide apology deck.

Some Fiori apps are excellent for operational monitoring but not intended to expose every technical field. Some GUI transactions remain necessary for deep troubleshooting even when they should not be part of daily business execution.

For training, the useful lesson is this: Training should explain the process outcome first, then the entry point. Users remember why they open an app when it is tied to a business event: release a blocked document, correct missing master data, monitor failed communication or post an exception. That is the difference between technical navigation and knowledge people can reuse.

That approach creates adoption faster than a navigation-only training deck.

Fiori adoption works when users understand the process outcome. Otherwise the new tile becomes an expensive shortcut to the old confusion.