In the SAP® lifecycle it is always necessary to set up a test or sandbox system. This can be necessary for performance, update, and validation tests, but also for other requirements like a system migration, be it to a newer hardware, to another server center, or to the cloud.
The existing non-production staging systems such as quality assurance (QA), testing, training, and development systems of the regular lines are not always suitable or intended to be used for major changes such as comprehensive projects or complex software upgrades. In these cases, organizations prefer to utilize sandbox systems that can be arbitrarily modified and, in case of doubt, logically destroyed without impacting the regular line.
The benefit of these project and game systems increases with their availability, even in the short term, as well as their ability to map the logical properties of the regular line. With a focus on the latter point, system clones, i.e. complete images, of the systems of the regular lines are usually built rather than empty standard systems for the provision of these systems.
Depending on the architecture, complexity, and size of the SAP landscape, this can be a very extensive task, usually involving a large number of manual activities that can last from hours to days. If, in addition, environments of several connected systems are involved, these times in the context of a landscape clone also tend to add up to a real workload for the executing organizational units, for which there is never "the right" time. System and landscape clones block important and, not least, expensive resources: internal or external SAP Basis professionals.
This choice depends heavily on the requirements. If the goal is to create a system that is as standardized as possible, then the decision will probably go to a new installation from scratch.
However, as SAP® systems are adapted in daily use and thus deviate further and further from the standard, this is not always suitable. These deviations or "dirt" may in fact be relevant for other test requirements. A performance test on a "clean" freshly set up system cannot be compared to a used system with all its vast amounts of data and the exact distribution or structure of the data.
The same applies to update or validation tests. The parameters or programs that have been adjusted in use can prevent a simple update, and that is exactly what such an update test is about: to find a clean update procedure, in order to bring up this exact existing system with as short a downtime as possible on new SW conditions.
The effort required to set up the systems also plays a role in the considerations. Automation can take a lot of pressure off the people doing the work and also makes the setup easy to repeat.
The installations can usually be automated via parameter files. Nevertheless, the installation must be run through here and this is usually more time-consuming than duplicating an existing system, i.e. cloning. What do you have to consider?
It becomes apparent that a number of questions need to be clarified in advance, and the path for optimal implementation must then be defined on the basis of the requirements. Libelle IT Group can support you here as an expert with 27 years of experience, as well as providing tools to realize this most optimal implementation.