Be the first to receive news about our products. Subscribe to our newsletter!
Server room with icon of a faulty system copy in the foreground

Top 10 mistakes with manual SAP® system copies

Author

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.

1. Non-Production Systems Connecting to Production After Refresh

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.

2. Getting Off Schedule

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.

3. Bouncing the Wrong Server or Dropping the Wrong Database

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.

4. Incorrectly Altering Security Authorization Creates Security Holes

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.

5. Missing Transports, Importing Transports in Wrong Order

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.

6. Release Production Batch Jobs on QAS

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.

7. Deleting Development Projects and Version History

During the refresh of a development system, development projects that are not closed or moved via transports can be overlooked, wiping out version histories.

8. Program Paths in Job Variants Pointing to Production

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.

9. QAS Sending Data to Production Printer

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.

10. Lack of “Big Picture” Vision

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.

Libelle DataMasking advertisement
View all articles