A system refresh in SAP is the process of copying data, most often from Production, into a QA or test system so that testing happens against realistic, current data. Manually, it’s one of the most time-consuming recurring tasks a Basis team owns. Before automating the process, Avantra customer Scotts Miracle-Gro’s system refresh took four days and involved five staff members; the same task now completes in about four hours.That gap between what a refresh could take and what it typically does take is the subject of this guide.
System Refresh vs. System Copy vs. Clone
These three terms get used interchangeably, which causes real confusion for teams new to SAP Basis work, so it’s worth separating them precisely.
- A system copy is the general SAP term for duplicating an entire system. Homogeneous copies keep the same operating system and database; heterogeneous copies change one or both.
- A system refresh is a specific, recurring type of system copy: copying current data from a source system, usually Production, into an existing target system, usually QA or test, on an ongoing cycle, typically preserving target-specific configuration like RFC destinations and background jobs rather than overwriting everything.
- A clone creates a new, separate system as a copy of an existing one, most often used to spin up a sandbox or training system rather than refresh an existing test environment.
The practical distinction that matters most: a refresh updates an existing system’s data on a schedule, while a copy or clone typically happens once, to create a new environment.
| System refresh | System copy | Clone | |
| Frequency | Recurring, scheduled | Typically one-time | Typically one-time |
| Target system | Existing (e.g. QA) | New or existing | New system |
| Preserves target config | Yes (RFCs, jobs, users restored) | Not by default | Not applicable |
When and Why to Refresh
Most organizations refresh QA on a quarterly or pre-release cadence. Test systems get stale between refreshes: master data drifts from what’s actually in Production, user accounts accumulate that no longer reflect the current org chart, and transactional data ages until it no longer represents real business conditions. Three needs drive the standard cadence: keeping test data current enough to catch real issues, rehearsing an upcoming upgrade against production-like data, and satisfying audit requirements that testing reflects current business reality.
The right cadence depends on how fast the underlying data changes and how much testing rides on it. Organizations with frequent release cycles, monthly patches, ongoing custom development, or an active S/4HANA migration project often refresh QA monthly rather than quarterly, since stale data undermines every test cycle in between. Sandbox and training systems, by contrast, are typically refreshed far less often, sometimes only around major version upgrades, since their purpose is demonstration and learning rather than pre-production validation.
Pre-Refresh Checklist
Before starting a refresh, confirm the following are handled, since missing any one of these is the most common cause of a refresh running long or requiring rework:
- User exports and role assignments captured from the target system, so they can be restored after the refresh overwrites them. Skip this and testers lose access Monday morning, with the Basis team fielding access tickets instead of running the next refresh.
- RFC destination inventory documented, since these typically need repointing after the copy. Skip this and a test system can end up calling production endpoints, sending real emails, EDI transactions, or interface calls out of an environment nobody expects to be live.
- Transport log compared between source and target before the refresh starts, since the target’s transport history gets overwritten along with everything else. Skip this and any change transported into the target but not yet into the source, custom code or configuration still mid-testing, disappears without a trace, and nobody finds out until someone goes looking for work that should still be there.
- License and system measurement data backed up. A refresh that changes the underlying hardware key can leave the target system unable to start until a new license is applied.
- Spool requests and print configuration noted if they need to be preserved, since a refresh commonly wipes queued spool jobs and print device assignments along with everything else.
- Variants and background job definitions exported for restoration. Refresh tools typically deactivate jobs by design so a freshly copied system doesn’t start firing production-scheduled jobs on its own, but that means every job needs a deliberate decision to reactivate rather than assuming it will resume automatically.
The Refresh, Phase by Phase
Phase 1: Export and backup
The refresh begins with a backup and restore approach on the source system side, most commonly a database-level backup or storage snapshot of Production that can be restored onto the target system’s database server. The backup needs to be taken at a consistent point, which usually means coordinating with the existing production backup window rather than pulling an ad hoc copy mid-day, since restoring from an inconsistent state is one of the more common causes of a refresh needing to be rerun.
Phase 2: Restore and rename
Once the backup is restored onto the target, the system needs a logical rename so it doesn’t think it’s Production. SAP’s BDLS (Business Data Logical System) conversion updates the logical system names embedded throughout the database, which is one of the more error-prone manual steps in the entire process for two reasons: it typically needs to run in a restricted, single-user mode before anyone logs in, and on a large system it can take hours to complete across every affected table.
It’s also easy to miss custom Z-tables that store a hardcoded logical system reference outside the standard tables BDLS knows to update, which is a common source of the interface issues that show up days later rather than immediately.
Phase 3: Post-processing
This is where the pre-refresh checklist gets restored, and it’s more involved than a single step: users and roles go back in, RFC destinations get repointed away from production endpoints, any transports identified as in-flight but not yet in the source system are re-imported so that work doesn’t quietly disappear, background jobs are deliberately reviewed and reactivated one by one rather than en masse, the STMS transport domain configuration is checked to confirm the refreshed system can’t accidentally import into or export toward Production, output and spool device assignments are reset for the target environment, and number range buffers are reset so the test system doesn’t collide with production document numbers. Validation testing follows, confirming the refreshed system actually works end to end rather than just that the restore completed successfully.
Common Refresh Failures and How to Avoid Them
A handful of failure modes account for most refreshes that go wrong, and all of them trace back to a step in post-processing being skipped or done out of order:
- Interfaces firing against production endpoints. If RFC destinations aren’t repointed before background jobs are reactivated, a refreshed test system can send real transactions, emails, or EDI messages out of an environment everyone assumes is isolated.
- Duplicate or conflicting document numbers. Skipping the number range buffer reset means the test system can generate document numbers that later collide with production once any integration between the two exists.
- Interfaces that appear to work, then fail days later. This is the classic symptom of a missed custom table with a hardcoded logical system reference that BDLS didn’t touch; the failure doesn’t show up until that specific code path runs.
- The system won’t start after the refresh. Usually a license key mismatch after a hardware key change, which is why backing up license and system measurement data before starting the refresh matters even though it’s easy to skip.
- Authorizations look wrong for test users. Often not a permissions bug but a restoration-order issue: the user master was restored before the role assignments were reapplied, or vice versa.
How Long Does a Refresh Take?
A manual refresh typically takes multiple full days of a Basis team’s time; an automated one typically takes hours. Manual effort scales with system size and complexity, but even a straightforward refresh commonly consumes multiple full days once backup, restore, BDLS conversion, and full post-processing are all counted.
Avantra states that Enterprise Edition customers see system refresh timelines drop from weeks to days once automated, and in Scotts Miracle-Gro’s case specifically, the production-to-QA refresh dropped from four days to four hours, while the separate QA test-environment refresh dropped from three days to four hours. The same team is now able to refresh up to five SAP systems simultaneously, managed by a single engineer.
| Manual | Automated (cited customer example) | |
| Refresh duration | Multiple days | Hours |
| Staff required | Multiple engineers | One engineer, multiple systems in parallel |
| Post-processing | Manual, error-prone | Automated (BDLS, RFC repointing, job restoration) |
Automating the Refresh
Avantra’s system refresh automation handles the pre- and post-refresh activities directly, including authorization restoration, integration repointing, and the BDLS system rename. Avantra’s CTO has described the shift plainly: refreshes that used to take four days of manual work now complete in a few hours, with support extending across HANA, Oracle, and Sybase databases.[4] The goal isn’t just speed. Automating a refresh also means it runs the same documented way every time, which is what actually satisfies auditors asking how test data currency is maintained.
This piece covers how refreshes work and what automating one looks like. It intentionally doesn’t duplicate the product page’s mechanics; for the specific setup steps, that’s the right next stop.
FAQ
What is a system refresh in SAP Basis?
A system refresh is the process of copying current data, typically from Production, into an existing QA or test system, so testing happens against realistic, up-to-date data rather than stale test data.
How often should you refresh QA?
Most organizations refresh QA on a quarterly cadence at minimum, with additional refreshes ahead of major releases or upgrades to ensure testing happens against production-representative data.
Does a refresh delete users?
A refresh overwrites the target system’s data with the source system’s data, which includes user records, so target-specific users and roles need to be exported before the refresh and restored afterward as part of post-processing.
Can a refresh be fully automated?
Yes. Automation platforms can handle the backup, restore, BDLS rename, and post-processing steps end to end, reducing a multi-day manual process to a matter of hours with minimal human intervention.
Conclusion
A system refresh moves through three phases: export and backup, restore and rename, and post-processing, and it’s one of the most automatable recurring tasks in SAP Basis work because every phase follows the same documented steps every time.
To see what full automation looks like in practice, from a Basis engineer’s own perspective, read “Hey Avantra, refresh my QA systems”, or browse our full system refresh content hub. To see automated SAP system refresh in action, book a demo.