Data Refresh Operator
Releases, projects and support need up-to-date, production-like test data. There are three ways to get there – with very different consequences for runtime, memory and data protection.
The client copy tools in the SAP standard copy a client locally, remotely or by export and import. Copy profiles define which data types are included – such as customising, user master records or application data. They have no concept of a time frame: application data always comes with its complete history.
In a homogeneous system copy, the production database is transferred to the target system as a whole, usually via backup and restore. This is fast for large volumes but turns the target system into a complete replica: the same size, the same development status, plus extensive post-processing of connections, users and jobs.
The Data Refresh Operator copies business objects from a selected time frame and automatically adds all dependent objects – including those from earlier years – until nothing is verifiably missing any more. The target client remains fully usable for business processes but is only as large as it needs to be.
| Criterion | Standard client copy | System copy | Data Refresh Operator |
|---|---|---|---|
| What is copied? | All client-dependent data according to the copy profile – with the complete history | The entire database: all clients, the repository and cross-client data | A time slice plus all dependent objects up to the fixpoint |
| Memory requirement in the target | Close to production sizing | Identical to production | Can be sized according to purpose |
| Control by business criteria | Copy profiles select data types, but not a time frame | None – all or nothing | Time frame, run profiles and exception lists per run |
| Impact on the target system | The target client is overwritten | The entire target system is overwritten, including the development status | The target client is filled; system roles prevent imports into production |
| Masking | Via separate tools | Via separate tools | Integrated and maintained centrally |
| Termination | Often an expensive restart | Depends on the method | Pause & resume at the level of atomic work packages |
| Traceability | Technical logs | Technical logs | Simulation beforehand, manifest and audit trail |
| Logical system names | Afterwards via BDLS | Afterwards via BDLS, across the entire database | Replaced during the import – no BDLS run |
| Surrounding process | Manual or by script | Manual or by script, with extensive post-processing | Automated as a playbook: announcement, ramp-down, import, follow-up tasks, ramp-up |
System copy remains useful when a target system really needs the full data volume, for example for load and performance tests before a major go-live.
The standard client copy is sufficient when only customising or user master records are transferred or the data volume is small.
Time slices with DRO play to their strengths when large S/4HANA landscapes regularly need fresh, production-like test data – for projects, releases and support – and HANA memory in QA, test and sandbox becomes a noticeable cost.
Many test data management tools have grown over the years and have their origins in SAP ECC. They have been developed further for new SAP generations – with the compromises that backward compatibility brings.
DRO has been developed from the ground up for S/4HANA. Data model, processing, parallelisation and performance are consistently aligned with S/4HANA and the capabilities of SAP HANA. Behind it lie many years of practical experience with client copies and test data management – rethought, without legacy baggage.
Existing tools for system copies are not affected: for client copies, DRO is intended as a replacement.
Implementing and operating DRO
SAP system copy: methods, procedure and post-processing
Test data for S/4HANA: the options compared
BDLS after a system or client copy
Client copy: transactions, copy profiles and follow-up tasks
In a free demo, we show you DRO live using your own use cases – remotely and with no obligation. We discuss where the benefits lie for memory, refresh time and operating costs, and how you can try DRO in your own landscape.
