Production systems are business critical. No wonder, that change management has to comply with certain regulations in order to maintain availability, to meet SLAs, and to transfer results from the “sandbox” to the reality of IT.
In case of SAP it is strongly recommended “that you perform a system copy if you are planning to set up a test system, demo system, or training system. You must also perform a system copy if you want to change your operating system or your database.” Because no one in charge of SAP who takes his or her responsibilities seriously, would ever test a new software tool or a new hardware component within an active production environment—systems with three or more levels are common and system copies therefore a matter of routine today.
Well, if SAP Systemcopy just meant to clone an existing SAP system we wouldn’t talk about it. But to copy a system for backup reasons is one thing, and to system copy a running SAP production environment is another. Actually it’s not even the System Copy itself. It’s more the subsequent configuration changes and the adaption of references, indices, and allocations – pointing in the ‘wrong’ direction – that really sucks. Because this part is manually initiated and sequentially done, and therefore really affects the productivity of your IT department.
Even the baseline checklist of the system copy post actions by Omer Brandis gives you a glance of the related automation challenges. Consider that most versions of a “SAP System Copy” manual run to more than 50 small-printed pages. The good news is, that UC4 customers can automate 60 percent of this workflow and reduce System Copy time from 3 to 5 days to less than a day. And this by using the existing resources.
Find more details in the SAP System Copy Whitepaper