SAP Testing Strategy (2): S/4HANA Upgrade

In Part 1, we explored large-scale Migration testing strategies for transitioning from ECC to S/4HANA, focusing on massive data conversion verification. In Part 2, we'll examine SAP S/4HANA upgrade testing strategies.

SAP S/4HANA releases new versions quarterly. Many companies perform regular upgrades, yet business disruptions from unexpected issues continue to repeat. Why does this keep happening?

This article examines common problems during S/4HANA upgrades, their root causes, and verification strategies optimized for quarterly recurring work.

Common Problems During S/4HANA Upgrades

After upgrading SAP S/4HANA to the latest release, many companies face the same problems.

What actually happens in the field:

• Sales team: "App ID not found" error prevents screen from opening when querying sales orders in Fiori app

• Purchasing team: Specific fields disappear in purchase approval workflow, halting the process

• Finance team: API calls to external systems fail, preventing voucher creation

• IT team: Custom reports can't retrieve data due to CDS View changes

These aren't simple bugs. They're issues that occur structurally during SAP release changes.

Why Does This Happen?

There are three most common causes of S/4HANA Upgrade failures.

1. Fiori App ID Changes and Deprecated Fields

SAP improves Fiori apps with each release. During this process, app IDs change or specific fields become deprecated.

Problem scenario:

• Previous release: Sales order query app ID F1234

• New release: App ID changed to F1234A

Result: Existing bookmarks, permission settings, and custom tiles all stop working

After the upgrade, users see only an error message saying their usual app "does not exist." With deprecated fields, screens open but saving fails, disrupting work.

2. CDS View and OData Service Version Changes

S/4HANA provides data through CDS Views and OData services. When releases change, these structures change.

Types of changes:

• CDS View name changes: I_SalesOrder → I_SalesOrderTP

• Field additions/deletions: Required fields added or existing fields removed

• OData version upgrades: V2 → V4 transition changes calling methods

A single CDS View change can simultaneously shut down dozens of reports, dashboards, and external integration APIs.

3. Behavioral Differences Between GUI and Fiori

In SAP systems, GUI (SAP GUI) and Fiori apps coexist. Release changes create subtle behavioral differences between the two interfaces.

Real case:

• GUI transaction ME21N: Works normally

• Fiori purchase order creation app: Required input validation fails under identical conditions

• Cause: Fiori app applies new validation logic while GUI maintains previous logic

Since actual work uses both GUI and Fiori together, testing each interface separately won't catch errors occurring at transition points.

These problems occur structurally whenever SAP releases change. Unlike ECC to S/4HANA transitions, upgrades involve changes to functions and interfaces rather than system architecture.

So if many companies test before upgrades, why don't they catch these problems beforehand?

Limitations of Traditional Testing Methods

Most companies test before SAP upgrades. But problems repeat because the testing method itself has fundamental limitations.

1. Unable to Determine Release Impact Scope

SAP release notes span hundreds of pages but only list changes—they don't indicate actual impact on your company's system.

Example: Release note example: "SAP Note 12345: Pricing condition logic enhanced"

Hard to determine:

• Does our company use this pricing condition logic?

• If so, which transaction types are affected? (regular sales, special discounts, contract pricing)

• Matching hundreds of notes with thousands of transactions manually → practically impossible

You run full regression testing because you can't be certain of impact. The problem: spending time on unnecessary areas while missing critical ones, leading to business disruption after go-live.

2. Lack of GUI·Fiori·API Integrated Verification

Actual work uses GUI, Fiori, and APIs in combination—creating sales order drafts in Fiori, modifying complex pricing conditions in GUI, then transmitting to external systems via API.

Blind spots of separated testing:

Most testing verifies each separately. Field mismatches occur when transitioning from Fiori to GUI, and data that's normal in Fiori/GUI gets rejected during API calls due to validation failures.

• GUI only: VA01 transaction works normally

• Fiori only: Sales order Fiori app works normally

Errors at interface transition points go undiscovered until after go-live without integrated scenario verification.

3. Missing Boundary Value and Exception Case Verification

Release change errors occur more frequently in boundary values or exception cases than normal cases.

Boundary values and exception cases:

• Boundary values like quantity 0 or 999,999

• Exception cases combining special discounts, multiple currencies, and tax exemptions

Testing all boundary values and exception cases manually is impossible. Verifying only normal cases before go-live means validation logic change errors explode when exceptions occur in actual operations.

How can these problems be solved? Let's introduce three core strategies optimized for S/4HANA upgrades.

Effective S/4HANA Upgrade Testing Strategies

Overcoming traditional testing limitations requires fundamentally different approaches. These three strategies are optimized for quarterly recurring upgrades.

Strategy 1: Release Comparison-Based Impact Analysis

The first strategy is precisely identifying "what changed."

How automated impact analysis works:

Automatically compare previous and new releases. For example, when detecting "CDS View name changed from I_SalesOrder to I_SalesOrderTP" in SAP release notes, automatically scan all custom reports in your company.

Identify 20 reports using this CDS View. Then analyze usage frequency of each report to automatically classify impact.

• Critical: Daily essential reports

• High: Weekly important reports

• Medium: Monthly reports

• Low: Quarterly/annual reports

Expected effects:

• Selective testing of only affected areas reduces unnecessary regression testing

• Eliminates manual matching errors and automatically tracks all related functions

• Reusable for next quarter with same process

Real case: Even if there are 20 CDS View changes in this release, only 3 are actually used by us. Excluding the remaining 17 from testing saves 85% time.

Strategy 2: Automated Selective Regression Pack Generation

The second strategy uses Strategy 1's impact analysis results to automatically create test packs.

Automated generation process:

Select only affected modules based on release impact analysis results. If 5 transactions in SD module are affected but MM module has no impact, exclude MM testing.

Automatically organize test sequence by priority:

• Critical → Execute immediately

• High → Execute first priority

• Medium/Low → Execute sequentially

Selective regression focuses on actually affected core areas, drastically reducing time and cost while catching all critical errors.

Strategy 3: Fiori + GUI Integrated Scenario Execution

The third strategy verifies exactly as users actually work.

Integrated scenario examples:

Testing each interface separately shows normal results, but data mismatch errors occur in actual workflows connecting Fiori → GUI → API. Integrated scenario verification catches problems at interface transition points beforehand.

[Sales Process]

Create sales order draft in Fiori app → Modify pricing conditions in GUI VA02 → Process shipment in Fiori app → Issue invoice in GUI VF01 → Transmit to external accounting system via API

[Purchasing Process]

Create purchase request in Fiori app → Create purchase order in GUI ME21N → Confirm receipt in Fiori app → Transmit to supplier portal via API

Since behavioral differences between Fiori and GUI cause problems most frequently during release changes, integrated scenario verification is essential.

These three strategies minimize S/4HANA Upgrade risks and maximize efficiency of quarterly recurring work.

Conclusion

S/4HANA upgrades repeat quarterly, but you can execute them stably with systematic strategies.

Keys to successful upgrades:

✅ Release Impact Analysis Automation

Identify only affected areas, not everything—reduce testing time and cut costs

✅ Selective Regression Execution

Priority-based verification focuses on core areas, maximizing efficiency

✅ Fiori + GUI + API Integrated Verification

Test exactly as business flows, catching interface transition point errors beforehand

These three strategies establish systematic verification frameworks that minimize S/4HANA Upgrade risks and maximize quarterly recurring work efficiency. We hope you achieve stable and efficient upgrades through systematic preparation and automated verification.