Step 1 of 5 Beginner 8 min

Your Fiori Apps Have a Technical Debt Problem Too

Lesson 1 — Every migration project fixates on ABAP remediation and forgets the UI5 layer sitting on top of it. Deprecated libraries don't get security patches and won't render under the current theme — and that risk compounds exactly the way ABAP debt does. Here's what's actually at risk, and how to see it in your own estate.

S
s4ready.ai Team

Every migration project fixates on ABAP remediation — transports, deprecated tables, released APIs — and quietly forgets the few hundred UI5 applications sitting on top of that layer. Some of those apps are running library namespaces SAP deprecated years ago. That isn’t cosmetic risk. It’s the same kind of compounding technical debt as an unremediated Z-program, just wearing a different file extension.

What’s actually deprecated, specifically

Two entire SAPUI5 library namespaces are deprecated, not just individual controls within them:

  • sap.ui.commons — deprecated since SAPUI5 1.38. Its successor is sap.m.
  • sap.ui.ux3 — deprecated since SAPUI5 1.38, superseded by the Fiori design language.

Apps still built on these namespaces don’t receive security patches, and they render incorrectly under the Horizon theme — the default SAPUI5 theme since version 1.108. That combination — no patches, broken rendering — is a real, present-tense risk, not a someday problem.

Three categories in a typical Fiori/UI5 estateCompliant: sap.m and sap.f controls, current OData version, receives patches and renders correctly. At-risk deprecated libraries: sap.ui.commons or sap.ui.ux3 in use, no security patches, breaks under the Horizon theme. Legacy OData V2: functional today, but the constrained, non-preferred path for new development.COMPLIANTsap.m / sap.f controls,current OData version✓ Patched, renders correctlyAT-RISKsap.ui.commons orsap.ui.ux3 in use✗ No patches, breaks on HorizonLEGACY ODATAStill on OData V2 —functional, but constrained△ Works today, non-preferred path
Three different risk profiles, usually mixed together in the same estate — and the mix is what a modernisation plan needs to see.

The correction worth making early

Here’s a distinction worth getting right before you plan around it: there is no confirmed, official SAP deadline that forces OData V2 off the way there’s a real end-of-mainstream-maintenance date for ECC. Don’t conflate the two. RAP (the ABAP RESTful Application Programming Model) still ships an official OData V2 service binding today — it comes with real, documented restrictions (no deep parameters on non-standard operations, limited ETag/draft handling), which makes it the constrained option rather than the forbidden one. The deprecated-library risk above is real and dated. The OData V2 risk is architectural pressure, not a countdown — treat it accordingly.

Try it yourself

Open one app’s manifest.json from a real or representative UI5 project. Check two things: does sap.ui5.dependencies.libs reference sap.ui.commons or sap.ui.ux3? And under sap.app.dataSources, what odataVersion is declared for its data source? Write down which of the three categories above that app actually falls into.

Go deeper

For the full deprecated-library detection method and a realistic effort model for remediation, read UI5 and Fiori Modernisation: A Technical Roadmap, or check any control directly against SAP’s own Index of Deprecated APIs.

Key takeaways

  • sap.ui.commons and sap.ui.ux3 are fully deprecated since SAPUI5 1.38 — no security patches, broken rendering under the Horizon theme.
  • There is no official OData V2 sunset date — don’t present it as a hard deadline. It’s the constrained, non-preferred path, not a forbidden one.
  • Classify your own estate into compliant, at-risk, and legacy-OData before planning any remediation — the mix is what actually determines project shape.

Next: what OData V2 to V4 actually changes, technically — not just “a version number.”

← Journey overview OData V2 to V4: What Actually Changes →