Steering committees interrogate timelines, budgets, and org-readiness for months. Almost nobody interrogates whether the mock cutover is testing anything real — and that gap is what actually delays go-live.
Every S/4HANAEprogram has a cutover plan with a runbook, a war room, and a hypercare schedule. Almost none has a test-data budget line that survives first contact with the steering committee. That isn’t an oversight so much as a structural blind spot: test data gets treated as housekeeping owned by Basis, when it is the single variable that decides whether your mock cutovers tell you the truth.
The tool you assumed would carry you forward doesn’t exist anymore
Teams migrating from ECC routinely plan to reuse SAP’s Test Data Migration Server (TDMS) — the tool many used for a decade of test-system provisioning. It won’t carry the S/4HANA program. SAP’s own guidance is explicit that TDMS is not functionally released or approved for S/4HANA, with no roadmap to bring it to on-premise S/4HANA; at best it is technically usable in narrow project scenarios with no standard support. Practically, the toolchain your Basis team used for every prior upgrade cannot be assumed. You have to redesign non-production provisioning — system copies with anonymization, a subsetting platform (SAP Data Sync Manager or a third-party TDM tool), or SAP’s depersonalization services — rather than budgeting on “we’ll TDMS it like last time.” Discovering this in week three of build, instead of at blueprint, is a self-inflicted schedule risk.
One mock cutover proves nothing; volume is the variable that bites
The instinct to run a single mock cutover against a “representative” subset is understandable — it’s cheaper and faster to build. It is also why cutover weekends blow their downtime windows. Runtime and performance defects in data loads, nackground jobs, and interface throughput are volume-dependent: they don’t appear at 10% or even 60% of production mass; they appear at 100%, where table scans, index rebuilds, and batch contention behave nonlinearly. SAP’s own migration-cockpit performance guidance recommends running a mock load in a production-like environment precisely because sandbox and QA systems lack production-grade compute and storage, making runtime estimates from smaller cycles unreliable. The standard IOTEK enforces on GCC and North American programs alike is a minimum of two full mock cutovers against a 100%-volume mirror: the first to surface defects, the second to prove the fixes hold at scale. A single mock — or a mock built on a sample — rehearses a cutover that doesn’t exist.
PII in a sandbox is not a lesser problem — it’s the same problem
CIOs sometimes treat non-production data protection as a nice-to-have because “it’s not production.” Regulators don’t draw that line. A QA or sandbox system holding a full or partial copy of customer, vendor, employee, or HR master data carries the same personal-data exposure, and the same fine calculus, as production — under GDPR (Article 25’s “privacy by design” applies the moment personal data lands in a lower environment; there is no test-system carve-out) and under GCC frameworks like Saudi Arabia’s PDPL, which provides administrative fines up to SAR 5,000,000 (~USD 1.3M) per breach, doubled for repeat offences, alongside a separate criminal penalty of up to two years’ imprisonment and up to SAR 3,000,000 for unlawfully disclosing sensitive data. This is not theoretical: Saudi’s regulator (SDAIA) issued 48 enforcement decisions in the past year. Masking and anonymization are therefore a mandatory pre-condition for standing up any non-production environment on a GCC- or EU-touching program — not a task slotted in “if there’s time” before go-live.
Naive masking creates a different failure: it breaks the data it was meant to protect
The harder problem is that masking without architectural discipline yields a system that is compliant but useless. S/4HANA’s data model is tightly coupled — business-partner records, open items, and financial documents reference each other across standard tables, custom Z-tables, and business-logic dependencies a field-by-field scrambler never sees. Mask a customer ID in one table without propagating the identical transformation everywhere it appears as a foreign key, and you get orphaned records, broken customer–vendor links, and open items that no longer reconcile — the exact referential-integrity failures that make testers raise false defects, or miss real ones because the masked data behaves nothing like production. The fix is deterministic, entity-aware masking with consistent key mapping and dependency-aware scope, validated with orphan-detection and uniqueness checks before the data ever reaches a test team — not a one-off scramble script run the weekend before UAT.
Data goes stale faster than programs admit
Even a well-masked, full-volume, referentially intact test system decays. Test data more than three to six months old starts producing results that no longer reflect current master data, open-item aging, or org-structure changes; teams tracking SAP refresh cycles find test quality reliably degrades past that window, and shops on annual refresh cycles spend most of the year testing against data that is already stale by that standard. On a 12–18 month S/4HANAEprogram, that means two, often three, full refresh-and-remask cycles belong in the plan — not one “golden copy” cut at kickoff and never touched.
| Assumption teams make | What actually happens |
|---|---|
| “We’ll reuse TDMS from the last upgrade” | Not approved for S/4HANA; the toolchain must be redesigned |
| “A representative sample is good enough for the mock cutover” | Volume-dependent runtime defects only surface at 100% scale |
| “It’s just a sandbox, PII rules are relaxed” | GDPR/PDPL exposure is identical to production |
| “Masking is a quick scramble script” | It breaks referential integrity across Z-tables and business logic |
| “One data load at kickoff covers the whole program” | Test quality degrades materially past 3–6 months |
The real reason cutover dates slip
None of these failures show up in a steering-committee deck until the mock cutover itself blows its downtime window — or worse, until go-live weekend. That’s the core dysfunction: the mock cutover was meant to de-risk the real one, but run against small, stale, unmasked, or badly masked data, it doesn’t surface risk — it hides it. The program looks green through UAT and then breaks in production, where the volume, the aged data, and the real interdependencies finally show up for the first time. Cutover dates don’t slip in the boardroom. They slip in the sandbox, three weeks before go-live, when someone finally runs the load at full scale.
The practitioner takeaway
Budget test-data engineering as its own workstream from blueprint — not a Basis line folded into infrastructure. Sequence it: confirm your TDMS replacement before design closes; provision a full 100%-volume, entity-aware masked mirror before integration testing begins (not before cutover rehearsal); run at least two full mock cutovers against that mirror, spaced far enough apart to fix and re-test what the first one breaks; and lock a refresh cadence of no more than every 3–6 months for the life of the program, with re-masking and re-validation built into each refresh. A mock cutover that hasn’t rehearsed against real volume, real referential complexity, and reasonably current data isn’t a rehearsal — it’s a false signal that will cost you far more on go-live weekend than the test-data budget you skipped would have cost upfront.
### Sources – EPI-USE Labs — Creating SAP test systems: an alternative to SAP TDMS (TDMS not approved for S/4HANA): https://www.epiuselabs.com/sap-landscape-optimization-blog/creating-sap-test-systems-an-alternative-to-sap-tdms – SAP Community — Improve data transfer performance of the SAP S/4HANA Migration Cockpit (production-like mock load): https://community.sap.com/t5/technology-blog-posts-by-members/improve-data-transfer-performance-of-quot-sap-s-4hana-migration-cockpit/ba-p/13549125 – EPI-USE Labs — How to anonymise PII in non-production SAP S/4HANA systems and comply with GDPR: https://www.epiuselabs.com/data-security/how-to-anonymise-pii-in-non-production-sap-s/4hana-systems-and-comply-with-gdpr – Gigantics — Referential integrity in data masking: https://www.gigantics.io/en/blog/referential-integrity-data-masking – Automators.ai — SAP Test Data Refresh: 3 big pains and what fixes them: https://automators.ai/blog/sap-test-data-refresh-challenges-explained – A&O Shearman — Enforcement of the Saudi Personal Data Protection Law (PDPL) (SAR 5M / SAR 3M penalties): https://www.aoshearman.com/en/insights/enforcement-of-the-saudi-personal-data-protection-law – Global Privacy & Security Compliance Blog — Active Enforcement of Saudi Arabia’s Privacy Regime (SDAIA 48 decisions): https://www.globalprivacyblog.com/2026/05/active-enforcement-of-saudi-arabia-privacy-regime-implications-for-businesses/