SCC1 — SCC1 Client Copy of Transport Requests
SCC1 copies the client-dependent contents of one or more already-imported transport requests from one client into another client of the same system, without going through the transport queue. It is used to replicate customizing changes across sandbox, test, or training clients that share a system but did not receive the request through STMS.
SCC1 replays the client-specific portion of a transport request into a different client within the same SAP system. This page covers the real usage pattern in multi-client landscapes, the tables the copy touches, and the failure modes that come from mixing this up with a normal transport import.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,056 words
Purpose
SCC1 takes one or more transport requests that already exist on the system (imported or even just released) and copies their client-dependent contents into a target client different from the one the request was originally created against. The structural fact that causes most confusion: cross-client repository objects in the request (programs, dictionary structures, function modules) live once per system and are not duplicated by SCC1 - they were already applied when the request landed in the system. SCC1 only replays the client-bound part: customizing table entries, client-specific master data setup, and similar content. Anyone expecting SCC1 to move code between clients is misunderstanding the object; that already happened at import time.
When it is used
SCC1 is reached for in landscapes with multiple clients on the same system - a customizing client, a unit-test client, a training client, a demo client - where a transport request was created and imported against one client but a second client also needs the same customizing without going through a full STMS import cycle (which would apply the request system-wide only to the client it targets). Typical case: a request was released and imported into the QA customizing client, and now the same configuration is needed in a parallel test client for a different project stream, or a client was created after the original import and missed the request entirely. It is not a substitute for STMS in normal transport flow between systems.
How to use it in practice
- Call transaction SCC1.
- Enter the target client - the client that should receive the data, not the source client.
- Enter the transport request number, or a range/list if copying several requests together.
- Choose whether to run in test mode first to see what would be copied.
- Execute the copy and review the resulting log for errors or skipped objects.
- Confirm in the target client that the customizing entries are now present.
Key data objects
- E070 - header of the transport request being copied, including request type and status.
- E071 - object list of the request, showing which programs, tables, or customizing objects are included.
- E071K - key-level entries for table-bound customizing content, the actual client-dependent rows the copy replays.
- Target client-dependent tables - whatever application tables the customizing objects in the request belong to; these receive the copied rows directly.
- Client copy log table - stores the run result, timestamp, and any object-level errors from the SCC1 execution.
How to prove it in the data
In SE16 on E071K, filter by the transport request number to see the exact table and key combinations the request carries. Cross-check those tables in the target client to confirm whether the rows are present with the expected values, and compare timestamps or change documents where available against the copy execution time. If a customizing table shows no trace of the change in the target client, the copy either failed silently for that object or was blocked by client change options - check the copy log before assuming the transaction did nothing.
ECC vs S/4HANA
SCC1 behaves the same way on S/4HANA as on ECC. It remains a classic GUI transaction with no dedicated Fiori app; client administration and client copy activities are still handled through the SAP GUI transport and client tools. No structural change has been introduced to how the transaction selects, filters, or replays transport request content.
Common pitfalls and how to diagnose them
- Wrong target client selected - the single most damaging mistake with SCC1 is entering the wrong client number and overwriting customizing in a client that was not meant to receive it. There is no confirmation screen that describes the business purpose of the target client, only its number, so always verify the client description before executing.
- Repository versus client-dependent confusion - complaints that SCC1 did not bring over a new program or table structure usually mean the person expected repository content to move again; it already moved at import and SCC1 has nothing to do there. Check the object list in the request first to know what SCC1 can actually affect.
- Client change options blocking the write - if the target client's cross-client or client-specific change settings (maintained in SCC4) do not allow automatic changes, SCC1 can complete with warnings while silently skipping protected tables. The reflex fix of rerunning SCC1 repeatedly does nothing; the change options have to be checked first.
- Active users or locked objects in the target client - customizing entries locked by another user's session in the target client cause partial copies. Check active sessions in the target client before running SCC1, particularly for large or dependency-heavy requests.
- Dependency order failures - a request that references organizational or master data not yet present in the target client can copy some tables successfully and fail on others, leaving the client in a half-configured state. Reviewing the copy log object by object, not just the overall return code, is the only way to see this.
Whose problem this is
SCC1 is a Basis-owned transaction because it touches client landscape and system consistency, but the decision to run it is usually driven by a functional or configuration team that needs a request replicated. A good handover states the exact request number, source and target client, the business reason, and confirmation that the repository objects in the request already exist in the target client's system.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/scc1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.