Zusammenfassung: Die Datenmigration in die SAP S/4HANA Public Cloud wird oft als Rückschritt erlebt, da moderne Middleware-Lösungen wie Peer-to-Peer-Integrationen nicht zulässig sind. Mit dem von sapXPerience entwickelten „S/4HANA Data Migration Cockpit Converter“ wird jedoch eine Lösung geboten, die durch automatisierte Konvertierung und Wiederverwendbarkeit der Daten eine effiziente und fehlerarme Migration ermöglicht. Dadurch können Kunden auch in GROW with SAP-Projekten vollständige, konsistente Datenbestände bereitstellen und ihre Tests zuverlässig und praxisnah durchführen.
Der Ansatz in der Datenmigration in die SAP S/4HANA Public Cloud ist gefühlt ein Rückschritt um zwei Jahrzehnte.
Was sind die Schlüsselfaktoren?
Eine korrekte, vollständige und integre Migration der Daten aus den Alt-Systemen in die neue SAP Welt ist bekanntermaßen einer der wesentlichen Schlüsselfaktoren zu einem erfolgreichen Go-Live mit dem neuen SAP System. Das habe ich insbesondere erfahren, nachdem ich das erste Mal Datenmigrationen in meinen Projekten eingesetzt habe, die mittels Middleware das Altsystem (Source) und das neue SAP System (Target) Peer-to-Peer miteinander verbunden haben. Sie ermöglichten die Anwendung des wesentlichen Erfolgsprinzips „Load often – Load all“ und somit ein evolutionären Vorgehen zur Sicherstellung eines vollständigen und kohärenten Datenbestandes im Target SAP-System.
Cleansings und Mappings wurden in dieser Middelware sicher und transparent unterstützt und man hatte immer alle noch in den Altsystemen zu bereinigen Daten vollständig verfügbar (s. hierzu auch meinen BLOG Beitrag 22). Seitdem ich diese Vorgehensweise erstmalig um 2010 kennenlernen durfte, habe ich diese in all meinen Projekten als wesentlichen Bestandteil zur Sicherstellung eines möglichst „langweiligen“ Go-Live erfolgreich zur Anwendung gebracht. Hier ging es allerdings nicht nur um die produktive Datenmigration, sondern insbesondere auch um die Bereitstellung von möglichst vollständigen und integeren Datenloads für den Integrations- und Akzeptanztest – ein weiterer Schlüsselfaktor für erfolgreiche Tests und das Vertrauen der Anwender in das künftige System. Allerdings setzen solche Peer-to-Peer Lösungen die Installation von spezifischen Add-Ons im Target (SAP S/4HANA) voraus, was in der S/4HANA private Cloud vielleicht noch möglich, in der S/4HANA Public Cloud aber nahezu ausgeschlossen ist.
Die Vorgeschichte
Vor diesen Middleware basierten Peer-to-Peer Lösungen war es üblich, die zu migrierenden Daten in komplexen Excel-Spreadsheets zu erfassen, zu cleanen, mit SVERWEISEN über mehrere Tabellen zu validieren und dann mittels LSMW in das SAP zu laden. Da man das aber gar nicht vollständig und konsistent hinbekommen konnte, haben viele SAP Einführungen extrem unter dem anfänglich schlechten, unvollständigen und inkonsistenten Datenbeständen beim Go-Live gelitten. An qualitativ ansprechende, annähernd vollständige Vorab-Loads für Integrations- und Akzeptanztests war gar nicht zu denken.
Soll das die Zukunft sein?
Als ich jetzt im Rahmen einer Gesamtprojektleitung erstmalig mit den in der S/4HANA Public-Cloud zur Verfügung stehenden Möglichkeiten konfrontiert wurde, fühlte ich mich in diese „Steinzeit“ zurück versetzt. Zwar kann man jetzt im Data-Migration-Cockpit (DMC) entsprechende Load-Templates für alle Datenobjekte entsprechend der Scope-ID (SI) Auswahl generieren, füllen und mittels DMC deren Load in das Target S/4HANA simulieren. Allerdings verfügen diese XML-Load-Templates über teilweise bis zu 15-20 Registerblätter, die konsistent nicht nur in einer Datei, sondern über Dateien mehrerer Objekte hinweg befüllt werden müssen und das ja vorzugsweise mit den aus dem Altsystem extrahierten Daten. Das ist eine rein manuelle Sisyphusarbeit und wird final nicht zu einem mit vollständig business-ready Daten beladenen S/4HANA-System führen können. Nur ist genau das der Anspruch und die Messlatte, die ich für von mir geleitete Projekte zugrunde lege.
Die gute Nachricht:
Wir haben eine Lösung entwickelt. Diese ist zwar nicht Peer-to-Peer, aber folgt den Prinzipien dieser Lösungen und macht die Anwendung des Erfolgsprinzips „Load often – Load all“ möglich: Eingeflossen in diese Lösung sind einerseits die aus jahrelanger Erfahrung gewonnenen Kenntnisse um die Möglichkeiten und Prinzipien der Middleware basierten Peer-to-Peer Systeme und andererseits profunde Kenntnisse in der Excel-basierten Entwicklung einer passenden Lösung. Diese erlaubt es, aus den Datenextrakten aus den Legacy-Systemen die Load-Templates des Data-Migration-Cockpit vollständig und konsistent zu befüllen, ohne dass die extrahierten Legacy-Daten vorher manuell bearbeitet werden müssen. Somit ist der gesamten Prozess vollständig und sicher wiederholbar und testbar und wir erreichen mittels einer evolutionären Vorgehensweise einen vollständigen und konsistenten Datenload für das S/4HANA-System.
Folgende schematische Darstellung gibt einen Überblick über die Gesamtlösung, in der der von uns entwickelte sapXP „S/4HANA Data Migration Cockpit Converter“ eine zentrale Rolle spielt:
Das Vorgehen ist dabei wie folgt:
-
- Extraktion der Daten der unterschiedlichen Datenobjekte aus den verschiedenen Legacy Systemen in ein beliebiges Format, welches nach Excel übertragen werden kann. Unbedingt zu empfehlen ist eine vorgängige sog. Active-Record Determination (Inhalt und Vorgehen s. BLOG 22), um keinen unnötigen Datenmüll in das neue System zu übernehmen.
- Field-Mapping, formales Cleansing und Übertrag der Daten in die aus dem S/4HANA Data Migration Cockpit generierten SAP XML Load Templates. Hierbei werden:
- Einmalig die Target Felder einfach aus den XML-Sheets mittels Copy/Paste (transponiert) als Target Felder in den „S/4HANA Data Migration Cockpit Converter“ übertragen (s. Video-Anleitung).
- Die Felder (Spaltenüberschiften) der Source Dateien auf die Targets gemappt; hierbei ist eine n(Sources) : 1 (Target) Zuordnung möglich. So sieht das Mapping aus:
- Optional einzelnen gemappten Feldern vorhandene Routinen zur formalen Bereinigung der übertragenen Daten zugeordnet. Dies sind z.B:
- Trennung des Straße/Hausnummer-Feldes in separate Felder
- Konvertierung von Zahlen mit Dezimalstellen in das jeweils im SAP Target Feld im verlangten Format
- Konvertierung von Datumsfeldern in das jeweils im SAP Target Feld verlangte Format
- Bedingte Belegung von im Altsystem nicht gepflegten Feldern mit vorgegebenen Werten in einzelnen Sätzen
- Eintrag von Vorgabewerten in einzelne Felder in Abhängigkeit vom Vorhandensein von Inhalten in anderen Feldern
- … und einiges mehr (weitere werden gern auf Anfrage bereitgestellt)
Auf ein inhaltliches Mapping (Wert im Altsystem : Wert im SAP System) (Einkäufergruppen, Werke; Lagerorte, Buchungsschlüssel etc.) wurde an dieser bewusst verzichtet, da entsprechende Mapping-Tabellen im S/4HANA Migration Cockpit einfacher und effektiver nach Vorgabe des Business angelegt werden können (eine einfache und sinnvolle Vorbereitung ist dabei die Vorgabe dieser Mappings im Rahmen von Excel Tabellen, die dann in das DMC übertragen werden (vorhandene zu mappende Legacy Werte kann man dabei einfach und vollständig aus den Legacy-Extrakt Dateien generieren und dem Business zum Mapping zur Verfügung stellen).
Hier eine exemplarische Liste potentieller 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
- Optional besteht auch die Möglichkeit, bereits generierte XML-Load-Sheets dem Business zur Datenbereinigung oder Datenanreicherung zur Verfügung zu stellen und diese dann als Source für den Update neu generierter XML-Load-Sheets zu nutzen. Das kann ja in einzelnen Fällen sinnvoller und schneller sein, als die Daten in der Legacy Source zu bereinigen – oder auch, wenn eine Bereinigung dort aufgrund des aktuell weiterlaufenden produktiven Betriebs nicht möglich ist, aber konsistent vorgenommen werden soll.
- Mit den so generierten Load-Sheets wird der Load im DMC simuliert und die dabei generierten Fehler zurückgemeldet und entweder durch Anpassung des Mapping und/oder Cleansing der Legacy Daten (alternativ s. auch vorgenannten 3. Punkt ) behoben werden und das Load-Sheet für einen neuen Versuch erneut generiert werden.
Nicht zu vernachlässigen ist an dieser Stelle der Punkt, dass die Simulation ja immer für den gesamten Datenbestand eines Objektes erfolgt und somit in jeder Simulationsrunde IMMER ALLE noch vorhandenen Defizite zu Tage treten und korrigiert werden können – dadurch, dass z.B. die Anpassung das Mappings und die Neugenerierung des Load-Sheets für eine erneute Simulation nur wenige Minuten in Anspruch nimmt, kommt es dabei zu extrem schnellen Turnaround-Zeiten mit jeweils maximalem Erkenntnisgewinn – eben „Load often – Load all“ enabled 😉. - Wenn die Simulation eines Target-Objekts ohne Fehler durchgelaufen ist, kann der Load in das SAP Target System erfolgen (sog. MOCK-Load). Hierbei sind natürlich die Abhängigkeiten der Objekte im Target-System zu beachten, anstatt erst die unabhängigen Objekte (Kunden, Lieferanten und Produkte) und anschließend die abhängigen Objekte (BoMs, Routings, Infosätze, Preise etc.) und deren Abhängigkeiten durch die Definition bestimmter Load-Zyklen zu beachten (Inhalt und Vorgehen s. BLOG 22).
Erfahrungen und Tipps aus der aktuellen Anwendung in einem GROW with SAP-Projekt (S/4HANA Public-Cloud)
In meinem aktuellen Projekt haben wir sapXP‘s „S/4HANA Data Migration Cockpit Converter“ seit ca. einem Monat zur Verfügung und haben bisher folgenden Stand erreicht bzw. folgende Erfahrungen gemacht:
- Bei den unabhängigen Objekten (Kunde, Lieferant und Produkte (aller Materialarten)) stehen wir kurz vor dem Abschluss der letzten fehlerfreien Simulation und können demnächst mit dem Load beginnen
- Über alle Objekte gesehen, haben wir aktuell einen Stand erreicht, der es uns wahrscheinlich erlaubt, auf einen der geplanten MOCK-Loads (wir hatten drei geplant) zu verzichten
- Wir werden mit großer Sicherheit den Anwendern zum Integrationstest ein System mit annähernd vollständigen und konsistenten Stammdaten zur Verfügung stellen können.
- Wir haben alle großen Datenbestände sicher im Griff – die einzige Größenbeschränkung ist die durch die SAP Load-Templates verursachte, da diese im Einzelfall nur 160 MB haben dürfen und deshalb große Datenbestände (i.e. mit mehr ca. 750‘000 Sätzen) auf mehreren Load-Sheets gesplittet werden müssen. Wir machen das durch ein entsprechendes Splitting der extrahierten Datendateien mittels eines Python-Skiptes (dies stellen wir gemeinsam mit sapXP‘s „S/4HANA Data Migration Cockpit Converter“ zur Verfügung stellen).
- Die SAP XML-Load-Templates, für die keine extrahierten Daten zur Verfügung stehen, müssen manuell befüllt werden. Auch wenn das nur geringe Datenbestände betrifft, ziehen wir das Befüllen der XML-Load-Sheets der mehrfachen Eingabe der Daten im Rahmen der unterschiedlichen MOCK-Loads vor, um den gesamten Migrationsdurchlauf automatisiert und personenunabhängig durchführen zu können. Dies betrifft in der Regel jeweils auch nur eine überschaubare Anzahl von Datensätzen, wie z.B. einige Datenobjekte im QM oder Compliance Umfeld.
- Wir konnten bisher alle kniffligen Fragen im Umfeld des Datenmapping insbesondere auch deshalb vollautomatisiert lösen, weil der „S/4HANA Data Migration Cockpit Converter“ extrem generisch für alle möglichen Konstellationen angewendet werden kann und immer sehr stabil und konsistent funktioniert. Hier ein Auszug der Objekte, die wir aktuell in der Simulation haben:
Fazit und Empfehlung
Wir sind stolz und heilfroh, dass wir in so kurzer Zeit so ein mächtiges und gleichzeitig simpel zu bedienendes Werkzeug entwickeln konnten, das uns wieder in die Lage versetzt, das mission-kritische Thema Datenmigration auch in einem S/4HANA Public-Cloud Projekt sicher und kontrolliert ins Ziel zu bringen. Insbesondere werden dadurch auch die Key-User in den noch anstehenden kritischen Tasks Integrations- und Akzeptanztest massiv unterstützt und von ansonsten notwendigen Datenerfassungsaufgaben befreit. Das bedeutet, dass sie darauf fokussieren können, sich mit dem künftigen SAP S/4HANA-System im Rahmen von Tests mit vollständigen Datenbeständen vertraut zu machen. Und das ist ja erfahrungsgemäß der zweite mission-kritische Aspekt, dass das System von den Anwendern sicher bedient werden kann.
Da die Aufgabe der Datenmigration in einem „SAP Activate“-Projekt definitionsgemäß dem Kunden zufällt (s. BLOG Beitrag 35) kann ich persönlich nur jedem Kunden dringend anraten, den „S/4HANA Data Migration Cockpit Converter“ der sapXPerience GmbH in seinem Projekt zum Einsatz zu bringen. Den Link zum Download finden Sie in unserem Digistore24. Verwenden Sie den Gutscheincode INTRO75, um bis zum 30.09.2025 von einem Einführungsrabatt in Höhe von 75% zu profitieren.
Damit Sie bei Ihrem GROW with SAP-Projekt auch von unseren zahlreichen weiteren Produkten im Digistore24 profitieren können, verwenden Sie bis 30.09.2025 den Gutschein Code GROW25. Hier finden Sie eine Übersicht unserer digitalen Produkte.
Hier sehen Sie eine Einführung zum S/4HANA Data Migration Cockpit Converter auf Youtube.
Ein Demo-Video der Anwendung sehen Sie hier bei Youtube.