TL;DR
- SAP Activate is the standard delivery framework for S/4HANA, but test data rarely gets planned as a formal deliverable within it
- Each Activate phase has specific test data requirements that most programs don't account for until they're already behind
- Test data strategy needs to start in Prepare, not when testing begins in Realize
- Treating test data as a versioned, governed program deliverable prevents the most common causes of testing delays and go-live risk
- Synthesized provides the platform to make this practical at every phase of an Activate project
SAP Activate is a well-structured framework. Six phases: Discover, Prepare, Explore, Realize, Deploy, Run. Each with defined deliverables, quality gates, and guidance on what needs to happen before the project moves forward. For most work in an S/4HANA program, Activate provides teams with a clear path.
Test data is the exception. It gets mentioned in the context of data migration, and it appears implicitly in the testing activities of the Realize phase. But as a standalone discipline — with its own strategy, governance, and provisioning approach — it rarely gets the attention it needs until the program is already feeling the consequences.
That tends to show up in predictable ways. Environments are not ready when Realize testing needs to start. Regression cycles are running on data that doesn't reflect the current configuration. Cutover rehearsals in Deploy are built on datasets nobody fully trusts. These aren't random failures. They're the result of treating test data as something the QA team will sort out rather than something the program owns from the beginning.
What test data planning looks like at each Activate phase
The good news is that SAP Activate gives programs a natural structure for when test data decisions need to be made. The phases themselves create the right moments, if the program is looking for them.
1. Discover and Prepare
Earlier than most programs start thinking about test data, but where the most important decisions get made. In Discover, the program is scoping business processes and identifying high-risk areas. That scope also serves as the test data scope. Order-to-Cash, Procure-to-Pay, Record-to-Report: the processes being prioritized for testing are the same ones that need production-realistic, consistent data to test against. Identifying that data dependency early sets the program up to plan provisioning rather than scrambling for it later.
In Prepare, the program is establishing governance, tooling, and team structure. Test data governance belongs here. Who owns provisioning? What compliance requirements apply? What generation methods will be used for which scenarios? These decisions become the foundation for everything that follows.
2. Explore
This is where fit-to-standard workshops define how business processes will work in S/4HANA. It's also where test data requirements become concrete. If Order-to-Cash is being redesigned to use S/4HANA's simplified data model, the test data used to validate it needs to reflect that design—not the ECC structure it's replacing. Aligning test data design with the process decisions made in Explore prevents mismatches that surface when Realize testing begins.
3. Realize
Where most programs feel the test data problem most acutely, because it's where testing actually runs. Implementation tests in Realize include unit testing of individual process components, string testing of linked transaction sequences, and user acceptance testing conducted by business experts. Each requires different data. Unit tests need targeted, scenario-specific records. String tests need data that holds together across the full process chain: a purchase order connecting correctly to a goods receipt, invoice, and payment run. UAT needs data that is realistic enough for business experts to genuinely validate the process rather than work around its limitations.
The programs that navigate Realize well arrive with a catalog of reusable test data sets already defined — versioned, scenario-specific, compliant by design, and available on demand rather than requiring days of preparation before each cycle starts.
4. Deploy
Where cutover rehearsals run and where test data quality has the most direct impact on go-live confidence. A rehearsal running on data that was accurate three weeks ago but doesn't reflect the latest configuration changes produces results nobody fully trusts. The decision to go live becomes harder to make, and risk gets pushed into hypercare rather than resolved in testing.
5. Run
Often treated as post-project, but for programs with ongoing release cadences — particularly S/4HANA Cloud's quarterly schedule — continuous test data availability becomes a standing requirement rather than a project deliverable. The capability built during implementation needs to serve the ongoing program, not just the go-live.
Making test data a program deliverable
The shift most programs need to make is to treat test data like any other program workstream. It needs an owner, a plan aligned to the Activate phases, and governance that defines compliance requirements, generation methods, and provisioning standards.
What that looks like in practice: reusable test data sets designed for each priority business process, compliant by default, provisioned on demand. Copy and refresh where production data is the right starting point. Masking and scrambling are used to protect sensitive data. Subsetting and time slicing are where right-sized, process-aware environments are needed. Synthetic generation where production data isn't available or permitted. The method depends on the scenario. The principle is the same: test data is ready when testing needs it, not when the preparation process finishes.
Synthesized's AI-native test data management platform is built to support this model across every phase of an Activate project. On-demand provisioning of production-realistic, compliant SAP test data, covering every generation method, across SAP and non-SAP systems, with storage footprints up to 99% smaller than full copy approaches. Organizations using Synthesized report delivery cycles running up to 70% faster, with test environments that keep pace with the program rather than holding it back.
Test data strategy isn't a QA concern to be resolved when Realize starts. It's a program decision that belongs in the Prepare section. The programs that make it there tend to find the rest of Activate considerably smoother.
Want to see what test data provisioning looks like across an Activate project? Book a demo and find out how Synthesized helps S/4HANA program teams get the right data at every phase, without the manual overhead.