Reading a UI5/Fiori Readiness Check

You already know this pattern if you’ve read an ABAP readiness assessment: a scan runs against a rule set and classifies every finding by severity. A UI5/Fiori readiness check does the identical thing for your front-end estate — deprecated libraries, stale OData versions, ageing manifest declarations — and it deserves the same disciplined reading, not a glance at a single score.

What actually gets checked

The real official tool behind this is the UI5 linter (@ui5/linter) — SAP’s own static-analysis tool, built to flag exactly the risk surface from Lessons 1–2: deprecated APIs and controls in your source, deprecated dependencies declared in manifest.json, and deprecated bootstrap attributes. Version 1.12 and later can even auto-fix a subset of findings directly. This is genuinely comparable to running ATC on ABAP — it’s just a Node-based tool run against JavaScript/XML source, not an ABAP transaction, so don’t expect it inside your ABAP toolchain itself.

Two fields inside manifest.json do a disproportionate amount of the work in any check:

• sap.ui5.dependencies.minUI5Version — the minimum runtime version the app requires. Far behind current = rising maintenance risk, even with zero deprecated controls.
• sap.app.dataSources → settings.odataVersion — declares whether that data source is “2.0” or “4.0”. This is what tells a scan whether an app is still sitting on the legacy path from Lesson 2.

This is precisely what our own platform’s Agent A7 (UI5/Fiori Check) looks at: SAPUI5 views, controllers, and the manifest — surfacing deprecated controls, OData V2→V4 paths, and Fiori Elements opportunities in one pass.

Reading the severity, not just the score

Exactly as with an ABAP scan, a hundred Critical findings concentrated in a handful of high-traffic apps is a completely different project than a hundred Low findings spread across your whole estate — different sequencing, different urgency, same overall count.

Try it yourself

Take a hypothetical (or real) set of five findings across a few apps: mix in at least one deprecated-library hit, one OData V2 app with no plan, one stale minUI5Version, and one freestyle app that’s a good Fiori Elements candidate. Sort them by severity using the framework above, then write one sentence on how that distribution would change your remediation sequencing.

Go deeper

For the UI5 linter itself — including the autofix capability — see SAP’s UI5 linter on GitHub and the official release announcement. To run this against your own estate today, use a free readiness scan.

Key takeaways

• The UI5 linter (@ui5/linter) is SAP’s real, official static-analysis tool for this — comparable to ATC, but it’s a Node tool against JS/XML source, not an ABAP transaction.
• manifest.json’s minUI5Version and dataSources.odataVersion carry most of the signal a check needs.
• Severity distribution, not the headline score, is what should shape your remediation sequencing — identical discipline to the ABAP readiness assessment.

Next: the capstone — pulling assess, decide, migrate, and verify into one real pass on one real app.