Abstract: Data migration to the SAP S/4HANA Public Cloud is often perceived as a step backward, as modern middleware solutions such as peer-to-peer integrations are not permitted. However, the “S/4HANA Data Migration Cockpit Converter” developed by sapXPerience offers a solution that enables efficient and error-free migration through automated conversion and reusability of data. This allows customers to provide complete, consistent data sets even in GROW with SAP projects and to carry out their tests reliably and in a practical manner.
The approach to data migration to the SAP S/4HANA Public Cloud feels like a step back two decades.
What are the key factors?
It is well known that the correct, complete, and intact migration of data from legacy systems to the new SAP world is one of the key factors for a successful go-live with the new SAP system. I experienced this firsthand after I used data migrations in my projects for the first time, which connected the legacy system (source) and the new SAP system (target) peer-to-peer using middleware. They enabled the application of the essential success principle “load often – load all” and thus an evolutionary approach to ensuring a complete and coherent data set in the target SAP system.
Cleansing and mapping were supported securely and transparently in this middleware, and all data still to be cleaned up in the legacy systems was always fully available (see also my BLOG post 22). Since I first learned about this approach in 2010, I have successfully applied it in all my projects as an essential component for ensuring a go-live that is as “boring” as possible. However, this was not only about productive data migration, but also about providing data loads that were as complete and accurate as possible for integration and acceptance testing – another key factor for successful testing and user confidence in the future system. However, such peer-to-peer solutions require the installation of specific add-ons in the target (SAP S/4HANA), which may still be possible in the S/4HANA private cloud, but is virtually impossible in the S/4HANA public cloud.
The background
Before these middleware-based peer-to-peer solutions, it was common practice to capture the data to be migrated in complex Excel spreadsheets, clean it, validate it across multiple tables using VLOOKUP, and then load it into SAP using LSMW. However, since it was impossible to do this completely and consistently, many SAP implementations suffered greatly from poor, incomplete, and inconsistent data sets at go-live. High-quality, nearly complete pre-loads for integration and acceptance tests were out of the question.
Is this the future?
When I was first confronted with the possibilities available in the S/4HANA public cloud as part of an overall project management role, I felt like I had been transported back to the “Stone Age.” It is now possible to generate and fill corresponding load templates for all data objects in the Data Migration Cockpit (DMC) according to the Scope ID (SI) selection and simulate their load into the target S/4HANA using DMC. However, these XML load templates sometimes have up to 15-20 register sheets that must be filled consistently not only in one file, but across files of several objects, preferably with data extracted from the legacy system. This is purely manual, Sisyphean work and will ultimately not result in an S/4HANA system loaded with completely business-ready data. But that is precisely the standard I set for the projects I manage.
The good news:
We have developed a solution. Although it is not peer-to-peer, it follows the principles of these solutions and enables the application of the successful principle “Load often – Load all”: This solution incorporates, on the one hand, the knowledge gained from years of experience with the possibilities and principles of middleware-based peer-to-peer systems and, on the other hand, profound knowledge of Excel-based development of a suitable solution. This allows the load templates of the Data Migration Cockpit to be filled completely and consistently from the data extracts from the legacy systems without the extracted legacy data having to be processed manually beforehand. This means that the entire process is completely and reliably repeatable and testable, and we achieve a complete and consistent data load for the S/4HANA system using an evolutionary approach.
The following diagram provides an overview of the overall solution, in which the sapXP “S/4HANA Data Migration Cockpit Converter” developed by us plays a central role:
The procedure is as follows:
-
- Extraction of data from various data objects in different legacy systems into any format that can be transferred to Excel. We strongly recommend performing a so-called active record determination (for content and procedure, see BLOG 22) beforehand to avoid transferring unnecessary data garbage to the new system.
- Field mapping, formal cleansing, and transfer of data to the SAP XML load templates generated from the S/4HANA Data Migration Cockpit. This involves:
- Transfer the target fields once from the XML sheets to the “S/4HANA Data Migration Cockpit Converter” as target fields using copy/paste (transposed) (see video tutorial).
- The fields (column headers) of the source files are mapped to the targets; an n(Sources) : 1 (Target) assignment is possible. This is what the mapping looks like:
- Optionally, assign existing routines for formal cleansing of the transferred data to individual mapped fields. These include, for example:
- Separation of the street/house number field into separate fields
- Conversion of numbers with decimal places to the format required in the SAP target field
- Conversion of date fields into the format required in the respective SAP target field
- Conditional assignment of fields not maintained in the legacy system with specified values in individual records
- Entering default values in individual fields depending on the presence of content in other fields
- … and much more (additional features are available on request)
Content mapping (value in the legacy system : value in the SAP system) (purchasing groups, plants, storage locations, posting keys, etc.) was deliberately omitted, as corresponding mapping tables can be created more easily and effectively in the S/4HANA Migration Cockpit according to business specifications (a simple and sensible preparation is to specify these mappings in Excel tables, which are then transferred to the DMC (existing legacy values to be mapped can be easily and completely generated from the legacy extract files and made available to the business for mapping).
Here is an example list of potential mappings:
- Produkt_SERNP_SerialNoProfile
- MEINS_Mengeneinheiten
- LGORT_Lagerorte
- KTGRM_Material
- TAXM1_Material
- Länderkürzel_Kunden_Lief
- EKCODE_EKGRP
- INCOTERMS_Lieferant
- Abstimmkto_Lieferant
- Verk_GRP_Kunde
- INCOTERMS_Kunde
- Versand.Bed_Kunde
- ZTERM_Lieferant
- TAXTYPE_Lieferanten
- ZTERM_Kunden
- TAXTYPE_Kunden
- Kontierungsgruppe Kunde
- Abstimmkto_Kunde
- WAERS_Kunde_LIEF
- SPRAS_Kunde_LIEF
- QM_Prüfart
- Mapping für Bestandsmigraton
- Optionally, you can also make already generated XML load sheets available to the business for data cleansing or data enrichment and then use them as a source for updating newly generated XML load sheets. In some cases, this can be more useful and faster than cleaning up the data in the legacy source—or even if cleanup is not possible there due to ongoing productive operations, but needs to be done consistently.
- The load sheets generated in this way are used to simulate the load in the DMC, and any errors generated in the process are reported back and either corrected by adjusting the mapping and/or cleansing the legacy data (alternatively, see also the aforementioned point 3) and the load sheet is regenerated for a new attempt. It should not be overlooked at this point that the simulation is always performed for the entire data set of an object and thus, in each simulation round, ALL remaining deficits can ALWAYS be revealed and corrected . Since, for example, adjusting the mapping and regenerating the load sheet for a new simulation only takes a few minutes, this results in extremely fast turnaround times with maximum knowledge gain in each case – in other words, “Load often – Load all” enabled😉 .
- If the simulation of a target object has run without errors, the load into the SAP target system can be performed (known as a MOCK load). Of course, the dependencies of the objects in the target system must be taken into account here, rather than first considering the independent objects (customers, suppliers, and products) and then the dependent objects (BOMs, routings, info records, prices, etc.) and their dependencies by defining specific load cycles (for content and procedure, see BLOG 22).
Experience and tips from the current application in a GROW with SAP project (S/4HANA public cloud)
In my current project, we have been using sapXP’s “S/4HANA Data Migration Cockpit Converter” for about a month and have achieved the following status and gained the following experience:
- For the independent objects (customer, supplier, and products (all material types)), we are about to complete the last error-free simulation and will soon be able to start the load.
- Looking at all objects, we have currently reached a stage that will probably allow us to dispense with one of the planned MOCK loads (we had planned three).
- We will almost certainly be able to provide users with a system with nearly complete and consistent master data for the integration test.
- We have all large data sets securely under control – the only size restriction is that caused by the SAP load templates, as these may only have 160 MB in individual cases and therefore large data sets (i.e., with more than approx. 750,000 records) must be split across several load sheets. We do this by splitting the extracted data files using a Python script (which we provide together with sapXP’s “S/4HANA Data Migration Cockpit Converter”).
- The SAP XML load templates for which no extracted data is available must be filled manually. Even if this only affects small data sets, we prefer to fill the XML load sheets rather than entering the data multiple times in the various MOCK loads, so that the entire migration process can be carried out automatically and independently of individual users. This usually only affects a manageable number of data records, such as a few data objects in the QM or compliance environment.
- So far, we have been able to solve all tricky questions in the area of data mapping in a fully automated manner, in particular because the “S/4HANA Data Migration Cockpit Converter” can be applied extremely generically to all possible constellations and always works very stably and consistently. Here is an excerpt of the objects we currently have in the simulation:
Conclusion and recommendation
We are proud and delighted that we were able to develop such a powerful and easy-to-use tool in such a short time, which enables us to safely and reliably complete the mission-critical task of data migration in an S/4HANA public cloud project. In particular, this also provides massive support to key users in the critical integration and acceptance testing tasks that still lie ahead and frees them from otherwise necessary data entry tasks. This means that they can focus on familiarizing themselves with the future SAP S/4HANA system in the context of tests with complete data sets. And experience shows that this is the second mission-critical aspect: that the system can be operated safely by users.
Since the task of data migration in an “SAP Activate” project is, by definition, the responsibility of the customer (see BLOG post 35), I can only urge every customer to use the “S4/HANA Data Migration Cockpit Converter” from sapXPerience GmbH in their project. Use the coupon code INTRO75 to benefit from an introductory discount of 75% in our Digistore24 until September 30, 2025.
To take advantage of our numerous other products in Digistore24 for your GROW with SAP project, use the coupon code GROW25 until September 30, 2025. Here you will find an overview of our digital products.
Here you can see an introduction to the S/4HANA Data Migration Cockpit Converter on YouTube.
You can watch a demo video of the application here on YouTube.