SAP system refresh and client copy with SCC5 and SCCL

"Refresh QAS from production" is one of the most routine requests a Basis team gets and one of the easiest to get subtly wrong. The phrase covers a range of operations — from a full system copy to a client copy to a targeted data refresh — and the right one depends on what the requester actually needs. This post separates the options, walks through the client-copy mechanics with SCC5 and SCCL, and is clear about what can be automated today versus what still takes hands.

Three things people mean by "refresh"

• System copy — clone the whole system (all clients, the full database) onto the target. This is the heavyweight option, usually done at the database level with a backup/restore or a system-copy tool, and it is what you want when QAS must be a faithful mirror of production including every client.
• Client copy — copy a single client's data into a target client, within the same system (local) or from another system (remote). This is the right tool when you only need one client's customizing and data refreshed, not the entire system.
• Targeted data refresh — bring across a subset of data, often with scrambling for non-production. More project than routine task, and outside the scope of this post.

Choosing wrongly is expensive in both directions: a full system copy when a client copy would do wastes a weekend; a client copy when the requester needed a true mirror leaves them testing against the wrong baseline.

Client copy: SCCL and SCC9

A local client copy (transaction SCCL) copies data between clients in the same system. The key decision is the copy profile, which controls what comes across:

• SAP_ALL — customizing, master and transaction data. The full picture.
• SAP_APPL — customizing and master data, but not transaction data.
• SAP_CUST — customizing only.
• SAP_USER — user master and authorisations only.

SCCL runs as a background job, ideally with several parallel processes, and should be sized for the window — a SAP_ALL copy of a large client is not quick. A remote client copy (SCC9) does the same across systems over an RFC connection, with the network and the RFC sizing becoming the constraint.

Client deletion: SCC5, carefully

Before a fresh copy lands in a target client, the old client data usually has to go. Transaction SCC5 deletes a client's data permanently. Two rules are non-negotiable: never run it without a current backup, and never run it against a client you have not triple-checked. The protected clients (000 and 001) should be guarded against deletion entirely. SCC5 is the operation most worth putting behind pre-checks and explicit confirmation, because there is no undo.

A client-refresh sequence

1. Confirm the request really is a client refresh, not a full system copy.
2. Verify a current backup of the target system exists.
3. Lock the target client and make sure no users are working in it.
4. Delete the target client's data with SCC5.
5. Run the client copy (SCCL locally, SCC9 remote) with the chosen profile.
6. Post-processing: number ranges, RFC destinations, logical system names, scrambling where required, and re-opening the client.

The post-processing step is where refreshes leak time, because it is the part that is hard to standardise and easy to half-finish. A copied client that still points at production logical systems is a hazard, not a refresh.

What can be automated today

Farrenio automates the two client operations above as agent-executed jobs with guided pre-checks. Local client copy (SCCL) runs with a chosen copy profile, process count and background mode, and is tracked to completion. Client deletion (SCC5) runs behind pre-checks, with clients 000 and 001 protected and a target-client login verified first, then the result recorded in the audit trail. Both are scoped by role, so only the people who should be able to run a destructive operation can.

A single guided system refresh that orchestrates SCC5 + SCCL with post-processing as one operation is on our roadmap, not shipped today — the building blocks are automated, the end-to-end wrapper is coming. We would rather you know that now than discover it in a demo. The full picture of what is automated versus planned is on the SAP Basis automation page.

The point of automating it

The value is not that a client copy is hard — it is that doing it the same way every time, with the same pre-checks, behind role-based access, with a record of who ran what against which system, turns a risky weekend task into a routine one. That is the same reason the rest of the platform exists: operations across the landscape, on the record. If you want to see SCCL and SCC5 run against a sandbox, write to contact@farrenio.com.