SAP system refresh: runbook for the QA refresh

SAP system refresh: what it involves

In a refresh, an existing target system is overwritten with current data from a source system, usually QA from production. Unlike when a new system is set up, the target is meant to keep its configuration. The system ID, connections, users, transport routes and printers remain those of the QA system.

There are two technical approaches. The SAP system copy replaces the entire database, including the repository and all clients. The client copy only replaces one client. The variants available for this are shown in the basics article in the section Local, remote or by export. The organisational framework is the same for both and follows seven phases:

Planning and coordination. Clarify the date, downtime window, affected tests and transports; announce the refresh.
Ramp-down. Bring the QA system to a standstill: lock users, stop jobs and interfaces.
Backups. Back up everything that makes the system a QA system: users, transport buffer, connections, settings.
Copy. Transfer the database or client from production.
Post-processing. Separate the system from production and restore the QA settings.
Ramp-up. Check, switch on interfaces and jobs, unlock users.
Release and documentation. Acceptance by the business departments; record runtimes and deviations.

From ramp-down to ramp-up, the QA system is not available to testers. The shorter the copy and post-processing, the shorter the downtime window.

Phase 1: planning and coordination

A refresh takes the test system away from the business departments for hours or days. Ongoing tests lose their data. So agree on the date early and clarify these points:

Business departments and projects: Which tests are currently running, which test data has to be created again afterwards, and who tests after the release?
Development status: Identify transport requests that have been imported into QA but are not yet in production. After a system copy, they are missing from the repository; after a client copy, their client-specific Customizing is missing. In both cases, they have to be imported again afterwards.
Downtime window: Derive the duration from the last refresh or from a test run, as SAP recommends for system copies, and plan a buffer for post-processing. Coordinate copies with production data with month-end and year-end closing.
Connected systems: Clarify which test and partner systems are connected to the QA system and who stops them during the refresh and reconnects them afterwards.
Communication: Announce the date, duration and contact persons by email. Shortly before the start, create a system message in SM02.

Phases 2 and 3: ramp-down and backups

At the start of the downtime window, the QA system is brought to a standstill. Logged-on users are informed and logged off, and dialog users are locked with SU10, except for the Basis team. You check running jobs in SM37. Interfaces to partner systems are interrupted, for example IDoc processing and the qRFC and tRFC queues.

Production keeps running during a refresh. However, its jobs come into the QA system with the copy and must not start there. A common approach is to start the target system after the copy without background processes at first (profile parameter rdisp/wp_no_btc set to 0) and to suspend the jobs there with report BTCTRNS1. Open update requests in SM13 should ideally have been processed in the source at the time of the backup.

Before the QA system is overwritten, back up everything that makes it a QA system. SAP describes the principle in ABAP Post-Copy Automation, part of SAP Landscape Management: before the copy, the task list SAP_BASIS_COPY_REFRESH_EXPORT exports configuration tables of the target system to the file system using R3trans. After the copy, tables containing data from the source are cleaned up and the configuration is imported again. Report SCTC_LIST_TABLES shows which tables are exported. With or without a task list, these backups are part of every refresh:

Users and authorisations: for example via a client export with copy profile SAP_USER (SCC8).
Transport management: Back up the import buffer of the QA system in the transport directory and store the list of requests to be re-imported.
System-specific settings: Export or document logical system names (SCC4), RFC destinations (SM59), partner profiles (WE20), printers (SPAD), licence keys (SLICENSE), certificates (STRUST) and logon groups (SMLG).
Fallback: A backup of the QA system in case the refresh has to be aborted.

Phases 4 and 5: copy and post-processing

For a refresh by system copy, you restore a backup of production in the QA system. With SAP HANA, the SWPM option ‘Refresh Database Content’ replaces only the database content of an existing system; the instances are not reinstalled. For this, the application servers of the target are stopped while the ASCS instance keeps running. Methods and procedure are described in the article SAP system copy.

For a refresh by client copy, you copy the production client remotely with SCC9 or SCC9N. The repository and development status are retained. According to SAP's system copy guide, client transport with SCC8 and SCC7 is not intended for production clients but for the initial setup of a system landscape.

Post-processing follows. First comes everything that separates the system from production, then the restoration of the QA settings:

Separate. Initially open the system only for the Basis team. Check RFC destinations and queues, and block output via printers, email and EDI.
Licence and transport management. Install the QA licence key. After a system copy, run the post-installation processing for a database copy in SE06 and set up transport management in STMS again.
Logical systems. Use BDLS to convert the names from the name of production to that of the QA client. Why this takes time is explained in the article BDLS after a system or client copy.
Restore QA settings. Restore the backed-up users, RFC destinations, partner profiles, printers and certificates.
Jobs. Delete or adjust production jobs and release only the jobs needed in QA, after a system copy with BTCTRNS2.
Transports. Re-import the transport requests identified in phase 1.
Protect data. Mask personal data before testers and developers get access.

The complete lists can be found in the checklist for follow-up tasks after a client copy and in post-processing after the system copy.

Phases 6 and 7: ramp-up, release and documentation

Only when the system has been separated and set up does it go back to the users:

Check: Consistency check (SM28) and system log (SM21), logon with test users, spot checks in the most important processes.
Ramp-up: Switch on interfaces to the test partners, schedule jobs, unlock users with SU10, remove the system message.
Release: The business departments confirm that data and functions are suitable for their tests. Only then is the refresh complete.
Documentation: Record the runtimes of each phase, deviations and open issues, and update the runbook for the next refresh.

Checklist for the QA refresh

The phases in brief, to tick off:

Date agreed with business departments and projects, downtime window fixed
Transports identified that are in QA but not yet in production
Refresh announced by email and system message
Users locked, jobs and interfaces stopped
Users, transport buffer and QA settings backed up
Backup of the QA system available as a fallback
Copy completed, logs checked
RFC connections, output and jobs separated from production
Licence, transport management and logical system names adjusted
Users and QA settings restored
Open transports re-imported
Personal data masked
Checks successful, business departments have given their approval
Runtimes, deviations and open issues documented

Automating the SAP refresh as a playbook

The runbook is the same every time. Even so, many teams work through it manually, often at the weekend and with the risk of forgetting a step.

If your QA refresh runs as a client copy, the Data Refresh Operator can take over this procedure. DRO playbooks automate the announcement, wait for the downtime window and carry out the ramp-down: suspending jobs, locking users, interrupting interfaces, saving number range levels. This is followed by the backup of the user master records, the import, customer-specific post-processing and the ramp-up. DRO replaces logical system names during the import, before the data is written to the database. No subsequent BDLS run is needed.

A time slice is copied, for example the last 90 days, plus all dependent objects from earlier years. If a run is interrupted, DRO resumes at the level of atomic work packages, and every step is recorded in the audit trail.

3–5×: faster than a full copy, in practice
0: BDLS runs after the import

Value from practice, not a guarantee. Depending on the system, time frame and exclusions, considerably more is possible. DRO runs on SAP S/4HANA from release 2023.

DRO replaces the client copy, not the system copy. For a refresh by system copy, SWPM and the post-processing described above remain the tools. What an automated refresh looks like from Friday evening to handover is shown in the sample playbook.

SAP system refresh: a QA refresh runbook from ramp-down to release