Datenmigration in SAP S/4HANA – Ansätze, Planung und praktische Umsetzung

Datenmigration bleibt ein zentraler Erfolgsfaktor in SAP-S/4HANA-Projekten. Während der ETL-Grundgedanke weiterhin gilt, stehen für die Datenmigration nach SAP S/4HANA heute insbesondere die von SAP bereitgestellten Standardlösungen im Vordergrund. Mit dem SAP S/4HANA Migration Cockpit und den standardisierten Migrationsobjekten stellt SAP hierfür einen integrierten Ansatz zur strukturierten Vorbereitung, Durchführung und Überwachung der Migration bereit.

Datenmigration als eigenständiges Teilprojekt

Die Datenmigration gehört zu den kritischsten Erfolgsfaktoren einer SAP-S/4HANA-Einführung. Sie verbindet fachliche Entscheidungen, Datenqualität, technische Transformation, Prozessabhängigkeiten, Testmanagement und Cutover-Planung. Eine unzureichend vorbereitete Migration kann zu verlängerten Projektlaufzeiten, inkonsistenten Stammdaten, fehlerhaften Folgeprozessen und erhöhtem Aufwand nach dem Go-live führen.

Ein belastbares Migrationskonzept definiert deshalb frühzeitig Scope, Migrationsobjekte, Datenquellen, Verantwortlichkeiten, Transformations- und Mappingregeln, Abhängigkeiten, Testzyklen, Laufzeiten sowie fachliche und technische Abnahmekriterien.

Aus der Praxis:  die technische Meldung „Migration erfolgreich“ ist kein fachlicher Abnahmestempel. Erst der fachliche Datenabgleich und die anschließende Prozessprüfung zeigen, ob die migrierten Daten im Zielsystem vollständig und korrekt verarbeitet werden können.

Wege nach SAP S/4HANA

Für den Übergang nach SAP S/4HANA werden drei grundlegende Transformationspfade unterschieden: System Conversion, New Implementation und Selective Data Transition. Welcher Pfad geeignet ist, hängt unter anderem von Ausgangssystem, Transformationsbedarf, gewünschter Datenhistorie und Projektstrategie ab.

Abbildung 1: Drei grundlegende Transformationspfade nach SAP S/4HANA

Datenarten und Migrationsscope

Für die Projektarbeit ist eine prozessorientierte Einteilung hilfreicher als eine rein technische Sicht auf Datenbanktabellen. Typische Kategorien sind Organisations- und Customizingdaten, Stammdaten, offene Geschäftsvorgänge und Bewegungsdaten, historische Daten sowie Referenz- und Mappingtabellen.

• Organisations- und Customizingdaten: Werke, Lagerorte, Buchungskreise, Steuerungsparameter.
• Stammdaten: Material, Geschäftspartner, Arbeitsplatz, Stückliste, Arbeitsplan.
• Offene Geschäftsvorgänge und Bewegungsdaten: Bestände, offene Bestellungen, Aufträge.
• Historische Daten: nur soweit fachlich, regulatorisch oder für Reportingzwecke erforderlich.
• Mapping- und Harmonisierungstabellen: kontrollierte Zuordnung von Quell- zu Zielwerten.

Der Scope sollte zusätzlich Selektionsregeln, Datenvolumen, organisatorischen Umfang und zeitliche Gültigkeit festlegen. Ebenso wichtig ist die bewusste Entscheidung, welche Daten nicht übernommen werden.

Vom ETL-Modell zum Migration Lifecycle

Extract, Transform, Load bleibt der technische Kern. Für ein reales S/4HANA-Projekt ist dieses Modell jedoch zu kurz.

Die Datenmigration in SAP S/4HANA ist kein rein linearer Ablauf, sondern ein iterativer Prozess. Insbesondere während der Testmigrationen werden Daten wiederholt validiert, migriert und im Zielsystem fachlich geprüft. Erkannte Fehler und Abweichungen fließen in die Korrektur der Mapping- und Transformationsregeln ein, bevor nach erfolgreichen Testzyklen der produktive Cutover erfolgt.

Abbildung 2: Erweiterter Migration Lifecycle

Wichtig:  der größte Aufwand entsteht häufig vor dem eigentlichen Load: bei Bereinigung, Harmonisierung, Mapping, Ableitungsregeln und der Klärung fachlicher Ausnahmen.

SAP S/4HANA Migration Cockpit – Stand 2026

