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
Test systems get stale. 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.
Organizations typically refresh QA on a quarterly or pre-release cadence, driven by three needs: 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.
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.
- RFC destination inventory documented, since these typically need repointing after the copy.
- License and system measurement data backed up.
- Spool requests and print configuration noted if they need to be preserved.
- Variants and background job definitions exported for restoration.
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 of Production that can be restored onto the target system’s database server.
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 data, one of the more error-prone manual steps in the entire process.
Phase 3: Post-processing
This is where the pre-refresh checklist gets restored: users, RFC destinations, background jobs, interfaces, and any target-specific configuration go back in, followed by validation testing to confirm the refreshed system actually works end to end.
How Long Does a Refresh Take?
Manual effort scales with system size and complexity, but even a straightforward refresh commonly consumes multiple full days of a Basis team’s time 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.
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.