Client Creation, Client Copy Procedures and Client Settings Administration

Explanation

Once the client concept is understood, the next operational skill is actually creating and populating a client safely. Client maintenance begins with defining the client record itself: assigning a client number, a descriptive name, the responsible organization, and critically, the client role (such as customizing, production, test, demonstration, or training) along with change and transport protection settings and client-specific logon restrictions. These protection settings control whether repository and cross-client customizing changes are allowed directly in that client, whether client-dependent customizing changes require being recorded to a transport request, and whether eCATT/CATT and external system access are permitted. Getting these settings wrong is a frequent source of incidents: for example, leaving a production client open for direct customizing changes undermines change control and audit traceability, while leaving a development client too locked down blocks legitimate configuration work. A new client typically starts out empty except for a minimal technical shell, so it must be populated through a client copy, which duplicates data and/or customizing from an existing source client. SAP provides different copy mechanisms depending on scope and location of source/target: a local client copy runs when source and target clients reside in the same system, a remote client copy transfers data across systems using RFC connections, and client export/import mechanisms move data at the operating system file level for cross-landscape scenarios. Each of these approaches uses copy profiles that define exactly what is copied — for example, only customizing tables (cross-client and client-specific configuration, no master or transactional data), or customizing plus limited application data, or a full copy including master and transactional data. Choosing the correct profile is a critical judgment call: copying full production data into a training or demo client without proper handling could expose sensitive data, while copying only customizing into a new UAT client without any master data would leave it unusable for testing without additional data loads. Before initiating a copy, administrators must ensure the target client exists, is not being used by other users, and that source and target clients are not locked during the operation, since a client copy is resource-intensive and inconsistent access during copy can cause corruption. Administrators should also review the copy log carefully after completion for errors and warnings — tables that failed to copy due to conflicts, size limits, or authorization issues are recorded there, and these gaps can silently cause downstream configuration problems if not investigated. A best practice is to run copies during a maintenance window with the client locked, and to perform post-copy validation such as spot-checking key customizing entries, running consistency checks, and confirming number range and workflow configuration were copied as expected, since some settings (like certain number range buffers) may need explicit resets after a copy. In S/4HANA on-premise and private cloud, this administration model is largely unchanged from ECC, though the underlying data volumes and HANA-specific considerations (such as copy duration on large HANA databases and interaction with in-memory calculation views) can affect copy strategy and timing. In S/4HANA Cloud public edition, customers typically do not perform direct client copies themselves; SAP manages the underlying tenant/client provisioning and refresh cycles as part of the service, and customers instead use configuration transport and activation tools appropriate to that deployment model — so Basis-style client copy skills learned on-premise do not directly transfer to that operating model, and administrators should verify current tenant refresh capabilities with the specific cloud service documentation rather than assuming ECC-style procedures apply.

Code example

* Illustrative sequence for a local client copy (conceptual, not a script)* 1. Create client record: define client number, name, role=Customizing, change/transport protection=locked for direct changes* 2. Ensure target client has no active users; place source and target under copy lock* 3. Select appropriate copy profile, e.g.:*    SAP_CUST   - client-specific and cross-client Customizing only*    SAP_UCSV   - Customizing plus user master records*    SAP_ALL    - full copy including master and transactional data (use with strong caution)* 4. Execute local client copy (e.g., via SCCL) specifying source client and chosen profile* 5. Monitor copy job progress; do not interrupt* 6. Review copy log (e.g., via SCC3) for errors/warnings per table* 7. Perform post-copy checks: number ranges, workflow customizing, background job definitions* 8. Unlock target client for intended use once validated

Real project scenario

A project team requests a fresh QA client refreshed from production customizing (but not production transactional data) ahead of a regression testing cycle. The Basis administrator creates the new client, sets its role to Test, applies a customizing-only copy profile from the production client, and schedules the copy overnight with both clients locked. After completion, the administrator reviews the copy log, finds a handful of tables flagged as skipped due to client-independent content, confirms this is expected, and then runs a smoke test of core transactions before releasing the client back to the test team.

Common mistakes

• Selecting a copy profile that includes far more (or less) than intended, such as accidentally copying transactional data into a training client. • Not locking the client during copy, leading to data inconsistency if users attempt access mid-copy. • Skipping review of the copy log, missing table-level failures that later surface as missing configuration. • Leaving a newly created client with overly permissive change/transport settings, allowing uncontrolled direct customizing changes. • Assuming client copy procedures used in ECC or S/4HANA on-premise apply unchanged to S/4HANA Cloud public edition tenants.

Best practices

• Always define client role and change/transport protection settings deliberately at creation time, not by default. • Choose the narrowest copy profile that satisfies the actual business need for the target client. • Lock both source and target clients during copy execution and avoid interrupting the copy job. • Always review the copy log for errors or skipped objects before declaring the client ready. • Mask or avoid copying sensitive production data into training, demo, or lower test environments where not required. • Confirm current capabilities and procedures with deployment-specific documentation before assuming ECC-style client copy applies in cloud environments.

Interview angle

Interviewers may ask candidates to describe the difference between local and remote client copy, when each is appropriate, and how to choose a copy profile for a given business need. Strong candidates explain the importance of reviewing copy logs, describe risks of copying sensitive production data into non-production clients, and can articulate that cloud public edition clients are administered differently than on-premise clients.