How To Convert Your Frequently Used SAP GUI Transactions Into Fiori Apps?

Over the last decade, SAP landscapes have evolved rapidly, from ECC to S/4HANA, from on-premise to cloud, and from classic SAP GUI to SAP Fiori 3.0. Today, several SAP products are shipped Fiori-only, whereas in environments such as S/4HANA Public Cloud and SAP BTP applications, Fiori is no longer optional; it is the standard.

Yet, in most customer landscapes, critical business processes are still heavily dependent on traditional SAP GUI transactions. Because these transactions are familiar to users and are deeply embedded in their day-to-day operations, even if they no longer look modern.

If your organisation is also under pressure from the evolving SAP environments and you feel compelled to convert your frequently used SAP GUI transactions into SAP Fiori apps, read on.

Fear not. You don’t need to rebuild everything in Fiori, nor do you have to compromise on your core operational workflows. You can still modernise SAP GUI transactions into SAP Fiori apps without breaking what already works.

Understanding Fiori-fication of SAP GUI: What Does “Conversion to Fiori” Really Mean?

When organisations talk about “moving from SAP GUI to Fiori,” it is often assumed that this is a purely technical exercise. In reality, it is a change in how people work with SAP every day.

SAP Fiori has more functionalities than the classic GUI. It’s not simply a more modern-looking interface. It represents a fundamental shift from transaction-centric usage to role-based, task-driven work. With modern Fiori apps, your workforce can execute tasks faster with a few clicks, and instead of navigating through long lists of T-codes, they are guided toward the actions that matter most to their role, and access SAP on any device.

Most importantly, Fiori-fication helps organisations stay ahead of future SAP modernisation efforts.

As SAP continues to push Fiori-first and Fiori-only delivery models, adopting Fiori in a structured way today reduces risk, avoids last-minute pressure, and ensures that core business processes remain stable throughout the transformation.

How to Modernise Your GUI Apps to Fiori (A Hybrid, Usage-Driven Strategy)

Adoption of Fiori as the primary user interface is the biggest challenge in SAP transformation projects. And, one of the biggest mistakes organisations make is trying to apply a single conversion approach to all SAP GUI transactions. In reality, SAP landscapes are complex, user roles are diverse, and business criticality differs by process.

That is why, in most successful programs, we recommend a Hybrid Fiori Adoption Approach rather than a “replace everything with UI5” strategy.

A hybrid Fiori adoption approach acknowledges business reality. It means that not everything should be converted immediately; business value comes before technical purity, and governance matters as much as tools

The objective is not to eliminate SAP GUI overnight, but to maximise business value, minimise disruption, and align with SAP’s Fiori-first direction. This allows organisations to combine SAP Fiori apps, classic UIs, and transitional technologies in a controlled and role-based manner.

When executed properly, this approach delivers faster user adoption, higher user satisfaction, lower transformation risk, and a clear path toward full Fiori and S/4HANA alignment.

Suggested Reading: What’s New in SAP Fiori for the S/4HANA 2025 Release?

Step 1: Identify SAP GUI Transactions that You Want to Convert

When organisations begin their Fiori journey, the first temptation is to jump straight into conversion discussions. As consultants, we deliberately slow this down. Before talking about what should change, we first need to understand what exists today.

Before deciding what to convert, it is important to step back and ask a few practical questions:

• Which SAP GUI transactions do users rely on every day?
• Are these transactions standard SAP, or are they custom Z transactions?
• Which business roles and user groups depend on them to do their jobs?
• Are these transactions mainly used for display and reporting, or do they involve frequent data entry?
• Do these processes still align with SAP S/4HANA best practices, or are they remnants of older ways of working?

These questions help create an inventory of relevant transactions and highlight where SAP usage is concentrated across the organisation.

To answer them objectively, we typically rely on a combination of system data and business insight, such as:

• SAP Usage & Procedure Logging (UPL) to understand real transaction usage
• Workload analysis (ST03N) to identify frequency and performance patterns
• Targeted workshops with key users to capture how processes are actually executed

This step ensures the focus stays on high-impact GUI transactions that matter to the business, rather than attempting to modernise the entire SAP system at once.

