SAP system refresh vs client refresh: when to use which

SAP system refresh vs client refresh: the terms

An SAP refresh overwrites an existing system or client with current data from a source, usually production. The target takes on the data of the source but remains a test system, with its own system ID, connections and users. How a refresh runs as a project is covered by the runbook for the QA refresh. This article deals with the question that comes first: which method?

In a system refresh, the target system is overwritten by a system copy. In S/4HANA landscapes, this is a homogeneous copy using SAP HANA backup and restore and the Software Provisioning Manager (SWPM). The entire database is always transferred: the repository with programs and Dictionary objects, cross-client data and all clients. According to SAP, individual components can be neither selected nor excluded.

In a client refresh, only one client is overwritten by a client copy: locally within the system, remotely via RFC or by export and import. The client-dependent data is transferred – depending on the copy profile, Customizing, application data and user master records. The repository, cross-client settings and the other clients of the target remain untouched. Cross-client Customizing can be included in a remote copy or client transport, but SAP intends this only for setting up a new system, as existing clients could otherwise be damaged. The transactions and profiles are explained in the basics article on SAP client copy.

System copy vs client copy compared

The table sets out both routes for refreshing a QA or test system from production:

Simplified comparison based on the SAP system copy guide for SWPM 2.0 and SAP Learning. The transactions ending in N are available from SAP_BASIS 7.54 (S/4HANA 1909).

A caveat on client transport. In its system copy guide, SAP states that client transport is not a system copy method and that transporting production clients is not supported. It is intended for the initial setup of a system landscape. For a client refresh from production, the remote copy with SCC9 or SCC9N is therefore the way to go, not SCC8 and SCC7.

Development status, downtime and post-processing

Development status and transports. The key difference lies in the repository. A QA system is usually ahead of production: it holds transports that have been tested but are not yet live. A system copy replaces the repository with that of production, so these transports are missing afterwards and have to be imported again before testing continues.

With a client copy, the target keeps its repository, but its client-dependent Customizing is overwritten. Customizing transports not yet in production therefore have to be re-imported here, too. The hurdle lies elsewhere: according to SAP, a remote copy requires identical table structures in both systems. If source and target are on different support package levels, not all tables will match. How SCC9N handles this is described in the article New client copy tools from S/4HANA 1909.

Other clients. A system copy brings exactly the clients of the source. Clients that existed only in the target, such as a training or project client in QA, are gone afterwards unless you back them up first, for example by client export. A client refresh leaves them alone.

Downtime. With a system refresh, the entire target system is unavailable, for all clients and users. The duration depends on the database size: backup, transfer, restore and then post-processing. SAP recommends determining the downtime with a test run. With a client refresh, the target client is locked, the source client optionally. The runtime grows with the volume of application data. SAP mentions several hours or even days and notes that data volume, memory requirements and copy time can be considerable for production clients. Where time can be saved is shown in Speeding up an SAP client copy.

Post-processing. After a system copy, the target carries the settings of production. The SAP guide lists a long series of steps, from a new licence key in SLICENSE, emptying tables TPFET and TPFHT and re-importing the profiles in RZ10 to RFC destinations, jobs, certificates and transport management in STMS. BDLS converts both client-dependent and client-independent tables. After a client copy, the system-wide settings stay as they were. What remains are the client-specific steps: converting logical system names with BDLS in the client-dependent tables only, restoring users and checking interfaces, jobs, output and number ranges. The complete lists are in the post-processing checklist for the system copy and the follow-up tasks after a client copy.

Space. For a system refresh, the target needs disk space and main memory for the complete database, roughly the sizing of production, plus space for the backup. For a client refresh, the size of the client counts. An additional local copy makes the database grow by the copied client. SCC_CLIENT_SIZE estimates the requirement in advance, though according to SAP only approximately. The standard client copy brings the complete history of the client, and in SAP HANA it sits in main memory.

Typical use cases

These differences translate into clear patterns:

