UI5 and Fiori Modernisation: A Technical Roadmap

Front-end technical debt in SAP landscapes is easy to underestimate. Most organisations completing an S/4HANA migration focus on ABAP remediation, transport logistics, and data migration — and then discover several hundred UI5 applications still running deprecated libraries, V2 OData services, and hand-rolled freestyle UIs that Fiori Elements could now generate automatically. This guide covers the technical facts you need before planning remediation.

The deprecated library problem

SAP has formally deprecated two entire UI5 library namespaces:

• sap.ui.commons — deprecated since UI5 1.38; scheduled for removal. Contains over 100 controls including Button, TextField, ComboBox, and the entire RichTooltip family.
• sap.ui.ux3 — deprecated since UI5 1.38. The Shell, ExactBrowser, ThingInspector, and DataSet controls are all in this namespace.

Applications using these libraries will not receive security patches, will not render correctly under SAP Horizon theme (the current default since UI5 1.108), and will break when SAP eventually removes the namespaces from the CDN.

Detection is straightforward with static analysis: scan all manifest.json files for sap.ui.commons or sap.ui.ux3 in the dependencies.libs section, then scan view XMLs and controllers for any sap/ui/commons/ or sap/ui/ux3/ sap.require or import statements. A typical 200-application estate will surface 30–60 affected apps.

The migration path is control-by-control replacement with the sap.m equivalent — sap.m.Button, sap.m.Input, sap.m.Select. No automated tooling performs this replacement reliably because the control contracts differ; each replacement requires a functional test.

OData V2 to V4 migration

Most SAP Gateway V2 services were written before OData V4 was finalised. The capability gap has grown significantly:

Capability	OData V2	OData V4
Batch requests	$batch supported	$batch supported, atomic mode added
Server-side operations	Partial	Full Function Imports / Actions / Functions
Delta queries	Not supported	$delta link supported
Aggregation	Not supported	$apply transformation pipeline
Type system	Limited	Full Edm.Date, Edm.TimeOfDay, Geography types
UI5 binding model	sap.ui.model.odata.v2.ODataModel	sap.ui.model.odata.v4.ODataModel

The v4.ODataModel binding API is not backward compatible with v2.ODataModel. Properties like bindElement, bindList, and bindProperty have the same names but different parameter contracts. A V2-to-V4 migration for a medium-complexity freestyle app typically involves rewriting all binding initialisation, reworking batch logic, and updating all $expand and $filter expressions to OData V4 syntax.

On the backend, SAP recommends exposing S/4HANA data via CDS-based OData V4 services (the @OData.publish: true annotation or SRVB service binding). Services generated this way automatically surface the V4 analytical capabilities and stay in sync with the CDS view’s release status.

The UI5 tech stack today

graph TD
    subgraph "Fiori Launchpad (BTP)"
        FLP["SAP Launchpad Service"]
    end
    subgraph "Application Layer"
        FE["Fiori Elements (templates)"]
        FS["Freestyle UI5 (sap.m / sap.f)"]
        WC["Web Components (SAP UI5 WC)"]
    end
    subgraph "Data Layer"
        V4["OData V4 (CDS-based service)"]
        V2["OData V2 (Gateway / legacy)"]
        RAP["RAP OData V4 (ABAP Cloud)"]
    end
    subgraph "Deprecated (do not use)"
        DEP1["sap.ui.commons"]
        DEP2["sap.ui.ux3"]
        DEP3["OData V2 new development"]
    end

    FLP --> FE
    FLP --> FS
    FLP --> WC
    FE --> V4
    FE --> RAP
    FS --> V4
    FS --> V2
    WC --> V4

    style DEP1 fill:#f44,color:#fff
    style DEP2 fill:#f44,color:#fff
    style DEP3 fill:#f88,color:#fff

Fiori Elements vs freestyle: the real trade-off

Fiori Elements is a template-based UI framework where the application behaviour is driven by OData V4 annotations rather than JavaScript code. The four standard floorplans — List Report, Object Page, Worklist, and Analytical List Page — cover the majority of transactional and reporting use cases.

The architectural benefit for migration projects is clear: an app built on Fiori Elements receives layout, accessibility, and theme updates automatically when SAP ships a new UI5 version. You own no layout code. The cost is constraint: if your UX requirements cannot be expressed in the annotation vocabulary (@UI.lineItem, @UI.fieldGroup, @UI.chart, @UI.selectionField, etc.), you hit the ceiling of what templates can do.

When to choose Fiori Elements:

• Standard transactional workflows (create/change/display/list)
• Reporting and analytics against CDS analytical services
• Any net-new app being built for S/4HANA Cloud

When to keep or build freestyle:

• Complex multi-step wizards with conditional navigation
• Apps with custom visualisation (charts beyond @UI.chart support)
• Apps embedding third-party components

For a migration project, apply this heuristic: if a legacy Web Dynpro or BSP application can be described as “list of objects + detail view,” rebuild it as a Fiori Elements app against a RAP or CDS V4 service. The rebuild takes less time than migrating the legacy UI, and the result is maintainable by any UI5 developer.

SAP Launchpad Service on BTP

The SAP Launchpad Service on BTP replaces the on-premise Fiori Launchpad for cloud-first customers. The key architectural differences:

• Roles and catalogues are managed in BTP Identity and Access Management, not in PFCG.
• Applications are deployed as Multi-Target Applications (MTA) to Cloud Foundry or served directly from the ABAP Cloud environment.
• The integration point with S/4HANA Public Cloud is via Managed System URLs in BTP Cockpit.
• Content providers are registered via the Content Manager and expose tiles/apps to the central launchpad.

The Launchpad Service supports a federated model: legacy on-premise apps can be surfaced alongside cloud-native apps in a single shell, which is a common interim architecture during phased migrations.

Before/after: a typical modernisation

Dimension	Before	After
UI library	sap.ui.commons / sap.ui.ux3	sap.m / sap.f
OData version	V2 via SEGW	V4 via CDS SRVB binding
Application type	Freestyle controller logic	Fiori Elements annotations
Hosting	On-premise ICM / SAP Web Dispatcher	BTP Launchpad Service
Authentication	SAP logon ticket / SSO	BTP Identity Authentication Service (IAS)
Theme	Belize / Bluecrystal	Horizon
Deployment	SAPui5 ABAP repository (transaction /UI5/UI5_REPOSITORY_LOAD)	MTA → Cloud Foundry or ABAP Cloud repository

What the migration effort actually looks like

Based on remediation patterns across mid-size ECC estates (150–400 custom Fiori/UI5 apps):

• Deprecated library apps: 3–5 days each for pure control replacement, assuming the OData service is not also being migrated simultaneously. Test effort dominates.
• V2 to V4 rebind: 4–8 days per app for freestyle apps with moderate binding complexity. Fiori Elements apps repointed to a V4 service take 1–2 days.
• Web Dynpro to Fiori Elements rebuilds: budget 8–15 days per app end-to-end, including the RAP BO or CDS service definition on the backend. This is net-new development, not migration.

The highest-leverage action before sizing your project is running static analysis across your UI5 repository to classify each app: deprecated library, V2-only, Fiori Elements-capable, or already compliant. Investing one sprint in that classification prevents months of mis-scoped remediation work.

---

SAP, S/4HANA, UI5, Fiori, OData, and related marks are trademarks of SAP SE.