Get the whitepaper!
The Test Data Imperative: Towards SAP Autonomous Enterprise

S/4HANA upgrades

Test data for SAP upgrade and regression testing

S/4HANA now gets a new release every two years, and each upgrade needs a regression cycle on data that behaves like production. Refresh QA with a masked, right-sized copy at the start of every cycle, without copying all of production again.

Book a health checkThe 10-day validation
Available on SAP Store
SAP S/4HANA
New release every two years
QA refreshed · masked
Every upgrade
Fresh QA data at the start of each regression cycle
  • Masked before testers see it
  • Same rules, every release
Built for the SAP & Enterprise QA toolchain
SAP S/4HANASAP AribaSAP HANASalesforceUiPathTricentis

Why now

Upgrades now come round every two years

2 years
Between S/4HANA releases, each with its own regression cycle
Dec 2025
S/4HANA 2020 left mainstream maintenance, so many teams are upgrading now
1 a year
How often RISE with SAP customers can request an upgrade

Check the dates for your release in SAP's maintenance strategy.

The upgrade cycle

Where test data slows an upgrade down

An upgrade is a project with a deadline, and data shows up as a blocker at four points.

01
Sandbox conversionRehearsing the upgrade usually starts from a full copy of production, personal data included.
02
Regression testingThousands of automated and manual tests need data that matches current configuration, with open items, credit limits and stock in the right state.
03
Fixes and retestsEvery defect fix needs data reset to a known state before the retest, or the retest fails for the wrong reason.
04
User acceptanceBusiness users test with data they recognise, which pushes teams back towards production copies.

Full copy or masked subset

What changes when QA is refreshed with a masked subset

Full system copy

The same project every cycle

  • Effort. Days of Basis work, every time
  • Size. The same as production
  • Personal data. Copied as is unless masked separately
  • Repeatability. A small project each cycle
  • Connected systems. Separate copies with values that don't match
With Synthesized

A masked subset, rerun each cycle

  • Effort. Hours once the rules exist
  • Size. Only the company codes and dates in scope
  • Personal data. Masked before testers see it
  • Repeatability. The same rules rerun for each cycle and each release
  • Connected systems. The same masked values in SAP and connected systems

Platform

Subset, mask and generate for each cycle

MaskSubsetGenerate

Find and mask personal data

A scan flags personal data in SAP tables and the systems around them, then masking replaces it with realistic values, the same way everywhere.

  • Sensitive columns found by the scan, including Z-tables
  • Same replacement values in SAP and the CRM
  • A record of every run
Automated masking with a sensitive data scan report

Copy only what your tests need

Choose company codes, date ranges or business objects, and the subset keeps every related record so tests still run end to end.

  • Business keys and date ranges in scope
  • Document chains kept whole
  • Smaller, faster test systems
Automated subsetting with system statistics

Create the data production doesn't have

Generate customers, orders and edge cases for scenarios production doesn't contain yet, configured as code or in the UI.

  • Edge cases on request
  • Configuration as YAML or in the UI
  • Runs from the API, CLI or a pipeline
Automated generation configured as YAML

How teams run it

Every cycle starts from fresh data

SAP productionReal data
SynthesizedSubset and mask in scope
QA systemFresh, masked data
Regression testsTosca, UiPath, manual
Tests pass?
Fix the defectThen reset the data
Go live
Next upgradeSame rules, new release
no
retest from a known state
yes
two years later
start from fresh data again
Each upgrade cycle starts from a masked subset, and every retest resets the data first.
  1. 01

    Set the rules once

    In the first cycle, define the scope (company codes, date range, business objects) and the masking rules, including your custom Z-tables.

  2. 02

    Refresh at the start of each cycle

    Run the refresh into QA as soon as the upgrade lands in the test system.

  3. 03

    Reset between retests

    Provision the data a test needs from Tricentis Tosca or UiPath, so each retest starts from a known state. See test automation.

  4. 04

    Reuse for the next release

    Two years later, the same rules refresh the system for the next upgrade.

We've got you covered

Questions about upgrade testing

Does this work with RISE with SAP?

RISE customers run S/4HANA Cloud Private Edition, which the SAP Store listing names among the supported products. Check what your RISE contract allows before the validation.

How is this different from a client copy?

A client copy moves everything in the client, personal data included, and takes the same time every cycle. A subset copies only what's in scope and masks it on the way.

We only upgrade every two years. Is it worth it?

The regression cycle repeats inside each upgrade, because every fix needs a retest from a known state. Teams that also refresh for feature packs, quarterly releases or projects get the most from it.

What test data does an S/4HANA upgrade need?

Data that matches the new release's configuration: open sales orders, deliveries and invoices, open items in finance, stock in the right plants, and master data such as customers and materials. A masked subset of production in scope supplies all of it.

How often can RISE with SAP customers upgrade?

RISE customers can request an upgrade every year, and on-premise releases come every two years. Each upgrade needs its own regression cycle. See test data for RISE with SAP.

Next step

Start your next upgrade cycle with fresh data

We refresh one QA client for your next regression cycle and compare it with your current refresh.

Runs in your environmentNothing installed in SAPRead-only access to SAPSecurity and deployment
Book a health checkFind us on SAP Store

Related SAP pages

ProjectTest data for S/4HANA migrationMigration test dataAutomationTest data for SAP test automationTosca and UiPathProjectSAP performance test data at production scalePerformance testingProjectClean core test data managementClean core
Updated October 2026

SAP, S/4HANA, SAP HANA, SuccessFactors, Ariba, Concur and other SAP products and services mentioned herein, as well as their respective logos, are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.