Reducing time required for ABAP-only copyback (system copy) process

Question

Our company is investigating how to reduce the amount of time it takes to perform a copyback (system copy) from a production ABAP system to a QA system.  We use a similar process for all ABAP-only systems in our landscape, ranging from 3.1h systems to ECC6.0 ABAP-only systems on both DB2 and Oracle database platforms, and the process takes approximately two weeks of effort from end-to-end (this includes time required to resolve any issues encountered). 
Here is an overview of the process we use:
u2022     Create and release backup transports of key system tables and IDu2019s (via client copy) in the QA system to be overwritten (including RFC-related tables, partner profile and IDOC setup-related tables,  scheduled background jobs, archiving configuration, etc.).
u2022     Reconfigure the landscape transport route to remove QA system from transport landscape.
u2022                    Create a virtual import queue attached to the development system to capture all transports released from development during the QA downtime.
u2022     Take a backup of the target production database.
u2022     Overwrite the QA destination database with the production copy.
u2022     Localize the database (performed by DBAu2019s).
u2022     Overview of Basis tasks (for smaller systems, this process can be completed in one or two days, but for larger systems, this process takes closer to 5 days because of the BDLS runtime and the time it takes to import larger transport requests and the user ID client copy transports):
o     Import the SAP license.
o     Execute SICK to check the system.
o     Execute BDLS to localize the system.
o     Clear out performance statistics and scheduled background jobs.
o     Import the backup transports.
o     Import the QA client copy of user IDu2019s.
o     Import/reschedule background jobs.
o     Perform any system-specific localization (example: for a CRM system with TREX, delete the old indexes).
u2022     Restore the previous transport route to include the QA system back into the landscape.
u2022     Import all transports released from the development system during the QA system downtime.
Our companyu2019s procedure is similar to the procedure demonstrated in this 2010 TechEd session:
http://www.sapteched.com/10/usa/edu_sessions/session.htm?id=825
Does anyone have experience with a more efficient process that minimizes the downtime of the QA system?
Also, has anyone had a positive experience with the system copy automation tools offered by various companies (e.g., UC4, Tidal)?
Thank you,
Matt

Answer 1

Hi,
> One system that immediately comes to mind has a database size of 2TB.  While we have reduced the copyback time for this system by running multiple BDLS sessions in parallel, that process still takes a long time to complete.  Also, for the same system, importing the client copy transports of user ID's takes about 8 hours (one full workday) to complete.
>
For BDLS run, I agree with Olivier.
> The 2 weeks time also factors in time to resolve any issues that are encountered, such as issues with the database restore/localization process or issues resulting from human error.  An example of human error could be forgetting to request temporary ID's to be created in the production system for use in the QA system after it has been initially restored (our standard production Basis role does not contain all authorizations required for the QA localization effort).
>
For the issues that you encounter because of system copy, you can minimize this time period as you would be doing it on periodic basis (making some task list) and you can make a note of issues that you faced in previous run. So, normally i don't count it as system copy time
Thanks
Sunny