Is a single migration tool the long awaited solution for the new SAP S/4 HANA implementation?
Which migration tool? So many to choose from!
As long as there are SAP systems in existence, the question of data migration will remain a core issue in virtually all SAP implementation projects. Unless you’re starting out with an entirely green field and leaving all of your existing data behind. All of the different development phases of the SAP system platforms have seen an endless array of individual functional tools and techniques for data migration. Over the course of product developments in SAP ERP, the Legacy System Migration Workbench has become established as a tool for data migration. And for good reason, because the LSMW is able to cover a wide range of objects for migration, while also offering optional methods and technologies in addition. Not only that, it also offers space for the utilization of specially developed ABAP coding for complex auxiliary queries, conversion routines, calculation formulas, and error log outputs; in short, it offers a flexibility for development that is the envy of many other tools.
This blog will consider and take a closer look at a few of the questions around the SAP recommendations for selecting tools for data migration that project managers, sub-project managers, consultants and key users are likely to face at the beginning of an SAP S/4 HANA On Premise implementation project.
Why is a valuable tool no longer recommended in S/4 HANA?
It appears to be a case of preemptive self-preservation on the part of SAP. First of all, it’s a way for them to get around the flood of high ticket statistics and support inquiries for the LSMW, as well as the BAPIs and technologies being used, that will likely arise from the expiration of support for the SAP ERP. Secondly, it’s a way to chart new paths. A technology transfer of the LSMW with all the functions of the SAP GUI to the promising GUI platforms (UI5, Fiori) does not appear to be possible. For that reason, a new approach on a new platform makes sense.
What can the SAP Migration Cockpit do?
The SAP Migration Cockpit can migrate to an S/4 HANA system in three different ways. Via File Transfer, which involves some risks and pitfalls in filling due to the mandatory use of XML templates. Via Staging Tables, which implies that a tool must be used to fill the generated staging tables. And finally, via Direct Transfer, which again can only be used in the migration of SAP systems and brings with it a number of additional costs related to the persistent transfer of OSS notes. In all three approaches, the flexibility and the ability to intervene are still rather limited and very complex. The feasibility of the different scenarios must reflect the relevant project constellation, the data quality in the source systems, the project requirements for the data migration and if necessary the relevant validation requirements.
Disadvantages – What are the limitations of the SAP Migration Cockpit?
The SAP Migration Cockpit can create data with the provided migration objects and in some cases can expand it. However, it cannot change data that has been created. The BAPIs used are generally able to process data changes, but in the past anyone who dares to attempt the reconstruction of a copy in the LTMOM transaction has found themselves confronted with a massive task that is in no way comparable to writing your own ABAP report or to a LSMW. Because in any project in data migration the flexibility to make subsequent data modifications is highly valued, the selection of an individual migration tool for all requirements is quickly rendered moot. Equally difficult is the task of developing your own migration object from scratch. Here the example of SAP with a flat, time-honored S_FLIGHT structure, like we used to see in the introductory courses for ABAP programming in days of old, seem tame by comparison. It’s for goods reason that the SAP Development HUB in charge needs several months to bring a new object of moderate complexity up to the level of BETA testing maturity for the Migration Cockpit.
An additional matter is the very poor and non-adaptable logging of the completed data imports. In view of the spare display of statistics (processed, with errors), a custom load log creation via the corresponding data tables is unavoidable in order to document what the data import has achieved.
It should also be noted that for all of the individual process flow steps the “Validation” step can be misinterpreted. It in no way has to do with a data validation, or, to be more accurate, “data verification”, as required in a validation process. It strictly has to do with a purely technical plausibility check for correct data formats and for correctly linked data ranges between different tabs in a loading file or differing staging tables. In this process step, provided there is syntactic correctness, the subsequent mapping tasks are prepared technically. The topic of validation or data verification is not covered in the Migration Cockpit at all and must be appropriately drafted, defined and coordinated in parallel with the project guidelines and requirements.
Can the LSMW be used in S/4 HANA?
You can still use the LSMW. The BAPIs, objects and methods that have used the LSMW in the past have not been eliminated. There are technical limits in the methodology of recording transactions. It’s required for phased out transactions, but with pure FIORI applications it’s not possible at all. As a tool for the data migration, the LSMW remains a very useful companion in order to cover all areas, tasks, objects and adaptation requirements. Anyone who uses the LSMW and has learned to work with it should consider the flexibility of the tool before expending too much effort in weighing adaptations or in-house development of migration objects in the SAP Migration Cockpit. Quick solutions are often needed in data migration and later in the support service, which still allows the use of an LSMW to be considered. Don’t forget that the LSMW is still among the things that are delivered in the SAP installation.
Why has the SAP Migration Cockpit had different interfaces since release 1909?
The SAP Migration Cockpit for the File Transfer and for the Staging Table Transfer is maintained and run on the Web Dynpro. Since Release 1909 the SAP S/4HANA Migration Cockpit has offered the option to migrate data directly from an SAP system into the SAP S/4HANA system (“direct transfer approach”). But the direct transfer must now be called through a FIORI tile.
As a result, there are now two entirely different appearances within one planned central solution for data migration. The path to the FIORI tile does not appear illogical and use of the direct transfer can be adapted just as quickly as the SAP Migration Cockpit via Web Dynpro. The direction for all three available scenarios clearly goes in the direction FIORI tile, which has been announced in SAP publications for the future releases.
What is the future of SAP Migration Cockpit?
The SAP outlook for the 2021 release versions envisions the final transition of the Web Dynpro based scenarios to the tile world. At the same time, projects should also be linked to the transport system, meaning that in the future projects in the Migration Cockpit will be assigned to the transport order on the development system. Technical changes and adaptations to the objects sin the transaction LTMOM must then be performed and transported in the development system. This doesn’t necessary make handling adaptations easier, but it is more sustainable in design and you no longer have to open a Q-system or production system if you need to make changes on a client-specific basis.
Summary – SAP-Migration Cockpit versus LSMW
Overall, a data migration subproject should not be required from the outset to use a single tool for the data migration. The key thing is to make the most reliable and effective selection in each particular case. The foundation for a successful migration is a very good documentation concept which is followed consistently, thoroughly and in a disciplined way for each object. Of particular interest are the capabilities for integrating ABAP coding into the migration objects of the SAP Migration Cockpit and to edit them for error handling according to the current methods through debugging. This could mean a breakthrough in the use of the Migration Cockpit to the extent that it is enabled not only in the area of mapping, but also in the selection area and in the data import processing. There is also the prospect in future releases of receiving migration objects for updates of master data objects. For the time being, the LSMW can play an important role as an auxiliary tool on the way towards a successful migration.
