SAP client copy: step-by-step guide & profiles

What is a client copy?

An SAP system contains one or more clients – units that are separate in business terms, each with its own application data, its own Customizing and its own users. Programs and the Repository are shared by all clients of a system.

A client copy transfers the client-specific data of a source client to a target client – in the same system or in a different one. Typical occasions are the regular refresh of QA and test systems with production-like data, new training clients or a fresh sandbox for a project.

A system copy is something different: it transfers the entire database with all clients and the Repository. Which method fits when is shown in our comparison of system copy and client copy.

System copy

Overwrites the entire database

Client copy

Overwrites one client with its full history

Time-slice client copy

Overwrites one client with a time period, e.g. 90 days, plus dependent objects

A system copy replaces everything, a client copy one client with its entire history, a time slice only the period you need. Schematic diagram.

Performing an SAP client copy: step by step

The procedure is largely the same for local and remote copies. The following steps apply to the new tools from S/4HANA 1909 as well as to the classic transactions. Where they differ, this is noted.

Clarify scope and space. How large is the source client, and is there enough space in the target? From SAP_BASIS 7.54, SCC_CLIENT_SIZE estimates the size. The result is an approximation because HANA compression is not taken into account.
Create the target client. In SCC4, create the target client with its role and change options if it does not exist yet. The fields are explained in Creating an SAP client in SCC4.
Save what is there. When you refresh an existing client, its data is lost: with every profile except SAP_USER, the copy deletes Customizing and application data in the target. Save the users and system-specific settings of the target system beforehand.
Inform users and keep the system quiet. The target client is locked during the copy. According to SAP, no one should work in the source client either, as this can cause inconsistencies. A system message via SM02 announces the window.
Start the tool. SCCLN and SCC9N are started from an uninvolved client; SAP recommends client 000, for example. The classic transactions SCCL and SCC9 run in the target client. A new client only has the user SAP* for this, whose logon is controlled by the profile parameter login/no_automatic_user_sapstar.
Choose the source and the copy profile. The profile determines which types of data are transferred (see copy profiles). For a remote copy, you also choose the RFC connection to the source system.
Test run. Test mode shows in advance which tables are affected, with how much data, and where problems are likely. For a remote copy, it also reveals tables whose definitions differ between the systems.
Run it in the background. SAP recommends scheduling the copy as a background job so that it does not fail because of time limits for dialog processes. Parallel processes shorten the runtime; how many make sense is covered in Speeding up an SAP client copy.
Monitor in SCC3. SCC3 shows progress, table statistics and errors. How to read the logs is explained in SCC3 and common client copy errors.
Follow-up tasks. Only after the follow-up tasks is the target a test system again (checklist below).

The transactions at a glance

Transaction	Purpose	Used for
`SCC4`	Client administration	Create clients and define the role (e.g. test, production) and the change options. The target client must exist here before you copy.
`SCCL`	Local client copy	Copies a client within the same system, for example to set up a training or test client.
`SCC9`	Remote client copy	Copies a client from another system via an RFC connection, typically for refreshing QA from production.
`SCCLN, SCC9N`	New local and remote copy	From SAP_BASIS 7.54 (S/4HANA 1909): optimised for SAP HANA, started from an uninvolved client, with test mode and task list.
`SCC8`	Client export	Exports a client to transport files, which are then imported into the target system.
`SCC7`	Client import post-processing	Completes a client import after the export files have been imported into the target system.
`SCC1`	Copy by transport request	Transfers the content of individual transport requests between clients of the same system (new: SCC1N).
`SCC5`	Delete client	Removes a client together with its client-specific data.
`SCC3`	Log analysis	Shows the status and logs of the copy runs – the first port of call when a run hangs or terminates.
`SCC_CLIENT_SIZE`	Estimate size	From SAP_BASIS 7.54: estimates before the copy how large a client is and how much space the target needs.

Which transactions are available depends on the release level of your system. What the new tools do differently is described in The new client copy tools from S/4HANA 1909.

Local, remote or by export?

Situation	Method	Transactions
Source and target are in the same system	Local	SCCL or SCCLN
Target in a different system, RFC connection available, same release and support package level	Remote	SCC9 or SCC9N
No direct connection, or export and import are to run at different times	Export and import	SCC8, import, SCC7

Local (SCCL, SCCLN) is the simplest method, as long as source and target are in the same system.

Remote (SCC9, SCC9N) copies directly from another system via an RFC connection. Source and target should be on the same release and support package level so that the table structures match.

Export and import (SCC8, SCC7) decouple source and target: the export creates files that are imported into the target system and post-processed with SCC7. This makes sense if there is no direct connection or if the export is to run at a different time from the import. According to SAP's system copy guide, however, client transport is not intended for production clients but for the initial setup of a system landscape. More on this in SAP system refresh vs client refresh.

