SAP System Refresh vs Client Copy: Which One You Actually Need

"Can you refresh QA?" is one of the most commonly misunderstood requests in SAP operations, because it is used to mean two entirely different pieces of work with different costs, different risks, and different outcomes.

One takes hours and copies configuration. The other takes a weekend and replaces a system. Getting the answer wrong means either a test system that still cannot reproduce the defect, or a lost weekend nobody needed to spend.

What each one actually moves

The line that matters: a client copy does not move the repository. Custom programs, dictionary objects, classes, enhancements — none of it travels. Neither does cross-client Customizing.

This is behind the most common disappointment with client copies. A defect cannot be reproduced in QA, someone runs a client copy from production, and the defect still cannot be reproduced — because the difference was never the client-specific data. It was a program version, or a cross-client setting, or an object that exists in production and not in QA.

When a client copy is the right tool

• Creating a new configuration client from an existing one
• Setting up a training or sandbox client with current configuration
• Refreshing a unit-test client after configuration drift
• Restoring user master records after another copy overwrote them
• Moving a specific configuration change between clients in the same system (SCC1, by transport request)

The common thread: the code is already right, and only client-specific content needs to change.

When you need a full refresh

• The target must reproduce production behaviour, not just production configuration
• Performance or volume testing that needs realistic data sizes
• Testing an upgrade or conversion against genuine production content
• QA has drifted so far — from partial imports, manual fixes, abandoned test data — that nobody trusts it
• The target system's repository is materially behind production

Client copy: the transactions and the profiles

The copy profile decides what travels, and choosing it casually is the usual reason a copy overruns its window:

• `SAP_CUST` — Customizing without application data. The normal choice for a fresh configuration client.
• `SAP_UCUS` — Customizing plus user master records.
• `SAP_APPL` — Customizing and application data, without user master records.
• `SAP_ALL` — everything, including application data and users. The largest and slowest, and often selected by default when SAP_CUST was what was needed.
• `SAP_USER` — user master records and authorizations only.

Two practical notes. First, a client copy holds locks and generates substantial database load; running one against a system others are using does not end well. Second, SCC3 is where you find out what actually happened — check it rather than assuming a copy that finished, finished cleanly.

System refresh: the part that goes wrong

The copy itself is well-trodden: a homogeneous system copy from a production backup, restored onto the target, using SAP's provisioning tooling. The database work is routine and the tools are mature.

The post-copy steps are where refreshes fail — and they fail late, after the system is nominally handed back.

The non-negotiable ones

`BDLS` — logical system name conversion. The refreshed system still believes it is production, because logical system names came across in the data. BDLS converts them. It scans and updates every table holding logical system references, which on a large system means very large tables and a long runtime. Budget for it explicitly; it is routinely the longest single step.

`STMS` reconfiguration. The target's TMS configuration came from the source. Until it is corrected, the system's place in the transport domain is wrong, and the import buffer may contain requests that make no sense for it.

RFC destinations. These came across pointing at production's partners. Until corrected, a test system is talking to production systems — the single most dangerous post-refresh state, and the one worth checking before anything else.

Outbound interfaces. Anything that sends email, EDI, payment files, or messages to external partners must be disabled or redirected before users are let in. A refreshed test system that dispatches real payment instructions is an incident that reaches outside the company.

The ones that get forgotten

• Background jobs. Production's job schedule came across. Jobs that should not run in QA will run, on production's schedule.
• Printers and spool (SPAD). Output devices point at production printers.
• Secure store (SECSTORE) and certificates — encrypted entries generally do not survive a copy intact and need re-maintenance.
• Licence (SLICENSE) — the target needs its own.
• Users and authorizations — usually restored from a pre-refresh export, or copied with SAP_USER, depending on whether QA has its own user population.
• `SICF` services — services enabled in production may need to differ.
• Operation modes and system parameters — sized for production hardware, not the target's.
• Number ranges — worth reviewing where the target generates documents that will later be compared against production.
• Client settings (SCC4) — a refreshed client inherits production's change options, which usually need loosening for a test system.

None of this is difficult. It is long, it is easy to lose track of, and it is exactly the kind of work where a written runbook is the difference between a clean weekend and a Monday spent finding out what was missed.

Automating it

Post-copy automation is worth setting up if you refresh more than once or twice a year. SAP's landscape tooling can drive the post-processing steps from a defined task list, so the sequence is repeatable and auditable rather than reconstructed each time from someone's notes.

The honest test of whether your refresh process is under control: could someone other than the person who normally does it execute it correctly from the documentation? If not, the process is a single point of failure regardless of how well it has gone so far.

Deciding, in one question

Does the target need production's code, or just production's configuration?

Code — refresh. Configuration only — client copy. If the answer is "we're not sure why QA behaves differently," the answer is refresh, because that uncertainty is itself evidence the repository has drifted.

Before you start, either way

• Export what you will lose. Unreleased transport requests, QA-specific configuration, test data someone needs — none of it survives a refresh, and every refresh has someone who assumed it would.
• Check the transport queue. Requests in flight at refresh time need a deliberate decision.
• Agree the outage window with the people whose work stops, not just with IT.
• Write down the post-refresh checklist before you need it.

Refreshes and client copies are standard work for our managed Basis team, and a defined refresh runbook is one of the deliverables of a Basis health check — usually because the existing process turned out to live in one person's memory.

Related reading

• SAP Transport Management System (STMS): A Practical Guide — why the transport queue matters at refresh time
• What Is SAP Basis? — where this work sits in the wider discipline