SAP System copy
A system copy duplicates an SAP system, for example refreshing QAS from PRD, or building a new sandbox. It is a routine but delicate Basis task with important post-copy steps to keep the landscape consistent.
A system copy refreshes a QAS or sandbox with production data, builds a new system or creates a temporary one. A homogeneous copy keeps OS and database; a heterogeneous copy changes them through SWPM or DMO. The post-copy steps keep it safe: rename the logical system, reconfigure RFC destinations and interfaces, adjust TMS and jobs, scramble sensitive data.
- Watch out: Inherited interfaces sending test data to real partners.
Why system copies are done
- Refreshing QAS/sandbox with realistic production data.
- Building new systems in the landscape.
- Creating temporary systems for projects or testing.
Homogeneous vs heterogeneous
A homogeneous copy keeps the same OS and database; a heterogeneous copy changes them (also called a migration, e.g. to HANA), which uses SWPM’s export/import (or DMO). Homogeneous copies can also use database-native backup/restore for speed.
Critical post-copy steps
After copying, the target must be adjusted so it does not behave like the source: rename the SID/logical system, reconfigure RFC destinations and interfaces, adjust the TMS, reset background jobs, and, importantly, scramble or protect sensitive production data copied into a non-production system.
Why care
A careless system copy can send test transactions to real partners (via inherited RFC/interface config) or expose production data. The post-copy checklist exists precisely to prevent these serious mistakes.
Common pitfalls
- Inherited interfaces sending test data to real partners.
- Unscrambled production data in a non-production system.
- Forgetting logical-system/TMS adjustment after copy.