Libelle has been automating SAP system copies and refreshes with Libelle SystemCopy for over a decade, during which time we have seen the pitfalls and complications arising from manually executed refreshes. We’ve collected the top ten biggest potential issues and failures from manual refreshes below.
Production (PRD) settings in non-production systems (e.g. QAS) are the biggest issue resulting from manual refresh execution. Immediately after a refresh, QAS is populated with PRD settings; part of the refresh is to ‘fix’ those settings to point to QAS instead of PRD. Settings include (but are not limited to) RFC settings – this can result in QAS making production connections and issuing orders to your suppliers via partner systems, or emails being sent to customers incorrectly.
Refreshes are scheduled for a certain time frame, often months in advance. Manual processes and unexpected issues can delay the process, and BDLS may take longer than expected if it runs manually. Every minute counts - automated refreshes can’t avoid everything, but with 90% of the refresh workflow automated, risky weak spots are drastically reduced.
Basis administrators are overworked, double-booked, and triple-tasked. With refreshes stretching across multiple days or even weeks, attention is prone to distraction and division. Basis admins may run multiple terminals to various systems during a refresh, including connections to production investigating other projects and tasks. A QAS refresh requires bouncing SAP and dropping databases, which can easily result in the wrong server or database being bounced with catastrophic consequences.
PRD users and PRD roles are different than those of QAS. Part of the refresh is to re-assign QAS roles after the refresh. A manual process is tedious, and a simple mistake can give the wrong user too much access, risking data breaches.
During a manual refresh process there is a chance that all transports which were imported in QAS before the refresh are not re-imported correctly. If they are completely imported, they are often not imported in the right sequence, causing problems up to a point where QAS may not be usable and the refresh must be re-performed from scratch.
A common mistake in a manual refresh is the release of production batch jobs on QAS. This often creates major escalations and simultaneously creates a resource crunch on target systems, since target systems are not resourced as completely as the production system.
During the refresh of a development system, development projects that are not closed or moved via transports can be overlooked, wiping out version histories.
Programs often get program paths to the file system via parameters and the parameters are maintained in variants. In the case of a system copy, variants on QAS originate from production and must be fixed. If this is not done correctly, programs still point to production and, once triggered in QAS, can read and/or write data from/on production systems.
A smaller annoyance, but an issue that can cause confusion and delay, printer settings on QAS come coming from production. QAS then sends print jobs to production printers causing small, but equally irritating headaches.
During a manual system refresh, everyone involved is fully consumed in the process. After an often delayed and stressful delivery of the systems, who would want to revisit the process? The big picture is overlooked. How long does the refresh take? Why is taking so long? Where can we optimize? An automated process opens a simple runtime analysis. We recently identified how RDDSTAT* tables were responsible for 80% of the BDLS runtime on a system as they were not maintained.
Libelle AG provides you with a solution for Automating system copies, the alternative to manual system copying. Learn more about our solutions and get the free whitepaper.