Step 2: Usage-Based Scoping (What is Worth Converting)

Once there is clarity on what exists, the next step is to decide what is actually worth converting. This is where many Fiori initiatives either become focused or grow unnecessarily complex.

Instead of asking, “Which transactions should we convert?”, ask:

• Which T-codes do users genuinely work with on a regular basis?
• Which job roles rely on them to complete their daily tasks?
• How often are these transactions executed, and for what business purpose?

Looking at usage by role is particularly important. Some transactions may appear critical, but are used only by a small number of expert users. Others may seem unremarkable, but they support large operational teams every single day.

By applying usage-based scoping, you can intentionally avoid converting transactions that are rarely used and processes where a new UI would provide little real user experience benefit.

This keeps the Fiori-fication scope grounded in business impact. As a result, investment is directed toward scenarios that are highly visible, frequently used, and capable of delivering immediate user experience improvements.

Step 3: Check for Standard SAP Fiori App Availability

Before building anything, always check. Does SAP already provide a standard Fiori app for this transaction?

How this is done:

• SAP Fiori Apps Library analysis
• Mapping SAP GUI T-codes to available Fiori apps
• Checking compatibility with the current SAP release

Many customers are surprised to learn that 40–60% of commonly used GUI transactions already have standard Fiori equivalents, but they are simply not activated or configured. This step can significantly reduce cost and implementation time.

Step 4: Map SAP GUI T-Codes to the SAP Fiori Apps Library

After confirming that standard SAP Fiori apps exist, the next step is to systematically map your frequently used SAP GUI transactions to the SAP Fiori Apps Library. This is where the Fiori scope becomes concrete and defensible.

Rather than treating all transactions equally, look closely at relevance and business fit.

For each prioritised T-code, assess:

• Whether a corresponding Fiori app exists
• How closely the app matches the required business process
• The relevance rating of the app in the Fiori Apps Library
• Any functional differences compared to the SAP GUI transaction

Apps with high relevance ratings (*-rated)** and good functional coverage become the primary candidates for conversion. These are the quickest wins and usually deliver immediate value with minimal effort.

For transactions where no suitable Fiori app exists, or where the standard app does not fully meet business needs, flag them for one of the following paths:

• Custom SAP Fiori app development
• SAP GUI for HTML or Fiori transaction wrappers
• Temporary retention of the classic SAP GUI transaction

Making this distinction early avoids unrealistic expectations and keeps the program grounded in reality.

This structured mapping exercise leads to fast adoption of standard SAP Fiori apps, clear visibility into genuine functional gaps, and better-justified custom development.

Step 5: Apply the Right Technical Conversion Pattern

Once transactions are mapped and prioritised, the next step is to decide how each one should be technically enabled in Fiori. In a hybrid model, this is where different conversion patterns naturally coexist.

Rather than forcing a single approach, look at each transaction through a practical lens. How often is it used? How critical is it to daily operations? What level of user experience improvement is realistically achievable?

Based on this, transactions typically fall into one of the following patterns:

• Standard SAP Fiori apps for business scenarios already covered by SAP. These should always be the first choice, as they are SAP-supported, future-proof, and aligned with S/4HANA best practices.
• Custom SAP Fiori UI5 apps for high-value custom (Z) transactions. These are justified when the process is business-critical, frequently used, and benefits significantly from a redesigned, role-based user experience.
• SAP GUI for HTML or Fiori transaction wrappers for complex or low-priority transactions. This approach provides browser-based access and Launchpad integration without major redesign, making it suitable for transitional or specialist use cases.

Step 6: Use NWBC or Launchpad Strategically

In many real-world landscapes, especially during transformation phases, not every user role or process is ready to move fully to Fiori at the same time. This is where tools such as NWBC or a carefully designed Launchpad setup can play a role in providing a blended experience of Fiori and classic UIs

Used correctly, they can provide a blended experience that combines SAP Fiori apps for modernised processes and Classic SAP GUI transactions where no viable Fiori alternative exists yet.

This approach is particularly helpful when some user roles are still heavily dependent on SAP GUI and certain transactions are too complex or low-value to redesign immediately.

