The challenges following an SAP® System Copy

System copies are a common means of ensuring that the quality assurance (QA) system does not differ to much from production system regarding test data.
To achieve this production system is normally copied over to the quality assurance system.
However, there is more to a successful system copy than the actual copying and making the necessary adjustments to the database (changing the system ID, anonymisation of data etc.). It also requires that all the changes that were only integrated in the QA system and not in the production system, and were therefore lost, are reimported.
At first sight, this appears to be very simple. Everything that is in the QA system but not in the production system must be reimported.
Upon further consideration, it becomes clear that this kind of simplification can not only make future activities more difficult and reduce test quality, it can even lead to the creation of a non-functional QA system.
The two main factors in this regard are developments that are rejected after test, and the infamous overtakers.
To be precise, it is just as easy to import too much as too little.
Reimporting everything regardless, even transports which do not belong in production, would count as too much. Failing to take overtakers into account, however, is too little. Thus, an overtaking hotfix, for example, which is already productive, would not be found with a simplified approach and would therefore be lost.
In the end, all that would remain would be an overloaded and nevertheless broken quality assurance system.
Manually managing these challenges in the context of hundreds or even thousands of transport requests is, even with a great deal of effort, virtually impossible.
A solution such as Conigma QCopy offers fully automated management of the challenges described here and many others.System copies are a common means of ensuring that the quality assurance (QA) system does not differ to much from production system regarding test data.
To achieve this production system is normally copied over to the quality assurance system.
However, there is more to a successful system copy than the actual copying and making the necessary adjustments to the database (changing the system ID, anonymisation of data etc.). It also requires that all the changes that were only integrated in the QA system and not in the production system, and were therefore lost, are reimported.
At first sight, this appears to be very simple. Everything that is in the QA system but not in the production system must be reimported.
Upon further consideration, it becomes clear that this kind of simplification can not only make future activities more difficult and reduce test quality, it can even lead to the creation of a non-functional QA system.
The two main factors in this regard are developments that are rejected after test, and the infamous overtakers.
To be precise, it is just as easy to import too much as too little.
Reimporting everything regardless, even transports which do not belong in production, would count as too much. Failing to take overtakers into account, however, is too little. Thus, an overtaking hotfix, for example, which is already productive, would not be found with a simplified approach and would therefore be lost.
In the end, all that would remain would be an overloaded and nevertheless broken quality assurance system.
Manually managing these challenges in the context of hundreds or even thousands of transport requests is, even with a great deal of effort, virtually impossible.
A solution such as Conigma QCopy offers fully automated management of the challenges described here and many others.