All-in on SAP S/4HANA Migration Cockpit?

Posted on November 2, 2020 by - Architecture, Data Migration

I am not “all-in” on SAP S/4HANA Migration Cockpit.

Analysts warn that 83% of all data migration projects either fail or significantly exceed budgets. Like a poker table full of serious faces in a swanky casino, the stakes in data migration are sky high. Before going all-in on a single bet of such consequence, you’d better consider the big picture.

Yes, I understand that it’s the recommended tool for loading data into SAP S/4HANA, and has been for 5 years. And — for as many years — it’s been touted as the successor to Legacy System Migration Workbench (LSMW), which is no longer considered strategic.  It’s not that SAP S/4HANA Migration Cockpit isn’t usable.  After five years of steady revision, it’s achieved that mark, albeit with constraints.  And it introduces important innovation, such as Direct Transfer, to transfer data directly from an SAP system. That’s all super-good news, but it’s insufficient information.

First of all, it makes no sense to talk about any tool outside the context of data migration process and architecture. More on that in a bit. But with that as context, here’s the short list of why I’m not “all-in” on SAP S/4HANA Migration Cockpit:

  1. Migration Cockpit projects break with system upgrades; content that you create isn’t stable over time or easily reusable.
    • SAP Note 2778320 – SAP Release Comparison for SAP S/4HANA (on premise) Data Migration content.
      • “A change in the template structure requires a transfer of the data into the templates of the new release.“
    • SAP Note 2698032 – Migration Objects Deprecated
    • SAP Note 2988692 – SAP S/4HANA Migration Cockpit – Information about different versions
      • With SAP S/4HANA (on premise) 2021, existing projects in transaction LTMC will be still available in display mode. It will not be possible to create new projects.
  2. Migration Cockpit is meant only for initial creation of data, but not for updating data. That’s a process pain point.
    • SAP Note 2684818 – SAP S/4HANA Migration Cockpit usage for mass processing data or as interface.
    • SAP Note 2650201 – Migration Cockpit: How to create/update data records.
  3. Migration Cockpit may be the successor of, but it isn’t a replacement for LSMW. The gaps are more than niceties.
    • Unlike using IDocs, user-created content is tightly integrated with SAP system versions, making reuse difficult or impossible.
    • No support for delimited files as input; XML templates have problematic limitations and S/4HANA staging tables may add relative complexity.

For those who understand that content development and knowledge sharing are critical to faster, better, and cheaper delivery, the first pain point is excruciating.

Data Migration Solution

I often hear SAP S/4HANA Migration Cockpit described as a “solution” for data migration. It’s discussed without the context of other essential tools or process steps. But neither Migration Cockpit nor LSMW qualify as a solution. If you find yourself in such a conversation, pause. To avoid costly oversimplification and missed expectations, consider the fundamental steps for a data migration scenario:

  1. Analysis
  2. Extract
  3. Transform
  4. Validate
  5. Load
  6. Reconcile

Any data migration solution must address all six steps to warrant the name. If you’re responsible for the outcome then you dare not do less. 

LSMW was clearly positioned to address the Load step. It’s clear where LSMW fits, even though it could do much more when pressed by clever users. On the other hand, Migration Cockpit attempts to span from Transform to Load, but abandons a bevy of LSMW niceties (e.g. content stability, reusability, input file flexibility, simplicity). Covering the scope of data migration steps requires that you look beyond SAP S/4HANA Migration Cockpit — beyond the Load step — for all but the simplest projects.

Data Migration Load Step Options

What’s more, even in SAP S/4HANA 2020, consider that no single tool will enable the Load step for all data migration objects! 

For example, LSMW (more precisely, IDocs or BAPI) remains essential for SAP Retail. For confirmation of necessity, see SAP Note 2538170 – Migration of Retail Objects to SAP S/4HANA on-premise. Even outside of SAP Retail, your S/4HANA data migration architecture not only has to cover the six steps, but has to enable multiple options for the Load step, with a decision to be taken by data migration object.

Load step options include these tools, and you will need more than one:

