What should we re‑test after an SAP upgrade?

Custom codeSAP replaced its three-tier extensibility model with four levels in August 2025. Code built on released APIs under stability contracts has, in SAP’s words, a very low probability of breaking during upgrades. Code on classic APIs sits a level below that, and code touching internal, non-released objects carries real upgrade exposure. Knowing which of your objects sits where is the first cut of the scope. The second cut is usage: SAP recommends running the ABAP Call Monitor or usage logging in production for six to eighteen months, and that the window includes at least one year-end close, aggregating through transaction SUSG because the raw data is deleted quickly. ABAP Test Cockpit will identify incompatible code — but testing still has to verify that the remediated code produces the same business outcome, which ATC cannot tell you.

Fiori launchpadSAP publishes a Fiori Upgrade Impact Analysis specifically to identify obsolete and deprecated apps and their successors, and a Launchpad Content Aggregator to gather what your business roles currently carry. The distinction is load-bearing: obsolete apps must not be used and are typically removed, deprecated apps should not be used but still function. When roles are not amended, the symptoms are specific and user-visible — “Service does not exist” for technical teams, “Reference Lost” on tiles for business users — and regression itself slows down because the functionality under test is missing. Two further traps: the groups-based launchpad became outdated at release 2402, and an unmigrated tenant can leave users facing an empty launchpad; and launchpad settings cannot be transported, so each system has to be configured independently. Approvals reach users through this layer too, so validate the inbox and the completed approval, not just the tile.

Roles & authorisationsSU25 is explicitly an upgrade transaction, run at initial implementation and for every subsequent upgrade. Its mechanics are the reason role regression is real rather than theoretical: step 2b transfers SAP’s new default values into the customer tables, step 2c merges those changed defaults into existing roles — roles with deleted authorisation objects receive new objects automatically after merging — and step 2d does not take all modifications into account, so the correction table has to be inspected directly. The net effect is that role content can change without anyone editing a role. Test with representative business users on the critical processes, not with administrator access.

Interfaces & contractsThe specific risk here is quieter than an outage. SAP documents that after an upgrade a higher version for some IDoc segments can be used even though the partner profile entry is unchanged — the sending system changes what it emits while the configuration looks untouched. The scale of that drift is not trivial: the INVOIC02 invoice IDoc alone carries dozens of differences between ECC and S/4HANA, including the long material number and currency amount fields gaining decimal places. On the API side, the governing concept is the stability contract: released objects carry one, non-released ones do not, and SAP’s API policy states that non-published APIs may change without notice. Validate the whole chain — SAP event, outbound processing, middleware, receiving endpoint, acknowledgement, business result. A green transaction is not proof of integration success.

Output & formsSAP declines to name a single strategic form technology on-premise. Its own guidance says that because of upward compatibility all solutions remain supported in a general sense, and that whether your Smart Forms still work “can only be answered by looking at the individual business application”. Per-application uncertainty is precisely the argument for validating rather than assuming. There is also a classic mechanical step here that is easy to miss: the program that regenerates requirements and formulas — the routines behind pricing and output determination — needs to be run after the upgrade. Validate output determination, form rendering, recipient selection, channel and dispatch. A successful posting does not prove the document went out.

Legal & localisationLegal change does not follow the upgrade rhythm. SAP states plainly that additional support packages or Country Legal Changes are provided between two support package stacks, because HR and statutory applications need a higher maintenance frequency than the normal cadence. An upgrade shifts your legal-change baseline, and the delta needs re-checking against what has been announced for each country you operate in. SAP maintains the Announcement of Legal Change application and legal change notes in SAP for Me for exactly this. Payment file formats are worth a look in the same pass, given the move from the older format engine to its successor.

Background jobs & the batch windowThere is a specific reason batch needs its own before-and-after baseline. SAP’s EarlyWatch Alert can compare up to eight weeks before an upgrade against the first eight weeks after — but it does so from system-wide ABAP statistics, and its severe-slowdown detection covers dialog and HTTP task types, not background processing. So the automated comparison is genuinely useful and structurally silent on the batch window. Capture the job runtimes and failure logs before the upgrade as well as after; the “before” snapshot is the step most teams skip and the one that makes the “after” interpretable. Validate the expected document or data updates and the downstream process, not just the completion status.

Reports & embedded analyticsEmbedded analytics is exposed at upgrade for a structural reason rather than an accidental one. SAP’s modelling tools are always based on existing SAP CDS views — you cannot build a custom analytical query directly on a database table. Every custom view therefore sits on top of an SAP-delivered view and inherits that view’s lifecycle and release contract. A view built on a released one is protected; a view built on an internal one is not. For critical reporting, compare meaningful business values before and after the release rather than confirming the report executes, and investigate differences you cannot explain.

PerformancePerformance regression after an upgrade tends to be found by users rather than by tests, because the test that would have caught it was scoped to functionality. Coverage needs to span classic GUI transactions, Fiori applications, background processing, integration scenarios and a peak period simulation — month-end close and payroll being the obvious candidates. Note the limits of the automated comparison honestly: the EarlyWatch event statistics cannot reflect parameter or hardware changes, and cannot automatically compare database-level updates. Where those apply, your own before-and-after baseline is the only evidence you will have.