S/4HANA migration: step by step
You have decided to transform your current ERP system to S/4HANA? Then you probably know that preparing the master and transaction data available in the ERP system is a central and mostly underestimated task in the run-up to a system transformation.
In addition, the approach chosen for the transformation - brownfield or greenfield - plays an essential role.
In the brownfield approach, the existing system is upgraded and the data is migrated (converted) "in place".
In contrast, in the greenfield approach, the system is completely rebuilt and set up. The data from the old ERP system is migrated to the new S/4HANA.
In both cases, a quality check and cleanup of the existing data is required in advance of the transformation. This includes the deletion or deletion flagging of data that is no longer required and the correction of incorrect data that is still required.
The greenfield approach is often accompanied by process redesign. The associated changes in customizing result in extensive mapping tasks when migrating the data. This has an impact on the time sequence of the transformation steps. Migration is therefore only possible after the processes have been set up.
Procedure and tools for data migration to S/4HANA in the greenfield approach
A successful migration requires a clear strategy. After a detailed analysis of all components and the planning of all tasks, a concrete approach is developed.
The initial focus is on qualifying the data for migration. During the verification of the data and the associated correction or deletion, your process owners are supported by our team of consultants.
With the greenfield approach, initial migration test runs can usually only take place after the processes have been set up and the associated customizing has been completed.
In special cases, intermediate steps based on standard processes/customizing and migration test runs based on these can be useful.
The effort involved in data migration is influenced by the following factors:
- Scope of the migration objects (material master, bills of material, FI documents, etc.)
- Number of object instances (e.g. number of material masters)
- Complexity of the migration objects (e.g. number of material types in the material master)
- Extensions to migration objects (e.g. Z-Appends)
- Extent of self-developed migration objects (e.g. Z-tables)
- Extent of changes in customizing between old ERP and new S/4 HANA
Migration: step by step
The data migration process takes place in four steps per migration object.
In the first step, the data is selected from the legacy system. Mapping tasks are created for relevant data fields in order to convert values from the old system into other values for the new system. In this way, changes between the old and new customizing can be mapped.
In the second step, the resulting mapping tasks are to be processed. In this process, the old values are to be assigned to the corresponding new values.
In the third step, the creation of the selected and converted data in the new system can be simulated. In this way, causes of errors can be identified and eliminated in advance of the migration.
In the fourth step, the migration takes place with the transfer of the selected, converted and successfully simulated data.
The migration process must take into account the dependencies between the migration objects. For example, material masters must be migrated before the BOMs, since they are part of the BOMs.
The entire migration process is carried out using the "Migration Cockpit" and "Migration Object Modeler" tools provided by SAP for this purpose.
The "Migration Cockpit" guides you through the four steps of the migration process described above, and the "Migration Object Modeler" allows you to adapt selection criteria and mappings, as well as to create customer-specific migration objects.
In the course of a system transformation, data migration is performed at least twice. The first test migration is usually followed by an integration test in the new system. If necessary, further test migrations are required to check the effectiveness of corrections made and to optimize processes with regard to the final migration.