• QA fully on production status: If QA is to be a complete image of production, with the repository and all clients, the system refresh is the right route. The transports not yet in production follow afterwards.
• Load and performance tests: Meaningful runtimes need realistic data volumes. This usually requires a system copy.
• Sandbox: A sandbox with the status of production, for upgrade rehearsals or for reproducing errors, is created by system copy. If an existing sandbox only needs fresh data, a client refresh is enough.
• QA with ongoing projects: A QA system with transports in the pipeline gets new data by remote client copy. Its development status is preserved.
• Training client: A template client holds stable sample data. Before each course, the training client is reset from it by local client copy.
• Several clients in one system: If test, training and project clients share a system, refresh each one separately. A system copy would replace them all at once.

How systems and clients are usually distributed across a landscape is described in SAP system landscape and client strategy.

Decision guide: seven questions before an SAP refresh

Before you refresh an SAP test system, these questions help you choose the method:

1. Do you need the development status of production in the target? If so, for a sandbox or performance tests for example, choose a system refresh. If the target is to keep its own status and transports, that points to a client refresh.
2. Are there clients in the target system that must keep their status? Then refresh individual clients selectively. A system copy replaces all of them.
3. Do the release and support package levels match? A remote copy needs identical table structures. If the target is ahead, say in the middle of an upgrade project, run the client copy in test mode first. A system copy would set the target back to the status of production.
4. Do the tests need the full data volume? Load and performance tests do, and the system copy suits them. Functional and integration tests need complete document chains, but rarely every year of history.
5. Who is affected by the downtime? With a system refresh, all users of the target system; with a client refresh, those of the target client. Base the estimate on the last run or a test run.
6. How much space and main memory does the target have? A system copy needs the sizing of production, a standard client copy the space of the client including its complete history.
7. How often should the system be refreshed? The more frequent the refresh, the more runtime and post-processing matter. That favours the smaller scope: a client rather than a system, a time frame rather than the full history.

If most answers point to a client refresh but runtime and space are the real problem, a third option is worth a look.

A third option: client copy by time slice

Between the two routes lies the time-slice client copy. Like a client copy, it overwrites only one client, but instead of the complete history it copies a time frame, for example the documents of the last 90 days. For the target client to work, every object these documents refer to has to come along: master data, preceding documents and open items, even if they are years older.

The gain lies in runtime and space. Less data means a shorter copy, less main memory in the target and less table content for BDLS to search. The limit: edge cases that exist only in older data are missing. For load and performance tests with the full data volume, the system copy remains the appropriate route.

The standard tools cannot do this, because copy profiles select data types, not time frames. It takes a tool that resolves the dependencies between objects. In ECC landscapes, SAP TDMS was often used for this. According to SAP Note 2696183, TDMS is not supported in the SAP S/4HANA context. More on partial copies can be found in Test data for S/4HANA.

Client refresh with the Data Refresh Operator

The Data Refresh Operator (DRO) implements this third option for SAP S/4HANA. It copies a time slice, for example the last 90 days, plus all dependent objects from earlier years. Dependencies are resolved across the object graph until the fixpoint – the verifiable point at which no new objects are added. No BDLS run after the import: DRO knows the fields that contain logical system names and replaces the values during the import, before they are written to the database. Playbooks automate the procedure around it: announcement, ramp-down, backup of user master records, import, customer-specific follow-up tasks and ramp-up.

3–5×

faster than a full copy, in practice

0

BDLS runs after the import

A practical value, not a guarantee: in practice, three to five times faster than a full copy – depending on the system, time frame and exclusions, considerably more is possible. DRO runs on SAP S/4HANA from release 2023.

For the decision above, this means: DRO replaces the client copy, not the system copy. Where you need a system refresh, such as for performance tests or a sandbox with the development status of production, SWPM remains the tool. How the standard client copy, the system copy and the time slice compare in detail is shown in the comparison of client copy, system copy and time slice. We are happy to discuss which route suits your landscape: Book a demo.

Sources

• SAP Help: System Copy for SAP ABAP Systems Based on UNIX: SAP HANA 2.0 Database, Using Software Provisioning Manager 2.0 (PDF)
• SAP Learning: Client Copy and Client Transport Tools
• SAP Help: Conversion of Logical Systems (SAP NetWeaver 7.0 EHP3)
• SAP Note 2696183: TDMS components when installing and upgrading S/4HANA 1809/1909 (SAP Support Portal, login required)