Für aktuelle New-Implementation-Szenarien ist das SAP S/4HANA Migration Cockpit der zentrale SAP-Standardansatz zur Migration von Geschäftsdaten. Die Fiori-App „Migrate Your Data – Migration Cockpit“ (F3473) unterstützt Migrationsprojekte, Migrationsobjekte, Mapping-Aufgaben, Simulation und Migration.

• Staging Tables und Direct Transfer

Excel kann im Staging-Szenario weiterhin ein praktisches Arbeitsmittel sein, ist aber nicht das eigentliche Migrationswerkzeug. Bei größeren Volumina oder komplexeren Transformationen können geeignete ETL-Werkzeuge bzw. automatisierte Befüllungen sinnvoller sein.

• Migration Objects, Abhängigkeiten und Erweiterungen

Migration Objects definieren die für ein Business Object benötigten Strukturen, Beziehungen und Übertragungslogiken. Inhalte sind releaseabhängig. Vor Projektbeginn und nach Upgrades sollte daher geprüft werden, ob Objektversionen, Felder oder Status geändert wurden. Mit der App „Explore Migration Objects“ (F8638) lassen sich Abhängigkeiten zwischen Objekten visualisieren. Wenn ein Standardobjekt fachlich nicht ausreicht, ist vor einer Eigenentwicklung zu prüfen, ob eine Erweiterung mit dem Migration Object Modeler möglich ist.

• LTMC und LSMW richtig einordnen

Für aktuelle S/4HANA-Releases erfolgt der Einstieg in das SAP S/4HANA Migration Cockpit über die Fiori-App F3473. LTMC gehört zu früheren Ausprägungen des Migration Cockpit und sollte in neuen Konzepten nicht mehr als aktueller Einstiegspunkt beschrieben werden. LSMW ist für S/4HANA-Neuimplementierungen nicht der strategische Standard. Sonderfälle können dennoch andere Schnittstellen oder kundeneigene Programme erfordern.

Strukturierung und Planung der Datenmigration

Eine erfolgreiche Datenmigration erfordert eine klare Strukturierung der zu übertragenden Daten und der damit verbundenen Aktivitäten. Dazu wird zunächst festgelegt, welche Daten in welchem Umfang übernommen werden sollen. Anschließend werden technische Umsetzung, Abhängigkeiten, Verantwortlichkeiten sowie Prüf- und Freigabeschritte definiert.

Eine zentrale Rolle spielen dabei die Migrationsobjekte. Sie strukturieren die zu migrierenden Geschäftsdaten und bilden die Grundlage für die weitere Planung und Durchführung der Migration. Für jedes relevante Objekt sollten die wesentlichen Rahmenbedingungen transparent dokumentiert werden.

Diese Festlegungen bilden die Grundlage für die operative Migrationsplanung. Je nach Komplexität können sie in einer Migrationsobjektliste und einer detaillierten Migrationsspezifikation dokumentiert werden. Während die Migrationsobjektliste vor allem einen Überblick über Umfang, Status, Verantwortlichkeiten und Abhängigkeiten schafft, beschreibt die Migrationsspezifikation die konkrete Umsetzung auf Datenebene, bspw. Feld- und Wertmapping, Transformationsregeln, Ableitungen sowie fachliche Prüfungen.

Damit wird aus dem definierten Migrationsumfang ein nachvollziehbarer und wiederholbarer Prozess, der über mehrere Testzyklen hinweg bis zum produktiven Cutover gesteuert werden kann.

Testmigrationen und Datenabgleich

Eine produktive Migration sollte niemals die erste vollständige Migration sein. Bewährt hat sich eine Folge aus Test Loads, Integrationstest, Generalprobe und Production Cutover. Jeder Zyklus reduziert Unsicherheit und liefert belastbarere Aussagen zu Datenqualität und Laufzeit.

Validierung:  nicht nur Datensatzanzahlen vergleichen. Auch Schlüssel, Summen, Status, Gültigkeiten und fachliche Beziehungen müssen stimmen.

Praxisbeispiel 1: Migration von Arbeitsplänen und Einbindung in den Produktionsprozess

Das folgende Beispiel zeigt ein vollständiges Migrationsszenario im Umfeld der Arbeitsvorbereitung: Arbeitsplandaten werden aus einem Legacy-System extrahiert, fachlich geprüft, harmonisiert und für SAP S/4HANA aufbereitet. Nach der Migration werden sie in der Produktstruktur weiterverwendet.

