S/4HANA 2025 Upgrade Checklist | 8 Fiori and Scope Decisions

In 30 seconds

What it is This site's catalogue analysis sets out eight actions to complete before an S/4HANA 2025 release upgrade: freeze the snapshot, build a business-task register, review the 144 lifecycle-flagged apps, shortlist by scenario, validate against the target stack, capture implementation dependencies, test replacements, and separate clean core from UI technology. The eight are editorial recommendations derived from the export's structure, not instructions the export itself carries.

You use it when You are opening the Fiori and scope workstream for an S/4HANA 2025 release upgrade and need a closeable checklist with named owners before cutover planning begins.

Guide covers Migration / Release Upgrade

Why it matters

Release-upgrade teams often treat the Fiori and scope workstream as a formality: “we already have Fiori, we’re just moving releases.” The catalogue analysis prepared for this knowledge base disagrees. It sets out eight concrete actions to close before cutover planning, from freezing the source snapshot to separating clean-core assessment from UI technology, and none of them are optional busywork — skipping them is how a project discovers, during cutover, that a role points at an app the target stack no longer activates the way it used to. These eight are an editorial recommendation derived from the shape of the export, not something the export states; the export holds app records only. They apply equally whether the project is upgrading between S/4HANA releases or converting from SAP ERP with IS-U for the first time: the analysis does not distinguish between the two tracks, and a system-conversion team should close the same list.

Decide

The decision this page asks you to make is one of sequencing: which of the eight items below have to close before the upgrade starts, and which can run alongside the technical work. The split is editorial, from this site’s catalogue analysis, not a constraint stated in the export. For the keep, replace or retire framework covering the 144 lifecycle-flagged apps, use the lifecycle page; it is maintained in one place so the two pages cannot drift apart.

Item	Block the upgrade start, or run in parallel?	Why
1. Freeze the source snapshot	Block	Everything downstream cites this baseline. A snapshot that moves mid-project invalidates every count already quoted in a deliverable.
2. Build the business-task register	Block	The register is what steps 3 and 4 decide against. Without it, a lifecycle decision has no business task to test.
3. Review the 144 lifecycle-flagged records	Block	A role pointing at a Deprecated or successor-flagged app is a scope item, and finding it after build starts means reworking the role.
4. Build scenario-based shortlists	Block	The shortlist bounds the test scope. Starting the upgrade without it means testing scope is still open when cutover planning begins.
5. Validate each selected app against the target maintenance level	Parallel	Only shortlisted apps need this, and it can proceed while the technical upgrade runs, provided it finishes before role activation.
6. Capture implementation dependencies	Parallel	Dependency capture is per shortlisted app and does not gate the upgrade itself, but it does gate activation.
7. Test replacement candidates	Parallel	Testing needs a target system. Run it after the technical upgrade lands and before legacy access is removed.
8. Keep clean-core assessment separate from UI technology	Parallel	The extensibility inventory is its own workstream on its own clock; it informs refactoring design rather than upgrade readiness.

Do this

Discover · Solution Architect — Freeze this export as the source snapshot before scoping starts. Preserve the App ID, exact component, selected release, backend stack, lifecycle status and source row for every candidate app, and do not let a later export silently replace this baseline mid-project.
Discover · Fiori lead — Join actual transaction usage and existing launchpad role assignments into a separate business-task register. Do not overwrite the export’s source values with your proposed mappings; keep the two side by side.
Prepare · Fiori lead — Review the 144 records marked Deprecated or Available with Successor against the roles currently assigned to your users. Capture an explicit keep, replace or retire decision for every one your project actually touches.
Prepare · Utilities lead / FI-CA lead — Build scenario-based shortlists from the Utilities, FI-CA and core ERP indexes. Include normal processing, exceptions, reversals and high-volume work, not only the happy path.
Prepare · Fiori lead — Validate each selected app against the exact target maintenance level in SAP’s application documentation. Resolve the 140 blank backend-stack values and the 12 SP01 | SP01 records only for the apps you have actually selected.
Prepare · Security lead — Capture the real implementation dependencies for each selected app: software-component levels, service names and protocol, ICF nodes, catalogues, target mappings, roles, configuration, notes and licences where they apply.
Prepare · FI-CA lead — Test replacement candidates before removing legacy access. See the FI-CA specifics below.
Discover · ABAP lead — Keep the clean-core assessment separate from UI technology. Inventory the actual FQEVENTS implementations, user exits, modifications and integration dependencies before choosing a refactoring design; a Fiori elements record on its own proves nothing about released extension points.

Step 7 in full for FI-CA: test replacement candidates before removing legacy access, and specifically assess F4494 (Reverse Document) reversal coverage, F4531 (Manage Reconciliation Key) reconciliation keys, the payment-search apps F2588 (Search Payments), F3977 (Search Payments in Payment Runs) and F3978 (Search Payments in Lots), and the document-management actions in F6109 (Manage Documents (FI-CA)). These six apps sit where posting reversals, reconciliation and payment clarification concentrate, and a gap in any of them surfaces first during month-end, not during the upgrade test cycle.

Resolve the 140 blank backend-stack values and the 12 SP01 | SP01 records only where a selected app actually depends on them. Do not spend project time resolving all 152 records up front: most of them belong to apps outside your shortlist, and a blank stack is not evidence that the app is incompatible with your target release.

All app IDs, names, components, statuses and counts above come from the SAP export of September 2026 for product 2025 (Private Cloud): 85 records marked Deprecated, 59 marked Available with Successor, 140 records with a blank backend-stack value, and 12 records carrying the literal SP01 | SP01. The snapshot has not been revalidated against the live SAP Fiori Apps Reference Library.

Sequence matters more than the list suggests. Do the lifecycle review (step 3) before the scenario shortlisting (step 4): deciding what to keep, replace or retire first narrows the shortlist you then have to test, instead of building a shortlist you partly discard once the lifecycle review lands.

Deprecated and Successor Fiori Apps in S/4HANA 2025 — the full lifecycle table behind the 144-record count.
Core ERP Fiori Apps a Utilities Project Still Needs in S/4HANA 2025
Fiori 2025 App Explorer — search all 3,185 apps by component, status and backend stack.
SAP FI-CA business transactions: payments — process fundamentals behind the reconciliation and payment-search apps above.

Frequently asked questions

Does this checklist apply to a system conversion instead of a release upgrade?

Yes. The eight decisions come from this site's general catalogue analysis, not from anything specific to moving between two S/4HANA releases. A system-conversion team scoping Fiori for the first time from SAP ERP with IS-U should close the same eight items before cutover planning starts.

What decides whether one of the 144 lifecycle-flagged apps is kept, replaced or retired?

A documented business-task test against the app you would keep or move to: who uses it, at what volume, and whether the candidate covers exceptions and reversals as well as the normal case. The export tells you an app is Deprecated or Available with Successor; it does not tell you whether the successor is ready for your users.

Why resolve the blank backend-stack values before the upgrade instead of after?

140 apps in the export have no backend-stack value and 12 carry the literal string SP01 | SP01. Neither is evidence that the app is unavailable. Resolving them for apps you have actually selected, before cutover, avoids a late surprise when a role activation fails against the target maintenance level.