Ist ein einziges Migrationstool die versprochene Lösung in der SAP S/4 HANA Neuimplementierung?
Welches Migrationstool? Die Qual der (Aus-)Wahl!
Solange es SAP-Systeme gibt, ist die Datenmigration nahezu in allen SAP Einführungsprojekten ein Kernthema. Es sei denn, man begänne auf einer völlig grünen Wiese und lässt alle vorherigen Daten hinter sich. Durch die verschiedenen Entwicklungsstufen der SAP-System-Plattformen sind immer wieder einzelne funktionale Tools und Techniken für die Datenmigration entwickelt worden. Die Legacy System Migration Workbench hat sich im Laufe der Entwicklungen im SAP ERP als Tool für die Datenmigration etabliert. Zurecht, weil die LSMW einen weitreichenden Bereich an zu migrierenden Objekten abdecken kann und dabei auch noch optionale Methoden und Techniken bietet. Und darüber hinaus auch den Raum bietet, über spezifisch erstelltes ABAP Coding komplexe Hilfsabfragen, Konvertierungsroutinen, Rechenformeln, Fehlerprotokollausgaben, eine Flexibilität zu entwerfen, von dem manch anderes Tool gerne etwas hätte.
Dieser Blog soll einige Fragen aufgreifen und behandeln, die sich Projektleiter, Teilprojektleiter, Berater und Key User zu Beginn eines SAP S/4 HANA On Premise Einführungs-Projektes in Bezug auf die SAP – Empfehlungen zum Thema Tool-Auswahl für die Datenmigration stellen.
Warum wird ein wertvolles Tool jetzt in S/4 HANA nicht mehr empfohlen?
Dies erscheint ein vorrausschauender Selbstschutz der SAP zu sein.
Erstens, um die wahrscheinlich sehr hohen Ticket-Statistiken und Support-Anfragen bezogen auf die LSMW und die verwendeten BAPI’s und Techniken hinter sich zu lassen, einhergehend mit dem auslaufenden Support des SAP ERP.
Zweitens, um neu Wege gehen zu können. Ein Technologie-Transfer der LSMW mit allen Funktionen der SAP GUI auf die zukunftsträchtigen GUI Plattformen (UI5, Fiori) erscheint nicht möglich.
Daher bietet sich ein neuer Ansatz auf einer neuen Plattform an.
Was kann das SAP Migration Cockpit?
Das SAP Migration Cockpit kann auf drei unterschiedlichen Wegen Daten in ein S/4 HANA System migrieren. Per File Transfer, was aufgrund der zwingend zu verwenden XML-Templates mit einigen Risiken und Fallstricken bei der Befüllung einhergeht. Per Staging Tables, was wiederum impliziert, dass ein Werkzeug zur Befüllung der generierten Staging Tables verwendet werden muss. Und zu guter Letzt per Direkttransfer, was wiederum nur in der Migration von SAP Systemen eingesetzt werden kann und einige zusätzliche Aufwände im ständigen Nachziehen von OSS Hinweisen zu berücksichtigen hat. In allen drei Ansätzen ist die Flexibilität und Eingriffsmöglichkeit derzeit noch sehr begrenzt und sehr aufwändig. Die Einsetzbarkeit der verschiedenen Szenarien muss an der jeweiligen Projektkonstellation, der Datenqualität in den Quellsystemen, den Projektanforderungen an die Datenmigration und gegebenenfalls an zu berücksichtigenden Validierungsanforderungen orientiert werden.
Nachteile – Was kann das SAP Migration Cockpit nicht?
Das SAP Migration Cockpit kann mit den ausgelieferten Migrationsobjekten Daten anlegen und in einigen Fällen erweitern. Es kann angelegte Daten jedoch nicht ändern. Die verwendeten BAPI’s sind grundsätzlich in der Lage, Datenänderungen zu verarbeiten, aber wer den schwierigen Weg antritt, eine Kopie in der Transaktion LTMOM umzubauen, stößt bisher auf eine Mammutaufgabe, die in keinem Verhältnis zu einem selbst geschriebenen ABAP Report oder einer LSMW steht. Da in jedem Projekt in der Datenmigration die Flexibilität zu nachträglichen Datenanpassungen gefragt ist, ist die Wahl eines einzigen Migrationstools für alle Anforderungen schnell durchkreuzt. Ebenso schwierig ist die Aufgabe, selbst ein Migrationsobjekt komplett neu zu entwickeln. Da erscheint das Beispiel der SAP mit einer flachen altehrwürdigen S_FLIGHT Struktur, wie zu Urzeiten der Einführungskurse in die ABAP Programmierung, eher schmalspurig. Der zuständige SAP Development HUB benötigt nicht ohne Grund einige Monate, um eine neues Objekt mittlerer Komplexität für das Migration Cockpit zur BETA-Testreife zu bringen.
Ein weiterer Punkt ist die sehr dürftige und nicht anpassbare Protokollierung der durchgeführten Datenimporte. Eine eigene Ladeprotokollerstellung über die entsprechenden Datentabellen ist gemessen an der spartanisch angezeigten Statistik (verarbeitet, fehlerhaft) unausweichlich, um zu dokumentieren, was der Datenimport erreicht hat.
Zu den einzelnen Prozessablaufschritten ist noch anzumerken, dass der Schritt „Validierung“ missverständlich interpretiert werden kann. Es handelt sich mitnichten um eine Datenvalidierung oder besser formuliert „Datenverifikation“, wie sie in einem Validierungsprozess erforderlich ist.
Es handelt sich lediglich um eine rein technische Plausibilitätsprüfung auf korrekte Datenformate und auf korrekt verlinkte Datenbereiche zwischen verschiedenen Reitern eines Ladefiles bzw. verschiedenen Staging Tabellen. In diesem Prozessschritt werden, sofern syntaktische Korrektheit besteht, die anschließenden Mapping-Aufgaben technisch aufbereitet. Das Thema Validierung bzw. Datenverifikation wird im Migration Cockpit in keinerlei Weise abgebildet und muss den Projekt-Richtlinien und Anforderungen entsprechend parallel für die Datenmigration entworfen, definiert und abgestimmt werden.
Lesen Sie mehr zur Einführung des SAP Migratin Cockpit und zum Direct Transfer Approach.
Kann die SAP LSMW in S/4 HANA verwendet werden?
Man kann die LSMW weiterhin verwenden. Die BAPI’s, Objekte und Methoden, welche die LSMW bisher benutzt hat, sind nicht abgeschafft worden.
Technische Grenzen bestehen in der Methodik des Aufzeichnens von Transaktionen. Bei entfallenden Transaktionen zwangsläufig, bei reinen FIORI Applikationen ist es gar nicht möglich.
Als Tool für die Datenmigration ist die LSMW weiterhin ein sehr sinnvoller Begleiter, um alle Bereiche, Aufgaben, Objekte und Anpassungsanforderungen abdecken zu können. Wer die LSMW verwendet und damit umzugehen gelernt hat, sollte die Flexibilität des Werkzeugs immer mit betrachten, bevor zu viel Aufwand in Anpassungen oder Eigenentwicklungen von Migrationsobjekten im SAP Migration Cockpit erwogen wird. Oftmals sind schnelle Lösungen in der Datenmigration und später im Support Service gefragt, welche immer noch die Verwendung einer LSMW in Betracht kommen lässt. Nicht zu vergessen, dass die LSMW immer noch zu dem gehört, was bei der SAP Installation mit ausgeliefert wird.
Wieso hat das SAP Migration Cockpit nun seit Release 1909 unterschiedliche Oberflächen?
Das SAP Migration Cockpit für den File Transfer und für den Staging Table Transfer wird auf einem Web Dynpro gepflegt und ausgeführt.
Seit Release 1909 bietet das SAP S/4HANA Migration Cockpit die Möglichkeit Daten direkt aus einem SAP System in das SAP S/4HANA System zu migrieren („Direct Transfer Approach“). Der Direct Transfer ist nun allerdings über eine FIORI Kachel aufzurufen.
Damit gibt es nun auch noch innerhalb einer geplanten zentralen Lösung zur Datenmigration, zwei völlig unterschiedliche Erscheinungsbilder. Der Weg hin zur FIORI Kachel erscheint nicht unlogisch und die Bedienung des Direct Transfers lässt sich ebenso schnell aneignen wie das SAP Migration Cockpit über Web Dynpro.
Die Richtung geht für alle drei verfügbaren Szenarien eindeutig in Richtung FIORI Kachel, was sich in den SAP Publikationen für die zukünftigen Releases ankündigt.
Quo Vadis SAP Migration Cockpit?
Der Ausblick der SAP zeichnet für die 2021er Release Versionen den endgültigen Umzug der Web-Dynpro basierten Szenarien in die Kachelwelt vor. Gleichzeitig sollen Projekte dann auch an das Transportsystem angekoppelt werden, sodass Projekte im Migration Cockpit zukünftig auf dem Entwicklungssystem einem Transportauftrag zugeordnet werden. Technische Änderungen und Anpassungen an den Objekten in der Transaktion LTMOM müssen dann im Entwicklungssystem erfolgen und durchtransportiert werden. Das macht das Handling von Anpassungen nicht unbedingt einfacher, aber konzeptionell nachhaltiger und zwingt nicht mehr dazu, ein Q-System oder Produktivsystem öffnen zu müssen, wenn Eingriffe mandantenspezifisch erforderlich sind.
Fazit – SAP-Migration Cockpit versus SAP LSMW
Unter dem Strich sollte ein Teilprojekt Datenmigration nicht von vornherein verpflichtet werden, ein einziges Tool für die Datenmigration zu verwenden.
Das entscheidende ist, die jeweils zuverlässigste und effektivste Auswahl zu treffen. Kernpunkt für den Migrationserfolg ist ein sehr gutes Dokumentationskonzept, welches zu jedem Objekt nachhaltig, durchgehend und diszipliniert verfolgt wird.
Ganz besonders interessant werden die Möglichkeiten, eigenes ABAP Coding in den Migrationsobjekten des SAP-Migration Cockpits einbauen und zur Fehlerbehandlung nach gängigem Verfahren per Debugging bearbeiten zu können. Dies könnte einen Durchbruch in der Verwendung des Migration Cockpits bedeuten, sofern es nicht nur im Bereich des Mappings, sondern auch im Selektionsbereich und in der Datenimport-Verarbeitung ermöglicht wird.
Ebenso besteht die Aussicht, in den zukünftigen Releases Migrationsobjekte zu Aktualisierungen von Stammdatenobjekten ausgeliefert zu bekommen.
Die LSMW wiederum, kann bis auf Weiteres als Ergänzungstool eine gewichtige Rolle spielen auf dem Weg zum Migrationserfolg.
