# SAP System Copy Checklist: Refresh QA From Production Without Surprises > Source: https://netray.co/tools/sap-system-copy-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A phased checklist for SAP system copies and refreshes, with pre-copy backups, post-copy BDLS, RFC and job clean-up, and data privacy steps. ## Category sap ## Erp SAP ECC and S/4HANA ## Audience - SAP Basis administrator - SAP security analyst - Project manager ## Tool **Kind:** checklist **Groups:** #### Planning and approvals **Items:** **Text:** Agree the purpose and scope: full refresh, client copy or database restore, with named business approval. **Critical:** true Confirm the copy method: backup and restore, SAP Software Provisioning Manager (SWPM) copy, or client copy (SCCL, SCC9, SCC1). Verify source and target run compatible SAP release, database release and operating system for a homogeneous copy. Size the target: database, file system and memory must accommodate the source data. **Text:** Schedule a freeze window and tell testers and project teams that target data will be overwritten. **Critical:** true **Text:** Decide whether production data may land in the target and what masking or scrambling rules apply. **Critical:** true #### Pre-copy preparation on the target **Items:** **Text:** Export target-specific settings you must keep: RFC destinations (SM59), logical systems, partner profiles (WE20, WE21), printers (SPAD). **Critical:** true Export target users and roles if they differ from the source, for example test users and test authorizations. Record the target profile parameters (RZ10) and instance configuration. Save open and in-flight transport requests and the import queue state (STMS). **Text:** Take a full backup of the target so you can fall back if the copy fails. **Critical:** true Save the target system license key information, since the hardware key changes the license requirement. #### Copy execution **Items:** **Text:** Take a consistent backup of the source system and verify it completes without error. **Critical:** true Stop the target SAP system and restore or load the source data into the target database. Run the SWPM or database-specific steps to rename the system ID and database if required. Start the database and SAP system and confirm the work processes come up (SM50, SM51). Check for startup errors in the developer traces and system log (SM21). #### Post-copy technical steps **Items:** **Text:** Stop and cancel scheduled background jobs copied from production before anything can run, using BTCTRNS1 or equivalent. **Critical:** true Install a new SAP license for the target system (SLICENSE). **Text:** Set client roles and change options in SCC4, and set the system change option in SE06 for the target role. **Critical:** true Run the post-installation step in SE06 for the new system if SAP requires it. **Text:** Convert logical system names with BDLS and verify the result in the log. **Critical:** true **Text:** Re-create or correct RFC destinations to target partners so the target does not call production (SM59). **Critical:** true Reconfigure the transport domain and routes (STMS) and re-check the import queues. Adjust profile parameters, logon groups (SMLG) and operation modes for the target hardware. **Text:** Reconfigure printers, output devices and mail connectivity (SPAD, SCOT, SOST) to avoid sending test mail to real people. **Critical:** true #### Post-copy functional and security steps **Items:** Restore the saved target-specific settings: users, roles, partner profiles and interface definitions. **Text:** Reset or lock production user passwords and remove access not wanted in the target. **Critical:** true **Text:** Apply data masking or scrambling to personal and sensitive data, as policy requires. **Critical:** true Disable or point external interfaces, EDI and webhooks to test endpoints. Reschedule only the background jobs the target needs and confirm they point at test resources. Run smoke tests: log on, post a test document, run a standard report. Hand over to testers with a note of the data cut-off date and the open issues. Update the system landscape documentation and the SLD entries. **Scoring Note:** Items flagged critical protect production and personal data. If any of them is unticked when you hand over the system, record why. ## Content **Intro:** An SAP system copy gives you a realistic test or QA system, but it also copies production jobs, interfaces and personal data. This checklist covers planning, preparation, execution and the post-copy steps that stop a refreshed system from emailing customers or calling production. **Sections:** #### How to use this checklist **Body:** Print or export the list and tick items during the refresh weekend. The first two groups are done before any downtime, so they protect you if something fails halfway. The third group is the technical copy itself. The last two groups are where most mistakes happen, because the restored system believes it is production. Assign each critical item to a named person. Keep the exported result with the change ticket so there is evidence of what was done and when. For a client copy instead of a full system refresh, skip the database and SWPM items and use the client copy transactions. **Bullets:** - Do the preparation groups before downtime - Assign each critical item to a person - Attach the export to the change record #### Why the post-copy steps matter **Body:** After a restore, the target holds production settings. Scheduled jobs can start as soon as the system comes up. RFC destinations still point at real partners. Printers and mail settings may reach real users. The logical system name still matches production, which breaks distribution models and application link enabling, so BDLS is run to convert logical system names throughout the data. The client role and change options also come across. If those are not corrected, developers can end up working in a system that behaves like production. The order matters: stop jobs first, license and client settings next, then BDLS and RFC. **Bullets:** - Stop jobs before the system is open to users - Run BDLS and read the log for errors - Check every RFC destination, do not assume #### Data privacy and security **Body:** A refreshed non-production system often holds real customer, employee and supplier data. Many privacy regimes expect that data to be protected or masked. Decide the policy before the copy: mask names, bank details and tax numbers, or limit access to the refresh team until scrambling completes. Passwords and user master data also deserve attention. A production user with broad access should not carry the same access in the test system. Keep a record of what was masked, since a later review will ask. Where the target is a development or training system, the case for masking is stronger. **Bullets:** - Mask before opening to testers - Reset passwords and lock unneeded users - Record the masking rules applied #### Common mistakes **Body:** Frequent mistakes include forgetting to cancel jobs so test systems send real emails or post to real interfaces, skipping BDLS and then wondering why IDocs fail, and losing target-specific user and role setups. Teams also forget the new license, so the system stops working a few days later. Another error is not taking a target backup, which removes any path back. Plan for time: databases, BDLS and post-processing can each take hours on a large system, so a weekend window needs buffer. **Bullets:** - Cancel jobs and block mail early - Request the license before handover - Allow time for BDLS on large databases **Cta:** If you refresh systems often and want the post-copy steps scripted and checked automatically, Netray can build agents that run on your own infrastructure with human approval on every change. **Faq:** #### What is BDLS in an SAP system copy? **Answer:** BDLS is the transaction that converts logical system names in the data of a copied system. After a copy the target still carries the source logical system names, which breaks distribution and interfaces. BDLS replaces the old name with the new one across relevant tables and should be run with a log you can review. #### How do I stop background jobs running after a system copy? **Answer:** Run the standard report BTCTRNS1 before the system opens, which sets released jobs to a suspended status so they do not start. Afterward, review the list and restore only the jobs the target needs with BTCTRNS2 or by rescheduling them intentionally. #### Do I need a new SAP license after a system copy? **Answer:** Usually yes. The license is tied to the installation's hardware key, so a copied system needs its own key installed in SLICENSE. Request it from the SAP support portal ahead of time to avoid the system running on a temporary license. #### Is a client copy the same as a system copy? **Answer:** No. A client copy duplicates client-specific data inside one system or between systems, using transactions like SCCL, SCC9 and SCC1. A system copy duplicates the whole system, including all clients and client-independent objects, typically with a database restore. ## Search terms sap system copy checklist, sap system refresh checklist, sap post copy steps, bdls logical system conversion, sap homogeneous system copy, sap qa refresh from production, swpm system copy, sap post system copy activities --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json