Abbildung 3: Beispielhafte Objektabhängigkeiten in der Arbeitsvorbereitung

Nach erfolgreicher Arbeitsplanmigration werden Plangruppen den relevanten Produktstrukturknoten bzw. -stufen zugeordnet. Aus der Produktstruktur kann eine Stückliste ausgeleitet werden. Für die Anlage bzw. Validierung einer Fertigungsversion müssen die referenzierten Objekte vorhanden und fachlich gültig sein.

Qualitätsregel:  eine Fertigungsversion ist nur dann prozessual verwendbar, wenn die notwendigen Referenzen, insbesondere Stückliste und Arbeitsplan, konsistent und gültig sind.

Praxisbeispiel 2: Abhängigkeiten und Migrationsreihenfolge von PS-Objekten

Bei der Migration von PS-Daten können zwischen einzelnen Migrationsobjekten fachliche und technische Abhängigkeiten bestehen. Verweist ein Objekt auf ein anderes, muss das referenzierte Objekt bereits im Zielsystem vorhanden sein. So kann beispielsweise ein PSP-Element, das einem Projekt zugeordnet ist, erst migriert werden, wenn das entsprechende Projekt zuvor angelegt oder migriert wurde. Diese Abhängigkeiten bestimmen die erforderliche Reihenfolge der Migration.

Abbildung 4: Beispielhafte fachliche Ladefolge bei PS-Objekten

Stabile externe Schlüssel sind dabei zentral. Werden Schlüssel zwischen Test Loads geändert, verlieren Folgeobjekte ihre Referenzen. Mappingtabellen sollten deshalb versioniert und Änderungen kontrolliert dokumentiert werden.

Von der Generalprobe zum produktiven Cutover

Der Cutover verbindet technische Migration und operative Betriebsaufnahme. Für jedes Migrationsobjekt sollten Start- und Endzeit, Vorgänger, Verantwortliche, erwartete Laufzeit, Prüfschritte und Eskalationsweg feststehen.

• Data Freeze bzw. Delta-Strategie definieren.
• Finalen Extract reproduzierbar planen.
• Ladefolge anhand fachlicher Abhängigkeiten festlegen.
• Laufzeiten aus Test Loads übernehmen und Sicherheitsreserven einplanen.
• Fehlerbehandlung und Verantwortlichkeiten definieren.
• Validierung mit klaren Go/No-Go-Kriterien durchführen.
• Fallback-Entscheidungen für kritische Objekte vorbereiten.

Acht Lessons Learned

1. Datenqualität ist fachlich: technische Teams erkennen Inkonsistenzen; Data Owner entscheiden, welcher Wert fachlich richtig ist.
2. Mappingtabellen sind Projektartefakte: sie sollten versioniert, getestet und nachvollziehbar geändert werden.
3. Abhängigkeiten zuerst planen: fehlende Vorgängerobjekte erzeugen vermeidbare Ladefehler.
4. Simulation konsequent nutzen: frühe Simulation reduziert Fehler vor dem eigentlichen Load.
5. Laufzeiten messen: Cutover-Zeiten aus realistischen Test Loads ableiten, nicht aus Schätzungen.
6. Nicht alles migrieren: eine New Implementation ist auch eine Chance, Altlasten bewusst auszusortieren.
7. Standard vor Eigenentwicklung: zuerst Standardobjekt und Erweiterungsmöglichkeiten prüfen, dann kundeneigene Lösung.
8. Releaseabhängigkeit ernst nehmen: Objekte, Felder und Funktionen können sich ändern; das konkrete Zielrelease ist maßgeblich.

Fazit

Datenmigration in SAP S/4HANA ist ein wiederholbarer, kontrollierter Transformationsprozess und kein einmaliger Upload. Der technische ETL-Kern bleibt relevant, muss aber um Datenqualität, Mapping, Objektabhängigkeiten, Simulation, Testzyklen, Validierungen und Cutover-Steuerung ergänzt werden.

Für aktuelle New-Implementation-Szenarien bildet das SAP S/4HANA Migration Cockpit den zentralen Standardansatz. Staging Tables und Direct Transfer adressieren unterschiedliche Quellszenarien; Migration Objects strukturieren den Scope. Der Projekterfolg hängt dennoch wesentlich von der fachlichen Vorbereitung ab: klare Regeln, stabile Schlüssel, reproduzierbare Transformationen und belastbare Testzyklen bleiben entscheidend.