Job logic instead of customizing
Hybrid: for example, the source systems on-premises and the target systems on cloud
The guideline that integrated job logic is preferable to customizing has also proven its worth. The key point here is that each step of a copy job knows the overall context, including the steps that preceded and follow it.
In practice, customers have either built their own tools to make the appropriate configurations, or there are extensive lists of steps to be processed manually. This approach is time-consuming and error-prone.
SAP system startup and shutdown, including virtual hosts
In order to be able to work with the most up-to-date data possible on the development and quality assurance systems, it is necessary to bring an up-to-date production status onto these systems. This is often done via a complete system copy (production system -> development system, production system -> quality assurance system) and is very error-prone and user-intensive in ad-hoc configuration (especially if each developer/customizing user is responsible for saving the transports and importing them again after the copy). Every SAP system copy then carries the risk of losing the development status achieved and can lead to inconsistencies in programs and customizing, and any damage repair is usually very time-consuming.
The term "system copy" describes the process of creating a copy of an SAP system on a new server. There are two types to be distinguished: homogeneous and heterogeneous system copy and one can get to the system copy in different ways.
With "Shortcut for SAP Systems", tasks in the area of SAP system copying are simplified and can also be automated via the command line interface.
S/4HANA migration: The migration to S/4HANA is always done via an SAP system copy, if one does not start anew on a "greenfield".
One of the most common methods of creating an SAP system copy is to use SAP's own tool "BR*Tools".