However, this flexibility needs governance. Over-reliance on Business Workplace (BWZ) or legacy navigation constructs can quickly undermine a Fiori strategy and turn temporary solutions into permanent constraints.

The key is to treat these tools as transitional bridges, not long-term destinations. They should support the journey toward a Fiori-first experience, not replace it.

Remember that flexibility without governance leads back to SAP GUI by default.

Step 7: Enforce a “Fiori-First” Strategy, But Allow Exceptions

A mature hybrid Fiori strategy does not mean that every decision is open-ended. Flexibility without direction quickly leads back to familiar SAP GUI usage. This is why successful programs clearly enforce Fiori-first as the default principle.

Make sure that SAP Fiori is the starting point for all new or redesigned processes; classic SAP GUI usage is allowed only with clear justification, and every exception is reviewed, documented, and time-bound.

This governance model helps avoid common pitfalls such as:

• Falling back to SAP GUI out of habit
• Diluting the overall UX transformation
• Losing momentum once the initial rollout is complete

Allowing exceptions is not a weakness; it is a practical necessity. However, those exceptions must remain controlled, temporary, and regularly revisited to ensure your organisation continue moving toward a Fiori-centric future.

Step 8: Set Up A Few Apps In A Sandbox Environment Before Going Live

Sandbox-based validation is a critical control point between design and change management. Before moving into formal change management and user rollout, it is essential to validate selected Fiori apps in a sandbox environment.

This step often determines whether a Fiori initiative succeeds or struggles post go-live.

A sandbox allows teams to test standard and custom Fiori apps in isolation, validate end-to-end business scenarios early, identify functional gaps before production rollout, and build confidence across IT and business users.

Unlike development or quality systems, a sandbox is ideal for exploration, experimentation, and early feedback, without delivery pressure.

What to include in the Sandbox scope?

We typically recommend including:

• A small but representative set of high-usage Fiori apps
• At least one app per key business role
• A mix of:
  • Standard SAP Fiori apps
  • Custom UI5 apps (if applicable)
  • Wrapped SAP GUI transactions (for comparison)

This provides realistic insight into how the hybrid Fiori experience will look for end users.

What to validate before going live

The sandbox is not just for UI validation. Key checks include:

• Functional completeness compared to SAP GUI
• Role-based authorisations and tile visibility
• Performance and response time
• Navigation flow and task efficiency
• Data consistency with backend processes
• Known limitations or differences from GUI behaviour

Any gaps discovered at this stage are far cheaper to address than after go-live.

Step 9: Transition to Change Management and Adoption

Once sandbox validation is complete and critical issues are addressed, you’ll be in a strong position to move into structured change management, training, and phased rollout.

So how do you ensure people actually use it, and use it well? Provide targeted user enablement sessions focused on real business scenarios, offer guided walkthroughs that show users how familiar tasks are performed in Fiori, and roll out Fiori apps gradually, role by role, rather than all at once. Also, maintain fallback options during early phases to reduce operational risk.

This approach helps users build confidence at their own pace, while ensuring that critical business processes remain stable.

Suggested Reading: Typical Challenges in Adopting SAP Fiori as the SAP UI

Fiori-fication of GUI Apps Is a Strategy, Not a Technical Task

Converting SAP GUI transactions into SAP Fiori apps is not a one-size-fits-all exercise. Successful Fiori-fication requires a careful balance of business process understanding, technical expertise, UX-focused thinking, and alignment with SAP’s long-term roadmap and S/4HANA strategy.

When these elements come together, Fiori delivers measurable business value.

At AvoTechs, we help organisations approach Fiori adoption in a structured and realistic way. We offer guidance on Fiori adoption, transformation of GUI-based applications to Fiori, enablement of Fiori Apps into your SAP Business Suite, development using Fiori Elements and freestyle SAPUI5, and extensibility of standard Fiori apps.

If your organisation is still heavily dependent on SAP GUI and unsure where to start, what to convert, or how to avoid unnecessary risk, we can help bring clarity.

Schedule a 30-minute consultation today.

Or if you’d prefer to explore our packages first, visit our offer page and navigate through the sections: Enterprises running SAP (select SAP development services) or SAP consulting company (select project outsourcing), based on your industry.