System Copy in RISE: The Real Story
Many RISE customers assume SAP handles system copies end-to-end. In reality, you own significant prep and post-copy tasks. Here's what actually happens and how to streamline the process.
The Common Misunderstanding
"SAP manages our infrastructure, so they handle system copies."
This is partially true. SAP executes the database-level copy and restores target systems. But you are responsible for pre-copy prep (client exports, user locks, archiving), post-copy configuration (logical system names, RFCs, printing, batch jobs), testing, and cutover approval.
Who Does What
SAP Manages
- Database-level copy (backup/restore or storage snapshot)
- Target system shutdown and startup
- Basic system verification (database consistency)
- Infrastructure-level troubleshooting (OS, DB)
- Schedule coordination and downtime notification
You Still Own
- Pre-copy prep (user locks, batch job holds, archiving)
- Post-copy configuration (RFC, printers, batch variants)
- Logical system name adjustments
- Testing and smoke tests
- User acceptance and signoff
- Interface reconnection and validation
Pre-Copy Checklist
Complete these tasks before submitting your system copy request to SAP:
Lock all users (except emergency)
Use SU01 or SUIM to mass-lock users. Leave a few Basis users unlocked for post-copy work.
Hold all scheduled batch jobs
Use SM37 to prevent jobs from running immediately after copy. Release selectively post-copy.
Export critical client data (if needed)
For QA → DEV copies where you need to preserve DEV-specific config, export client 000 data first.
Document target-specific settings
List RFC destinations, printer configs, email settings, ArchiveLink, EDI partners - anything that differs between source and target.
Archive old data (optional but recommended)
Reduce copy time and target system size by archiving documents, change docs, and logs before copy.
Coordinate with dependent systems
Notify teams that manage interfaces, reporting tools, or downstream systems that the target will be refreshed.
Post-Copy Checklist
After SAP completes the copy and starts the target system, you need to complete these steps:
Adjust logical system names
Use BDLS or SCC4 to update logical system IDs so they match the target. Critical for ALE/IDoc.
Reconfigure RFC destinations
SM59 - update all RFC connections to point to correct targets (don't leave pointing to prod!).
Reset email and output management
SCOT, SOST, SPAD - ensure emails don't go to real customers and printers point to test devices.
Disable/adjust batch jobs
SM36/SM37 - disable jobs that shouldn't run in target (e.g., production interfaces, real payments).
Test critical transactions
Smoke test: login, run key transactions, check interfaces, verify batch job execution.
Unlock users (selectively)
Don't unlock everyone at once. Start with testers, then roll out access based on testing progress.
Document and communicate
Send completion notice to stakeholders with data cut-off time, known issues, and next refresh date.
Automation Opportunities
Many of these manual steps can be scripted or semi-automated:
Quick Wins
- • User mass-lock/unlock scripts (SU01 batch input)
- • Batch job hold/release via SM37 job selection
- • RFC destination update scripts (table-level changes)
- • Email suppression via SCOT config script
Advanced Automation
- • Full runbook automation (Redwood, Control-M, custom)
- • Pre/post-copy testing with automated smoke tests
- • Configuration comparison and drift detection
- • Integrated service catalog requests
Common Pitfalls
- Forgetting to disable prod interfaces - QA system sends real EDI transactions to vendors
- Not updating logical system names - ALE/IDoc distribution breaks
- Unlocking all users immediately - Testers find issues but prod data is already exposed
- Assuming SAP handles post-copy config - System sits broken waiting for SAP, who's waiting for you
- No runbook or documentation - Each copy is reinvented from memory