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 full system copy through local or remote client copy to a targeted data refresh, and the right one depends on what the requester actually needs. This post separates them, walks the client-copy mechanics with the real transactions (SCCL, SCC9, SCC5, SCC3, BDLS), and is clear about what can be automated today versus what still takes hands.

Three things people mean by "refresh"

Pin down which one the request is before you touch anything. The effort and the blast radius are wildly different.

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

The copy profile decides what comes across

For any client copy the single most important parameter is the copy profile. It decides which categories of data are copied, and it is where "the refresh looks wrong" usually originates.

A common QAS refresh uses SAP_ALL for a true copy, then re-applies the QAS-specific user set separately; a "give me PRD customizing without the users" request is SAP_APPL. Get the profile wrong and you either drag production users into a lower system or leave testers unable to log in.

Before the copy: know your clients

Every client-specific operation reads T000. Confirm exactly which clients exist and which you are about to touch. The number of production incidents that start with "wrong client number" is not small.

# The client list (transaction SCC4 is the UI; the table is the truth)
SE16 -> T000     # MANDT, MTEXT, ORT01, CCCATEGORY (P/T/C/D/S), CCCOPYLOCK

# Roles of the reserved clients (never a copy target)
#   000  SAP reference client
#   001  template / reference
#   066  EarlyWatch (legacy; remove if present)

Running the copy (SCCL / SCC9)

Never run a real client copy in a dialog work process. It will hit rdisp/max_wprun_time and die halfway. Schedule it in the background with parallel processes, and give the system enough background work processes for the window.

# SCCL: local client copy, run in BACKGROUND with parallel processes
#   Source client   : e.g. 100 (the client you are copying FROM)
#   Target client   : the CURRENT logon client (you copy INTO where you are)
#   Copy profile    : SAP_ALL / SAP_APPL / ...
#   Processes       : 4–8 parallel (bounded by free background WPs)
#   -> "Schedule as Background Job", not "Start Immediately"

# Make sure the background WPs exist for the window (RZ04 operation mode),
# then watch progress and the log:
SCC3             # copy/transport logs: status, table counts, errors
SM37             # the RSCLICOPY* background job(s)
SM50 / SM66      # the parallel copy processes actually running

A remote client copy (SCC9) does the same across systems over an RFC destination, so the network and the RFC/gateway sizing become the constraint. Where a stable RFC is not available, the transport-based route, using client export SCC8 on the source and SCC7 post-import on the target, moves the client as transport files instead.

Deleting the target first: SCC5, carefully

A copy overwrites, but a clean refresh usually deletes the stale target client first. SCC5 removes a client's data permanently. There is no undo and no "oops" recovery short of a restore.

# SCC5: delete client data. Two rules are non-negotiable:
#   1. a CURRENT, VERIFIED backup of the target system exists
#   2. you have triple-checked the client number (it is the current logon client)

# Options:
#   - Delete client from T000 as well, or keep the empty client shell
#   - Run in BACKGROUND (large clients take hours)
# Guard 000 / 001 against deletion at the policy level, not by memory.

SCC5 is the single operation most worth putting behind pre-checks and an explicit, typed confirmation. Every serious client-copy incident I have seen traces back to SCC5 run against the wrong client, in the wrong system, without a fresh backup.

The step everyone forgets: BDLS

A freshly copied client still carries the source system's logical system names in its ALE / RFC / workflow configuration. If you skip the rename, your refreshed QAS client will happily send IDocs, trigger workflows and post to interfaces as though it were production. Convert them before anyone logs in:

# BDLS: convert logical system names in the copied client
#   old: e.g. PRDCLNT100   ->   new: QASCLNT100
#   Run in BACKGROUND; on a large client it rewrites many tables.
#   Pre-check the conversion list; run a test run first if unsure.

# Then the post-copy checklist (all client-specific):
SCC3    # confirm the copy finished with no errors
SM59    # repoint RFC destinations away from production
BD54 / SALE  # logical systems and ALE model, post-BDLS
SM37    # released batch jobs: reschedule or delete PRD-scheduled ones
SCOT / SO16  # SMTP/output nodes so the copy doesn't email real users
STMS / SE06  # transport routes, if this client participates in TMS

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, tracked to completion via the same SCC3/SM37 signals. Client deletion (SCC5) runs behind pre-checks, with clients 000/001 protected and a target-client login verified first, then recorded in the audit trail. Both are role-scoped, so only the people who should be able to run a destructive operation can.

A single guided system refresh that orchestrates SCC5 → SCCL → BDLS → post-checks as one operation is on our roadmap rather than shipped today. The building blocks are automated, the end-to-end wrapper is coming, and we would rather you know that now than discover it in a demo. The full picture is on the SAP Basis automation page.

A short checklist

• Confirm which "refresh" this is, whether a system copy, a client copy or a targeted slice, before scoping downtime.
• Read T000 and confirm the exact client numbers; never target 000/001.
• Pick the copy profile deliberately (SAP_ALL vs SAP_APPL vs SAP_USER). It decides who can log in and what data lands.
• Run SCCL/SCC9 in the background with parallel processes and enough background WPs for the window.
• Never run SCC5 without a fresh, verified backup and a triple-checked client number.
• Run BDLS before anyone logs in. A copied client that still names production logical systems is a hazard rather than a refresh.
• Finish the post-copy checklist (SM59, batch jobs, output nodes). A half-finished refresh is where the time leaks and the surprises live.

The value of automating this is not that a client copy is hard. It is 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. That is the same reason the rest of the platform exists: operations across the landscape, on the record. To see SCCL and SCC5 run against a sandbox, write to contact@farrenio.com.