Four pages, about 17 minutes in total.
- A Fiori Elements App Is Not a Clean Core: Separating UI Technology from Extensibility — 4 min. The distinction this whole path is built around: a modern UI technology label is not evidence of a clean extensibility model underneath it.
- Before an S/4HANA 2025 Upgrade: 8 Fiori and Scope Decisions to Close First — 5 min. The scope decisions that set where the extensibility boundary sits, read with the distinction from step 1 in mind.
- Fiori Enrichment Record Template: Tracking What the SAP Export Does Not Supply — 4 min. How to record extensibility and technical-debt findings against an app without overwriting the source export when SAP refreshes it.
- “SAP Fiori Elements for CoPilot” Is Not Joule: How to Verify AI Capability Claims — 4 min. The same UI-label-versus-capability error applied to AI claims, and the check to run before repeating one.
Utilities and FI-CA carry a disproportionate share of custom code on most SAP ERP estates: EDM and AMI interfaces, BPEM exception handling, event modules and correspondence logic built up over years. A clean-core assessment that only inventories generic ABAP custom code will miss where the real extensibility debt sits. Every page in this path applies its distinction (UI technology versus extensibility, export data versus verified capability) specifically to that Utilities and FI-CA custom-code surface.
The pages in this path draw on the SAP export of September 2026 for product 2025 (Private Cloud): 1,547 of its 3,185 app records carry SAP Fiori elements as their UI technology value, one of 12 distinct values in that column. The export has no column for extension points, released APIs or customer code. The snapshot has not been revalidated against the live SAP Fiori Apps Reference Library.
Coming next for this role
Still to come that will extend this path: clean core and technical debt, and AI and Joule.
Related reading
- S/4HANA 2025 Conversion and Upgrade journey map — the full workstream and phase view behind this path.
Frequently asked questions
Why does this path put a clean-core distinction before the scope checklist?
Because the scope checklist assumes readers already separate UI technology from extensibility. Reading it first means the scope decisions in step 2 get the correct clean-core framing rather than a UI-technology one.
Why does an AI capability page belong on a clean core reading path?
An AI feature that turns out to be a UI label rather than an extensibility-relevant capability is the same category of error as mistaking a Fiori elements app for clean-core evidence: both substitute a technology label for a governed claim. The same verification habit applies to both.
Further reading
Continue your trail
You now have the Migration context.
Save this guide, continue to the next concept or return to the Knowledge Library with your context intact.
Migration
22 resources in this area.
Working on an FI-CA or IS-U implementation? I take on a limited number of advisory and architecture engagements.
Get in touch →
