Refreshing an S/4HANA QA or dev system from Production is routine work, but the post-refresh list runs longer than it did on classic ECC — embedded analytics, Fiori, and logical-system-sensitive configuration all need their own pass.
Before you start: the pre-refresh checklist
- Freeze transports into the target system for the duration of the refresh.
- Record every RFC destination and logical system name currently configured on the target — you'll need to restore some of these after the DB copy overwrites them.
- Export any client-specific configuration you don't want silently replaced by Production's values.
- Confirm the backup/restore or snapshot window with the DBA/HANA team and the business calendar — not just the technical window.
Two ways to move the data
HANA backup and restore: take a data backup from source, restore it to target. Straightforward, works across any infrastructure, but slower on large databases. Storage or array snapshot: a DBA/storage-team-driven copy at the disk layer, far faster for large systems, but it needs infrastructure support for snapshotting and cloning to already exist. Pick based on your downtime budget, not habit.
Core Basis steps
- Stop SAP on the target and take a backup of the target first, in case anything requires a rollback.
- Restore or snapshot the HANA database from source onto the target.
- Run post-processing:
BDLSto rename the logical system,SCC4to correct client settings,SM59to repoint RFC destinations away from production endpoints, and clear the number range buffer. - Reschedule or re-trigger background jobs lost in the refresh — see our background job troubleshooting guide if any come back cancelled instead of simply missing.
- Reapply the license key with
SLICENSE— a full database-level copy wipes the one the target had. - Reset
<sid>admand database user passwords to target-specific values. Never leave production credentials live in a lower system after a refresh.
S/4HANA-specific extras
- Refresh the Fiori Launchpad and ICF service cache — stale service registrations are a common cause of tiles failing to load right after a refresh.
- Re-check client-dependent authorizations on embedded analytics CDS views; these don't always carry over cleanly from a BDLS rename.
- Update the refreshed system's registration in Solution Manager / your landscape tool so monitoring and EWA reports point at the right SID again.
The most expensive mistake to get wrong
Outbound interfaces firing against production endpoints because RFC destinations weren't repointed before the system came back up. This is the single costliest post-refresh mistake — a test message, an EDI document, or a payment run can leave the lower system and land in a live production process. Repoint and lock down outbound RFCs and interfaces before starting SAP on the target, not after.
FAQ
What is BDLS used for after an SAP system refresh?
BDLS renames the logical system in a client after a refresh or copy, so documents and interfaces reference the correct (target) system instead of still pointing at the source system's identity.
Why does my SAP system try to send data to production after a refresh?
Because RFC destinations and interfaces copied over from production still point at live production endpoints. Repoint SM59 destinations and disable or redirect outbound interfaces before starting the system on the target.
Do I need a new license key after an SAP system copy?
Yes — a full database-level copy or restore invalidates the target's existing license, since the license is tied to the system's hardware key. Reapply it through SLICENSE after the copy.






