The refresh calendar with Basis

A test environment ages from the day it is refreshed. Master data drifts from production, open items pile up, test runs consume stock and change statuses, and number ranges advance. Refreshing is the cure, but every refresh also destroys something: project data, test users, configuration in flight, connected-system settings. The refresh calendar decides when each environment is renewed, how, and what must be rebuilt afterward, so that refreshes land just before the test windows that need them and never in the middle of one.

System copy or client copy

The client copy transactions are long established: SCCL for a local copy, SCC9 for a remote copy, SCC8 and SCC7 for export and import, and SCC3 for the logs, with profiles such as SAP_ALL (all client data), SAP_CUST (customizing only) and SAP_UCUS (customizing and user masters). From SAP_BASIS 7.54, the ABAP basis of SAP S/4HANA 1909, SAP also offers a new client copy tool with SCCLN (local) and SCC9N (remote), parallel processing of large tables, and SCC_CLIENT_SIZE to estimate a client's size before copying; SAP Note 2962811 is the general information note. Sam's team decides which tool to use. The TCoE needs to know only what each method keeps and what it destroys.

The post-copy runbook

A copy is not a test environment. A system copied from production starts life believing it is production: its RFC destinations point at production partners, its background jobs are scheduled as in production, its logical system names are production's, and its users and roles are production's. The post-copy runbook turns it into a safe, usable test system. Basis owns the technical steps; the TCoE owns the readiness check at the end.

Two details deserve emphasis. First, export what you need to keep before the copy: test users and roles, RFC destinations and partner profiles of the target, and transports that exist only in the target. Second, track the runbook as a checklist with timestamps. The time from "copy complete" to "test-ready" is one of the service's key measures, and Contoso's first refresh of CMR took six working days, most of it waiting for unrecorded manual steps.

Who does the copy depends on your contract

Under RISE with SAP, SAP operates the systems, and system copies and refreshes are services whose number, scope and post-copy steps are defined in your contract and in SAP's roles and responsibilities documentation for SAP S/4HANA Cloud Private Edition. Read it before you build a calendar: it tells you how many copies are included, how far ahead to request them, and which post-copy steps SAP performs and which remain yours. For on-premise landscapes, many customers automated refreshes with SAP Landscape Management 3.0. Its mainstream maintenance ends on December 31, 2027 with no extended maintenance planned (SAP Note 3375877), and SAP has since discontinued SAP Landscape Management Cloud, so check how your refresh automation will continue. In SAP S/4HANA Cloud Public Edition the model is different again: SAP offers a Test Data Refresh service, requested through SAP for Me, that replaces master and transactional data in the quality system with production data, including depersonalization, without copying configuration (SAP Note 3070606).

Building the calendar

Lay refreshes onto the TCoE annual calendar (sap-tst-401, lesson 4) and work backward from the test windows. CMR is refreshed four times a year; two of those refreshes are timed three weeks before the regression windows for Contoso's two feature pack stack updates, so the system is production-like when the stack arrives. CMQ is refreshed once a year in a quiet window agreed with all projects, because every refresh wipes project data and any transport not yet in production, which then has to be re-imported from a list Luis prepares.