System Copy Checklist: What SAP Documentation Misses

A system copy is one of the higher-risk operations a BASIS admin performs. The SAP documentation covers the technical mechanics reasonably well. What it systematically underemphasises is the post-copy checklist — the steps that do not fail immediately but cause subtle, hard-to-diagnose problems days or weeks later.

Homogeneous vs Heterogeneous Copies

A homogeneous copy involves the same operating system and database platform on source and target. A heterogeneous copy crosses OS or database boundaries — for example, from Oracle on UNIX to HANA on Linux. Heterogeneous copies require R3load-based export/import through SWPM and are significantly more complex.

For most system refreshes (rebuilding QAS from PRD), you will be doing a homogeneous copy. SWPM handles this via database-specific backup/restore methods. The process itself is well-documented. The post-copy steps are where projects fall short.

Pre-Copy Preparation

Before starting the copy, document the current state of the target system. Specifically: RFC destinations, logical system names, output devices, background job schedules, and any interface configurations. You will need this to verify that the post-copy adjustments are complete.

Freeze transports to the target system for the duration of the copy. Any transport imported after the copy baseline was taken will be missing from the refreshed system and will need to be re-imported.

Ensure the target system is in a consistent state before overwriting it. Check SM21 for recent errors and resolve anything critical. If the target system has data that needs to be preserved — test scripts, QA test cases, custom variants — export them before the copy.

The Copy Itself

Follow the SWPM procedure for your specific platform combination. This is the part SAP documents thoroughly. Use the Software Provisioning Manager, not legacy tools. Validate checksums after the copy. Do not skip the post-copy SWPM steps for licence key, user synchronisation, and profile parameter adjustments.

What SAP Docs Underemphasise: Post-Copy Steps

The SAP documentation's post-copy checklist covers the technical minimum. Production systems have configuration that was built up over years and is not fully reflected in any official checklist. The items below are the ones most commonly missed.

RFC Destinations

This is the highest-risk post-copy item. After a system copy, all RFC destinations in SM59 point to whatever the source system was connected to. If you have copied PRD to QAS, your QAS system now has live RFC connections to production systems, production payment processors, and production bank feeds.

Go through every RFC destination in SM59 immediately after the copy. Update or disable connections to production systems, external partners, bank SFTPs, and any other live integration points. Do not assume that a naming convention (like a "P" prefix in the connection name) makes this obvious — it often does not.

Create a post-copy RFC verification step that is signed off by a named individual before the copied system is opened to users.

Batch Jobs and Scheduled Tasks

All background jobs from the source system are copied with the system. In SM36 you will find the full job schedule from production, now running in your QAS or development system. This includes: jobs that send emails to real users, jobs that post financial documents, jobs that trigger outbound EDI messages, and jobs that call external APIs.

After a copy, reschedule or deactivate all background jobs. Review them individually before re-enabling any. A QAS system should generally run a subset of PRD's job schedule, with external-facing jobs disabled entirely.

Logical System Names and IDocs

The logical system name is stamped on every IDoc the system generates. After a copy, the logical system name needs to be updated in BD54 and SALE to reflect the target system's identity. If you do not do this, outbound IDocs generated by the copied system will carry the source system's logical system name, confusing trading partners and potentially routing documents to the wrong system.

Check all distribution model entries in SALE. Update or remove partner profiles in WE20 that point to production endpoints.

Print and Output Configurations

All spool and output device configuration from the source system is copied. Your QAS system now has access to every production printer. More importantly, output conditions and condition records for invoice printing, delivery notes, and other business-critical output are pointing at real printers and real fax numbers.

Review SPAD for output devices. Disable or redirect devices that should not be active in the target system. For Finance teams, verify that automatic payment advice output is not pointing at live bank fax numbers.

User Passwords and Licences

The system copy brings all users from the source system, including their current password hashes. In most cases you will want to reset all non-basis-admin passwords in the copied system to prevent users from logging into QAS using production credentials and making changes they think are in production.

Transaction SUIM can generate user lists for mass password reset. The SAP licence key is system-specific — update it via SLICENSE after the copy. Running a copied system without the correct licence key will eventually lock system access.

> Editorial note: Post-copy steps vary significantly by landscape configuration, integration complexity, and system version. This checklist covers common scenarios but is not exhaustive. Always document your specific landscape's integration points before performing a copy.