SAP System Refresh Checklist: Save, Restore, Reconnect

Decision context

A system refresh overwrites the target with a copy of production, which is the point, and also overwrites everything that made the target a non-production system, which is the problem. The checklist is really a list of things that are target-specific and would otherwise be lost.

The order that works is: export the target-specific settings, refresh, then restore them and convert the things that still believe they are production. The conversions matter most, because a refreshed system that still holds production logical system names or production RFC destinations can reach production.

The second consideration is data protection. A non-production system now holds production data, and the obligations that applied to it in production apply here too, with a smaller set of controls around it.

Export from the target before the refresh

These are the settings that belong to the target and would be replaced by production's versions. Export them as table extracts or documented screenshots, and keep them somewhere outside the system being refreshed.

• RFC destinations and their attributes, including which ones hold credentials that will have to be re-entered rather than restored.
• TMS configuration and the transport routes, plus the current import queue state so you know what had been imported.
• Logical system names and their client assignments, which are the settings BDLS will convert afterwards.
• Output devices, spool servers, and access methods.
• Background job definitions, their variants, and the schedule, so nothing restarts unexpectedly.
• Operation modes and instance-specific profile parameters.
• ALE and IDoc configuration: partner profiles, ports, and the distribution model.
• Certificates and the trust configuration, since these are frequently environment-specific.
• Licence keys for the target's hardware key.
• User master data if users are not being taken from production, along with the role assignments.
• Any connection registration to a central monitoring or ALM system.

After the refresh, before anyone logs in

The system currently believes it is production. These steps are what stop it from behaving that way, and several of them are the reason a refresh is done under a lock.

• Install the licence for the target's hardware key.
• Run the post-installation actions for a system copy, so the system change option and the internal settings match a copied system rather than the original.
• Reconfigure TMS and re-establish the transport routes for the target, and keep the system locked against imports until the rest is done.
• Run BDLS to convert the logical system names from the production names to the target names. Until this completes, ALE and IDoc configuration points at production.
• Restore and correct RFC destinations, and re-enter every credential rather than assuming a restored destination still authenticates.
• Delete or reschedule background jobs, then restore the target's own schedule and re-establish the standard housekeeping jobs.
• Restore printers, output devices, and spool configuration, and clear inherited spool requests.
• Restore or rebuild users, roles, and authorizations, and reset passwords for anything copied from production.
• Check the certificate and trust configuration and replace anything production-specific.
• Run the installation consistency check and a generation run to reduce first-use compilation time.
• Clear inherited application data that must not run in a test system: pending output, outbound communication, scheduled workflow, and anything that could send a message to a real customer.

Data protection and the parts people forget

The refreshed system holds production data. Whatever obligations attach to that data attach here, and the controls in a test system are usually weaker than in production.

• Decide before the refresh whether personal or regulated data has to be scrambled or reduced, and who approves that decision.
• Disable or redirect outbound email, fax, and messaging before the first login, because production customer addresses came across with the data.
• Review who has access. A test system usually grants wider authorizations than production, and it now contains production data.
• Record the refresh date and the production point in time it represents. Testers need to know how old the data is.
• Re-import the transports that were in the target's queue but not yet in production, or the refreshed system silently loses in-flight changes.

What the workflow must cover

• Queue state preservation. Record which transports the target held before the refresh so in-flight changes are re-imported rather than silently lost.
• Change reconciliation. Compare the object versions in the refreshed target against the released requests, so the team knows exactly what the refresh reverted.
• Evidence continuity. Keep validation results tied to their package identity, so results obtained before a refresh are not read as valid afterwards.
• Access review. Surface which roles and users exist in a system that now holds production data.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Agree the refresh window, the production point in time, and the data protection decision.
2. Export the target-specific configuration and record the import queue state.
3. Refresh, keeping the system locked against imports and logins.
4. Restore configuration, run the logical system conversion, and reset credentials.
5. Re-import in-flight transports, run the consistency checks, then release the system.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Pre-refresh configuration export
• Import queue state
• Production point in time
• Data protection decision and approver
• Logical system conversion result
• Restored RFC and credential list
• Job schedule after restore
• Re-imported transport list

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A refresh reverts the target to production content. Anything tested but not yet in production has to be re-imported, and this is the step most often missed.
• Credentials in RFC destinations generally have to be re-entered rather than restored.
• Data scrambling scope and approval are customer decisions driven by regulation and contract, not by tooling.

Buyer checklist

• Was the import queue state recorded before the refresh?
• Has the logical system conversion completed for every client?
• Is outbound communication disabled before the first login?
• Which credentials were re-entered rather than restored?
• Which in-flight transports have to be re-imported?