Copy profiles: what is included

Copy profiles determine which types of data are transferred. One point first: with every profile except SAP_USER, Customizing and application data in the target client are deleted before copying. According to SAP, this is technically unavoidable. The general profiles at a glance:

SAP_ALL: All client data except change documents and local data: Customizing, application data and user master records.
SAP_APPL: Like SAP_ALL, but without user master records.
SAP_APX: Like SAP_ALL, but without authorisation profiles and roles.
SAP_CUST: Client-specific Customizing including authorisation profiles. Application data in the target is deleted; the target’s user master records are kept.
SAP_CUSV: Like SAP_CUST, plus variants.
SAP_UCUS: Like SAP_CUST, plus user master records.
SAP_UCSV: Like SAP_UCUS, plus variants.
SAP_USER: Users, roles and authorisation profiles. The only profile that does not reset the target client.
SAP_UONL: Users without authorisation profiles and roles.
SAP_PROF: Authorisation profiles and roles only.

For export and remote copy, there are additional profiles that include cross-client Customizing (SAP_EXPA, SAP_EXPC, SAP_EXBC and SAP_RMPA, SAP_RMPC, SAP_RMBC). The special profile SAP_RECO is only intended for restoring a client that was deleted by mistake.

Which profile for what? For a new Customizing or training client, SAP_CUST or SAP_UCUS is often enough. For a QA refresh with application data, SAP_ALL or SAP_APPL are the candidates. What matters is what profiles cannot do: they select types of data, but not a time period. If you copy application data, you always get the complete history – even if only the last few months are needed for testing.

Runtime and space requirements of a client copy

The runtime grows with the data volume of the client – and therefore with every year of history. In large S/4HANA systems, full copies often tie up systems, the Basis team and business departments for days. Parallel processes shorten the runtime, but they do not change the fact that the entire history is moved. For planning: the entire runtime is downtime for the target client, and no one should work in the source client in the meantime.

Then there is memory: in SAP HANA, the copied history resides in main memory. As a result, every full copy in QA, test or sandbox needs almost as much RAM as production. More on HANA memory in non-production systems

Follow-up tasks after the copy: checklist

After every copy from production, the target system has to become a test system again. Without these steps, there is a risk of real messages to customers, postings in partner systems or unprotected personal data.

Check the log in SCC3: errors, warnings and skipped tables
Adjust logical system names (BDLS) so that documents do not point to production
Switch over or deactivate RFC connections and interfaces
Check background jobs and stop production jobs
Block output: printing, email and EDI must not reach any customers
Restore the users and authorisations of the target system
Check number ranges
Mask personal data before testers and developers get access
Inform users and release the system

Many teams work through this list by hand every time, often at the weekend. Our sample playbook shows how the entire procedure can run automatically. Why the BDLS run alone takes hours on large systems is explained in the article BDLS after a system or client copy.

Limits of the standard client copy

The standard tools are reliable, but too coarse for the regular refresh of large S/4HANA landscapes: they copy everything or nothing, need almost production sizing in the target and leave masking and follow-up tasks to separate tools and checklists.

This is exactly where the Data Refresh Operator comes in. It copies a time slice – for example the last 90 days – plus all dependent documents: DRO copies business objects rather than date ranges. Dependencies are resolved iteratively 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. Masking and playbooks for the surrounding procedure are integrated.

Frequently asked questions about the SAP client copy

How long does an SAP client copy take?

Above all, it depends on the data volume of the source client: a pure Customizing client is copied much faster than a large production client with application data, which often ties up systems for hours or days. The test run and, from SAP_BASIS 7.54, transaction SCC_CLIENT_SIZE give you an indication. The levers that shorten the runtime are covered in Speeding up an SAP client copy.

What is the difference between a client copy and a system copy?

A client copy transfers the client-specific data of a single client. A system copy transfers the entire database with all clients, the Repository and the cross-client settings. Details in SAP system copy.

Which copy profile should I use for a QA refresh from production?

Usually SAP_ALL or SAP_APPL. With SAP_APPL, the user master records from production are left out. Many teams save the users of the target system separately beforehand, for example by exporting them with SAP_USER, and restore them after the copy.

Is cross-client data copied as well?

Not with the general profiles: the Repository and cross-client Customizing belong to the system, not to the client. For export and remote copy there are separate profiles that include cross-client Customizing (SAP_EX… and SAP_RM…).

Can a client copy transfer just a time period?

No. Copy profiles select types of data, not years. If you copy application data, you get the complete history. Partial copies by time period need additional tools, for example a time-slice-based copy such as the Data Refresh Operator.

SAP client copy: step-by-step guide, transactions and copy profiles