Finally, the scope of every enterprise-grade data migration project includes writing some code, no matter what the brochure says. Employing SAP S/4HANA Migration Cockpit is no assurance of avoiding that reality. If such code and other data migration content arrives at your project based on previous experience — content development — then that’s value added.

Data Migration Architecture

Given the above, now consider data migration architecture and workflow. It sure would be nice to have a single flow (or fewest) that accommodates all business objects. That desire encompasses functional as well as technical steps, and should work similarly regardless of the technical method chosen for the Load step.

That’s why I believe SAP Data Services (or an equivalent world-class tool) is essential for all but the simplest data migration projects. It’s uniquely capable to cover all six data migration steps, and any of the data migration load options fits into the process.

Classic SAP Rapid Data Migration architecture with SAP Data Services.

The above image from SAP Rapid Data Migration with SAP Data Services (On Premise) uses the modern term “API” as a placeholder to mean any of the technical load methods, including IDoc.

SAP Note 2287723 – LSMW in SAP S4HANA On-Premise edition explains that “SAP S/4HANA customers have access to a basic Data Integrator license key that comes with the underlying SAP HANA license (HANA REAB or HANA Enterprise). This key code applied to SAP Data Services provides full ETL functionalities (Extract, Transform, Load).” SAP Data Services functionality is thus available for this use case at no additional software license cost. But it does require hardware and specially-trained resources.

Whether you’re using SAP Data Services or not, the Transformation step should be centralized, and it doesn’t belong in the Load step. Whether the Load step is performed by Migration Cockpit, LSMW, or some other program, nothing more than simple mapping should be embedded in that step.

Given all of the above, an up-to-date SAP S/4HANA Data Migration Architecture looks significantly more like this:

SAP S/4HANA Data Migration Architecture

If SAP Data Services isn’t part of the landscape then the same functionalities must necessarily be provided by other tools.

LSMW or Data Services and IDoc or BAPI

Given the “short list” from the opening, there are still good reasons that your Data Migration strategy might include some combination of LSMW or Data Services and IDoc or BAPI.

  • IDocs are standard, with very mature supporting tools and processes.
  • Many IDoc / BAPI natively incorporate the ability to create and change data.
  • Data migration content works over time and from project to project.
    • IDocs remain relatively constant; I’m not aware of any deprecation of IDoc.
  • Load-Ready Files (delimited text files) and IDoc fit flexibly into varying data migration landscapes.
    • You might have SAP Data Services or use LSMW, but this approach fits into any architecture.
    • Data migration content that you create has an expectation of stability over time.
  • LSMW (more precisely, IDoc or BAPI) remains essential for SAP Retail Master Data.

Upside and Downside

This document isn’t a screed against SAP S/4HANA Migration Cockpit!  Not being “all in” doesn’t mean “against.”  Rather, the point is eyes-wide-open consideration, especially in the context of creating  data migration content and evaluating how multiple tools fit into your data migration process and architecture.

It’s clear that SAP S/4HANA Migration Cockpit is the recommended tool, now and in the future. Furthermore, SAP S/4HANA Migration Cockpit offers innovation and content that makes it the choice without rival in some scenarios.  For example, if careful analysis of your data migration scenario (and data!) reveals that it can be enabled by Direct Transfer (Transfer Data Directly from SAP System), and if you have no serious data quality and data structure issues, then Direct Transfer is a no-brainer.  What I don’t advocate is assuming that Direct Transfer is the best option absent careful analysis. Your data must drive the architecture and selection of tools, not the opposite.

No matter your choice of tool for the Load step, you need to carefully test that your approach satisfies your requirements, object by object. This is no less true when using SAP S/4HANA Migration Cockpit, and no less true when employing other load methods.

Let’s close where we began, by recalling that 83% of all data migration projects either fail or significantly exceed budgets. The mitigation strategy for avoiding this dismal number is clear:

  1. Engage very-experienced SAP functional experts who understand SAP data requirements and business processes.
  2. Engage experienced SAP technical resources who understand how to put the data away.
  3. Rely on the experience-based advice of these folks to guide your data migration process, architecture, and selection of tools.

The above is particularly true when implementing SAP Retail, because Master Data makes SAP Retail special.

Reference

Notes and Asides