Das SAP S/4HANA Migration Cockpit unterstützt die initiale Datenübernahme nach S/4HANA – doch welches Verfahren passt zu welchem Projekt? Wir erklären Migration Objects, Staging Tables, Direct Transfer sowie die Rolle von LTMC und LTMOM.

SAP S/4HANA Migration Cockpit: Datenmigration, Migration Objects und Vorgehen erklärt

Bei einer SAP-S/4HANA-Transformation gehört die Datenmigration häufig zu den arbeitsintensivsten Teilen des Projekts. Stammdaten müssen bereinigt, offene Geschäftsvorgänge übernommen, Werte gemappt und die Ergebnisse nach mehreren Testmigrationen fachlich validiert werden.

Für viele dieser Aufgaben stellt SAP das SAP S/4HANA Migration Cockpit bereit.

Doch rund um das Tool gibt es weiterhin einige Missverständnisse. Ist LTMC noch aktuell? Welche Rolle spielt LTMOM? Wann verwendet man Staging Tables und wann Direct Transfer? Kann mit dem Migration Cockpit die gesamte ECC-Historie übernommen werden? Und wird das Tool bei Greenfield, Brownfield oder beiden Ansätzen eingesetzt?

Die wichtigste Einordnung vorweg:

Das SAP S/4HANA Migration Cockpit ist kein Werkzeug für die komplette technische S/4HANA-Migration. Es unterstützt die initiale Übernahme von Geschäftsdaten in ein S/4HANA-Zielsystem.

SAP beschreibt das Migration Cockpit ausdrücklich als Werkzeug für den Initial Load von Daten, insbesondere im Rahmen einer SAP-S/4HANA-Neuimplementierung. Es ist nicht dafür gedacht, Systeme dauerhaft zu synchronisieren oder eine kontinuierliche Integration aufzubauen.

Die passende Datenmigrationsstrategie beginnt deshalb nicht mit der Frage „Wie bedienen wir das Migration Cockpit?“, sondern mit:

Welche Daten benötigen wir im Zielsystem, aus welchen Quellen kommen sie, wie stark müssen sie transformiert werden und welcher Migrationsweg passt zum gewählten S/4HANA-Szenario?

Das Wichtigste in Kürze

• Das SAP S/4HANA Migration Cockpit dient der initialen Migration von Geschäftsdaten nach SAP S/4HANA.
• Die aktuelle Oberfläche ist die SAP-Fiori-App Migrate Your Data – Migration Cockpit mit der App-ID F3473.
• SAP liefert vordefinierte Migration Objects, die beschreiben, welche Daten und Strukturen für bestimmte Business Objects übertragen werden.
• Für SAP S/4HANA stehen abhängig vom Szenario insbesondere Staging Tables und Direct Transfer aus unterstützten SAP-Quellsystemen zur Verfügung.
• Die frühere Transaktion LTMC ist deprecated und kann für aktuelle Datenmigrationen nicht mehr verwendet werden. Ihr Nachfolger ist die Fiori-App Migrate Your Data.
• LTMOM ist dagegen weiterhin relevant. Der SAP S/4HANA Migration Object Modeler kann genutzt werden, um Migration Objects zu erweitern.
• Das Migration Cockpit löst weder schlechte Datenqualität noch fehlende fachliche Entscheidungen automatisch. Datenbereinigung, Mapping, Ownership, Tests, Reconciliation und Cutover-Planung bleiben zentrale Projektaufgaben.

Was ist das SAP S/4HANA Migration Cockpit?

Das SAP S/4HANA Migration Cockpit ist das von SAP bereitgestellte Werkzeug für die initiale Übernahme von Geschäftsdaten in SAP S/4HANA.

Über die Fiori-App Migrate Your Data – Migration Cockpit können Projektteams unter anderem:

• Migrationsprojekte anlegen,
• relevante Migration Objects auswählen,
• Mapping-Aufgaben bearbeiten,
• Datenmigrationen simulieren,
• Daten nach SAP S/4HANA übertragen,
• den Status von Simulation und Migration überwachen.

SAP führt die aktuelle App unter der ID F3473.

Das Migration Cockpit arbeitet dabei nicht einfach mit beliebigen Tabellen.

Für unterschiedliche Business Objects stellt SAP definierte Migration Objects bereit. Diese enthalten die notwendigen Strukturen, Beziehungen, Mappings und Regeln für die Überführung der Daten in das S/4HANA-Zielmodell.

Damit standardisiert SAP einen großen Teil der technischen Datenübernahme.

Was das Tool allerdings nicht übernimmt, sind Entscheidungen wie:

• Welche Daten werden überhaupt migriert?
• Welche Daten können archiviert oder stillgelegt werden?
• Welche Dubletten müssen vorab bereinigt werden?
• Wie werden Werte zwischen alten und neuen Organisationsstrukturen gemappt?
• Welche Daten werden für den Cutover eingefroren?
• Wer bestätigt nach der Migration, dass die Daten fachlich korrekt sind?

Genau deshalb ist Migration Cockpit nicht gleich Datenmigrationsstrategie.

Ist das SAP Migration Cockpit dasselbe wie LTMC?

Nein.

Die Begriffe werden noch häufig gemeinsam verwendet, weil LTMC über Jahre eng mit dem S/4HANA Migration Cockpit verbunden war.

Heute muss man jedoch klar unterscheiden.

LTMC: die frühere Migration-Cockpit-Transaktion

LTMC steht für die frühere transaktionsbasierte Oberfläche des SAP S/4HANA Migration Cockpit.

SAP kennzeichnet LTMC inzwischen ausdrücklich als deprecated.

Noch deutlicher: SAP dokumentiert für SAP S/4HANA 2025 FPS01, dass LTMC nicht mehr für die Migration von Daten nach SAP S/4HANA verwendet werden kann. Bereits angelegte alte Projekte können weiterhin eingesehen werden.

Wer heute nach:

• SAP LTMC,
• LTMC S/4HANA,
• LTMC Migration,
• LTMC Nachfolger

sucht, sollte deshalb wissen:

Der aktuelle Nachfolger von LTMC ist die SAP-Fiori-App „Migrate Your Data – Migration Cockpit“.

Migrate Your Data – Migration Cockpit: der aktuelle Weg

Die heutige App bündelt den Migrationsprozess in SAP Fiori.

Projektteams können dort Migration Objects auswählen, Daten vorbereiten, Mappings bearbeiten, die Migration zunächst simulieren und danach ausführen.

Das bedeutet nicht, dass alle älteren Begriffe verschwunden sind.

Einer davon ist LTMOM.

Was ist LTMOM – und ist es ebenfalls deprecated?

Nein. LTMOM und LTMC erfüllen unterschiedliche Aufgaben.

LTMOM öffnet den SAP S/4HANA Migration Object Modeler.

SAP beschreibt den Migration Object Modeler weiterhin als Anwendung, mit der Migration Objects des SAP S/4HANA Migration Cockpit erweitert werden können. Der Zugriff erfolgt bei SAP S/4HANA über die Transaktion LTMOM.

Einfach ausgedrückt:

LTMC
→ frühere Oberfläche für die eigentliche Datenmigration; heute deprecated.

Migrate Your Data – Migration Cockpit
→ aktuelle Fiori-App für die Datenmigration.

LTMOM
→ Werkzeug zur Anpassung beziehungsweise Erweiterung von Migration Objects.

Welche Funktionen im Migration Object Modeler verfügbar sind, hängt vom gewählten Migrationsansatz ab.

LTMOM kann beispielsweise relevant werden, wenn der SAP-Standard eines Migration Objects die Anforderungen des Projekts nicht vollständig abdeckt.

Allerdings sollte nicht jede Abweichung sofort zu einer technischen Erweiterung führen.

Zunächst sollte geprüft werden:

Ist eine Anpassung des Migration Objects wirklich notwendig – oder kann die Anforderung durch Datenbereinigung, Mapping oder die Standardlogik gelöst werden?

Was sind Migration Objects?

Ein Migration Object beschreibt, wie Daten für ein bestimmtes Business Object in SAP S/4HANA übernommen werden.

SAP liefert zahlreiche dieser Objekte standardmäßig aus.

Ein Migration Object enthält unter anderem Informationen über:

• relevante Quellstrukturen,
• Zielstrukturen in SAP S/4HANA,
• Beziehungen zwischen den Strukturen,
• Feldzuordnungen,
• Regeln für die Konvertierung von Werten.

Typische Business Objects können – abhängig von Release, Scope und Migrationsansatz – beispielsweise aus Bereichen wie:

• Business Partner,
• Materialstamm,
• Finance,
• Anlagenbuchhaltung,
• Einkauf,
• Vertrieb,
• Produktion

kommen.

Wichtig ist: Nicht jedes Migration Object steht in jedem Szenario identisch zur Verfügung.

SAP weist ausdrücklich darauf hin, dass die verfügbaren Migration Objects unter anderem vom aktivierten Scope und vom verwendeten Ansatz – beispielsweise Direct Transfer oder Staging Tables – abhängen.

Auch die Objekte selbst entwickeln sich zwischen Releases weiter. Für SAP S/4HANA 2025 FPS01 dokumentiert SAP neue, geänderte, deprecated und entfernte Migration Objects separat.

Deshalb sollte die Migration nicht auf Basis einer alten Excel-Liste aus einem früheren S/4HANA-Projekt geplant werden.

Die relevanten Objects müssen für das konkrete Zielrelease und den konkreten Migrationsansatz geprüft werden.

Wie funktioniert das SAP S/4HANA Migration Cockpit?

Der genaue Ablauf hängt von Staging Tables oder Direct Transfer ab. Das Grundprinzip ist jedoch vergleichbar.

1. Migrationsprojekt anlegen

Zunächst wird im S/4HANA-Zielsystem ein Migration Project angelegt.

Damit wird festgelegt, über welchen Ansatz die Daten übernommen werden und welche Rahmenbedingungen für die Migration gelten.

2. Migration Objects auswählen

Anschließend werden die Business Objects ausgewählt, die für den Scope benötigt werden.

SAP liefert die technischen Definitionen der Migration Objects bereits mit.

3. Quelldaten bereitstellen oder selektieren

Beim Staging-Ansatz werden die Daten in Staging Tables bereitgestellt.

Beim Direct Transfer werden Daten aus einem unterstützten SAP-Quellsystem selektiert.

4. Mapping bearbeiten

Nicht jeder Wert im Altsystem entspricht direkt dem Wert im Zielsystem.

Beispiele können sein:

• Unternehmenscodes,
• Organisationseinheiten,
• Zahlungsbedingungen,
• Einheiten,
• Materialarten,
• Konten,
• Länder- oder Regionswerte.

Diese Unterschiede müssen über Mapping-Regeln aufgelöst werden.

5. Migration simulieren

Vor der tatsächlichen Datenübernahme lässt sich die Migration simulieren.

Das ist ein wichtiger Schritt, um:

• Fehler,
• fehlende Pflichtwerte,
• problematische Mappings,
• inkonsistente Daten

vor dem Load zu erkennen.

SAP führt Simulation ausdrücklich als Bestandteil der aktuellen Migrate-Your-Data-App.

6. Fehler korrigieren

Probleme werden analysiert und – abhängig von Ursache – entweder:

• in den Quelldaten,
• in Mapping-Regeln,
• in der Migrationskonfiguration,
• oder in der Zielkonfiguration

korrigiert.

7. Daten migrieren

Sind Simulation und Prüfungen erfolgreich, werden die Daten in das S/4HANA-Zielsystem übertragen.

8. Daten fachlich validieren

Dieser Schritt liegt nicht einfach „beim Tool“.

Nach der Migration muss geprüft werden:

• Stimmen Mengen?
• Stimmen Salden?
• Sind Beziehungen zwischen Datenobjekten intakt?
• Funktionieren die Geschäftsprozesse?
• Können Fachbereiche mit den Daten produktiv arbeiten?

Eine technisch erfolgreiche Migration ist erst dann erfolgreich, wenn auch die fachliche Reconciliation stimmt.

Staging Tables oder Direct Transfer: Was ist der Unterschied?

Eine der wichtigsten Entscheidungen im Migration Cockpit betrifft den Weg, über den die Quelldaten bereitgestellt werden.

Für SAP S/4HANA dokumentiert SAP insbesondere:

Migrate Data Using Staging Tables

und

Migrate Data Directly from SAP System.

Die beiden Ansätze lösen unterschiedliche Aufgaben.

Datenmigration mit Staging Tables

Beim Staging-Ansatz erzeugt das Migration Cockpit für die relevanten Migration Objects Staging Tables.

Diese Tabellen dienen als Zwischenschicht zwischen Quelle und SAP-S/4HANA-Zielsystem.

Für Migration Objects stellt SAP Template-Dateien bereit.

Die Daten können:

• über diese Templates vorbereitet,
• oder mit anderen Werkzeugen direkt in die Staging Tables geladen

werden.

SAP nennt beispielsweise SAP Data Services als mögliches Werkzeug.

Wann sind Staging Tables sinnvoll?

Der Ansatz ist besonders interessant, wenn:

• Daten aus Non-SAP-Systemen kommen,
• mehrere Quellen zusammengeführt werden,
• umfangreichere Transformationen erforderlich sind,
• Daten außerhalb des Migration Cockpit bereinigt werden,
• ein ETL-Prozess vor der eigentlichen S/4HANA-Übernahme notwendig ist.

Das Staging schafft eine kontrollierbare Zwischenschicht.

Genau darin liegt allerdings auch eine häufig unterschätzte Projektaufgabe:

Jemand muss die Staging Tables mit korrekten, vollständigen und fachlich abgestimmten Daten befüllen.

Das Migration Cockpit erzeugt nicht automatisch saubere Quelldaten.

Direct Transfer aus einem SAP-System

Beim Direct Transfer greift das Migration Cockpit auf ein unterstütztes SAP-Quellsystem zu und selektiert die für ein Migration Object relevanten Daten direkt.

SAP beschreibt diesen Ansatz für die Übernahme von Business Data aus bestimmten SAP-Quellsystemen nach SAP S/4HANA.

Dabei definieren die Migration Objects unter anderem:

• benötigte Tabellen,
• deren Beziehungen,
• Feldmappings,
• Konvertierungsregeln.

Das kann die technische Extraktion deutlich vereinfachen.

Wann kann Direct Transfer sinnvoll sein?

Typischerweise dann, wenn:

• ein unterstütztes SAP-System die Quelle ist,
• die benötigten Migration Objects verfügbar sind,
• die Datenauswahl gut über die verfügbaren Selektionskriterien gesteuert werden kann,
• keine umfangreiche externe Transformationsschicht erforderlich ist.

Aber:

„Direct“ bedeutet nicht „ohne Datenmigration“.

Datenqualität, Scope, Mapping, Abhängigkeiten, Tests und fachliche Validierung bleiben genauso notwendig.

Neuere hybride Möglichkeiten

Mit SAP S/4HANA 2025 FPS01 hat SAP den Direct-Transfer-Ansatz außerdem erweitert: selektierte Daten können bei entsprechenden Szenarien zunächst in Staging Tables eines Remote-SAP-HANA-Schemas zwischengespeichert und dort angepasst werden, bevor der Migrationsprozess fortgesetzt wird.

Das zeigt auch, warum die Entscheidung Staging vs. Direct Transfer nicht zu dogmatisch verstanden werden sollte.

Entscheidend ist das reale Daten- und Transformationsszenario.

Welche Daten können mit dem Migration Cockpit migriert werden?

Hier entsteht häufig das nächste Missverständnis:

„Dann übernehmen wir mit dem Migration Cockpit einfach unsere komplette ECC-Datenbank.“

So funktioniert die Lösung nicht.

Das Migration Cockpit ist auf die initial benötigten Business Data für den Betrieb des neuen Systems ausgerichtet. SAP beschreibt für seine S/4HANA-Cloud-Dokumentation beispielsweise folgende Kategorien:

• Stammdaten
• offene Bewegungsdaten
• Salden

Dazu können beispielsweise Kunden- und Lieferantenstämme, offene Posten, offene Aufträge sowie Bestands- und Sachkontensalden gehören.

Für bestimmte Finance-Szenarien existieren auch eigene Möglichkeiten für die Übernahme historischer Salden.

Das bedeutet jedoch nicht, dass die komplette Transaktionshistorie eines alten ERP-Systems übernommen wird.

Insbesondere bei SAP S/4HANA Cloud Public Edition dokumentiert SAP ausdrücklich, dass abgeschlossene historische Bewegungsdaten nicht über das Migration Cockpit migriert werden.

Die konkrete Datenstrategie muss deshalb unterscheiden zwischen:

migrieren
Daten, die für den produktiven Betrieb benötigt werden.

archivieren
Daten, die aus regulatorischen oder betrieblichen Gründen weiter verfügbar sein müssen.

extern zugänglich halten
Historische Informationen, die nicht zwingend im neuen S/4HANA-Transaktionssystem liegen müssen.

bereinigen oder stilllegen
Daten ohne zukünftigen fachlichen Wert.

Die Frage lautet also nicht:

Wie bekommen wir alles nach S/4HANA?

Sondern:

Welche Daten braucht das zukünftige Unternehmen tatsächlich im neuen S/4HANA-System?

SAP Migration Cockpit bei Greenfield, Brownfield und Selective Data Transition

Nicht jeder S/4HANA-Migrationsansatz nutzt das Migration Cockpit auf dieselbe Weise.

Diese Unterscheidung ist wichtig.

Greenfield / S/4HANA-Neuimplementierung

Hier besitzt das Migration Cockpit die klarste Rolle.

Bei einer Greenfield-Einführung wird ein neues S/4HANA-Zielsystem aufgebaut.

Die benötigten Business Data müssen deshalb aus:

• ECC,
• anderen SAP-Systemen,
• Non-SAP-Systemen,
• Dateien,
• Datenbanken

in die neue Struktur überführt werden.

SAP beschreibt das Migration Cockpit ausdrücklich als Lösung für den initialen Daten-Load und insbesondere für das New Implementation Scenario.

Typische Aufgaben sind:

Extract → Cleanse → Transform → Map → Load → Reconcile

Damit ist das Migration Cockpit ein wichtiger technischer Baustein der Greenfield-Datenmigration.

Es ersetzt aber nicht die fachliche Datenstrategie.

Brownfield / SAP S/4HANA System Conversion

Bei einer System Conversion sieht die Situation anders aus.

Hier wird das bestehende SAP-ECC-System technisch auf SAP S/4HANA konvertiert.

Die vorhandenen Daten bleiben grundsätzlich Bestandteil des konvertierten Systems.

Deshalb ist das Migration Cockpit nicht das Werkzeug, das die gesamte ECC-Datenbank von einem alten in ein neues S/4HANA-System kopiert.

Das wäre konzeptionell eine Neuimplementierung, nicht die klassische Brownfield-Conversion.

Im Brownfield-Projekt können trotzdem zusätzliche Datenmigrationsanforderungen entstehen. Die Rolle muss jedoch konkret aus dem jeweiligen Scope abgeleitet werden.

Für die eigentliche System Conversion stehen andere Themen im Vordergrund, beispielsweise:

• Simplification Items,
• CVI,
• Custom Code,
• technische Conversion,
• Datenmodelltransformationen,
• SUM,
• Testing und Cutover.

Selective Data Transition

Selective Data Transition liegt zwischen den beiden Extremen.

Unternehmen möchten beispielsweise:

• nur bestimmte Gesellschaften übernehmen,
• Organisationsstrukturen verändern,
• Daten selektiv harmonisieren,
• Teile der Historie erhalten,
• mehrere Systeme konsolidieren.

Hier reicht die einfache Aussage „Wir verwenden das Migration Cockpit“ oft nicht aus.

Abhängig von:

• Datenvolumen,
• gewünschter Historie,
• Transformationstiefe,
• Quelllandschaft,
• benötigter Selektivität

können zusätzliche SAP- oder Partnerwerkzeuge und eine eigene Transformationsmethodik erforderlich sein.

Das Migration Cockpit kann Teil eines solchen Datenmigrationskonzepts sein – aber es definiert nicht automatisch die gesamte Selective-Data-Transition-Architektur.

Wie werden Daten im Migration Cockpit gemappt?

Technische Übertragung allein reicht selten aus.

In einem neuen S/4HANA-System können Werte anders strukturiert sein als in den Quellsystemen.

Beispiel:

Im Altsystem existiert:

Company Code: 1000

im neuen harmonisierten Zielmodell soll daraus beispielsweise:

Company Code: DE01

werden.

Solche Unterschiede müssen über Mapping Tasks und Mapping Rules aufgelöst werden.

Die aktuelle Migration-Cockpit-App unterstützt die Bearbeitung solcher Mapping-Aufgaben direkt im Migrationsprozess.

Typische Mapping-Fragen betreffen:

• Organisationsstrukturen,
• Konten,
• Materialarten,
• Einheiten,
• Länderwerte,
• Zahlungsbedingungen,
• Steuerklassifikationen,
• weitere Codes und Stammdatenwerte.

Mapping ist eine fachliche Entscheidung

Technisch kann eine Mapping-Regel schnell definiert sein.

Die schwierigere Frage lautet:

Welcher Zielwert ist fachlich korrekt?

Diese Entscheidung kann selten allein vom Migrationsteam getroffen werden.

Dafür braucht es:

• Data Owner,
• Process Owner,
• SAP-Fachexperten,
• Verantwortliche aus Finance, Supply Chain oder anderen Fachbereichen.

Fehlt dieses Ownership, wird Datenmigration schnell zum technischen Bottleneck.

Kann das Migration Cockpit schlechte Daten automatisch bereinigen?

Nein.

Das ist einer der wichtigsten Punkte für die Projektplanung.

Das Migration Cockpit kann Daten:

• strukturieren,
• mappen,
• validieren,
• simulieren,
• übertragen.

Es kann aber nicht automatisch entscheiden:

• welche Dublette die richtige ist,
• welche Adresse aktuell ist,
• welche Materialstämme noch gebraucht werden,
• ob zwei Lieferanten zusammengeführt werden sollten,
• welche alten Konten im neuen Modell weiterbestehen,
• welche historischen Werte fachlich korrekt sind.

Deshalb sollte die Datenmigration idealerweise in dieser Reihenfolge gedacht werden:

Profiling → Bereinigung → Harmonisierung → Mapping → Testmigration → Reconciliation → Cutover

und nicht:

Load → Fehler sehen → Daten irgendwie reparieren.

Je später Datenqualitätsprobleme entdeckt werden, desto stärker wirken sie auf:

• Testzyklen,
• Cutover,
• Prozessvalidierung,
• Projektzeitplan.

Das Migration Cockpit transportiert Daten. Es entscheidet nicht, welche Daten Ihr zukünftiges Unternehmen benötigt.

Welche Abhängigkeiten bestehen zwischen Migration Objects?

Business Objects stehen selten isoliert.

Ein Verkaufsauftrag kann beispielsweise nicht sinnvoll migriert werden, wenn die dafür benötigten Business Partner oder Materialstämme noch fehlen.

SAP bildet solche Abhängigkeiten zwischen Migration Objects ab.

Ein Migration Object kann:

• Predecessor Objects
• und Successor Objects

besitzen.

SAP bietet inzwischen mit Explore Migration Objects außerdem eine interaktive Darstellung solcher Abhängigkeiten. Sie zeigt unter anderem, welche Migration Objects zwingende Vorgänger anderer Objekte sind.

Für das Projekt ist das äußerst wichtig.

Denn daraus entsteht die Migration Sequence.

Beispielsweise vereinfacht:

Organisationsdaten → Stammdaten → Salden → offene Transaktionen

Der konkrete Ablauf muss jedoch anhand der tatsächlich verwendeten Migration Objects geplant werden.

Das beeinflusst auch den Cutover.

Wenn ein früheres Objekt fehlschlägt, können nachgelagerte Datenmigrationen blockiert werden.

Wie sollten Testmigrationen organisiert werden?

Eine Datenmigration sollte nicht erstmals am produktiven Cutover-Wochenende vollständig durchlaufen werden.

SAP selbst beschreibt für Migration-Cockpit-Projekte mehrere Testmigrationen als üblichen Bestandteil des Prozesses. Erkenntnisse aus einem Test werden in nachfolgende Migration Projects beziehungsweise transportierte Projektstände übernommen.

In der Praxis können mehrere Mock Cycles sinnvoll sein.

Frühe Testmigration

Schwerpunkt:

• technische Strukturen,
• Migration Objects,
• erste Mappings,
• grundlegende Datenfehler.

Weitere Testmigration

Schwerpunkt:

• Datenqualität,
• Vollständigkeit,
• fachliche Validierung,
• Dependencies.

Cutover-nahe Testmigration

Schwerpunkt:

• realistisches Datenvolumen,
• Laufzeiten,
• Reihenfolge,
• Reconciliation,
• Cutover-Prozesse.

Die genaue Zahl der Mock Cycles ist projektspezifisch. Sie sollte nicht als fixe SAP-Vorgabe verstanden werden.

Entscheidend ist vielmehr:

Der produktive Migrationslauf sollte keine neuen grundlegenden Probleme mehr aufdecken.

Was gehört zum Cutover der Datenmigration?

Der eigentliche Load ist nur ein Teil des Cutovers.

Ein belastbarer Daten-Cutover muss beantworten:

Wann werden Quelldaten eingefroren?

Bestimmte Stammdaten können während des Übergangs eventuell nicht mehr geändert werden – oder müssen für einen definierten Zeitraum doppelt gepflegt werden.

SAP weist beispielsweise für Cloud-Migrationsszenarien ausdrücklich auf mögliche Freeze Periods oder Double Maintenance für bestimmte Objekte hin.

Welche Daten werden zu welchem Zeitpunkt extrahiert?

Master Data und offene Transaktionsdaten besitzen unterschiedliche Abhängigkeiten und Zeitpunkte.

In welcher Reihenfolge werden Migration Objects geladen?

Predecessor-/Successor-Beziehungen müssen berücksichtigt werden.

Wie erfolgt die Reconciliation?

Beispiele:

• Anzahl Stammsätze,
• offene Posten,
• Summen,
• Bestände,
• Kontosalden.

Wer gibt die Daten fachlich frei?

Nicht nur IT.

Für geschäftskritische Daten sollte eindeutig definiert sein, welcher Process Owner oder Data Owner die erfolgreiche Migration bestätigt.

Was passiert bei Fehlern?

Es braucht vorab definierte Kriterien für:

• Korrektur,
• Wiederholung,
• Abbruch,
• gegebenenfalls Rollback.

Eine Migration ohne klare Reconciliation- und Freigaberegeln ist kein belastbarer Cutover-Plan.

Wo liegen die Grenzen des SAP S/4HANA Migration Cockpit?

Das Migration Cockpit standardisiert viele technische Aufgaben – aber es ist kein Universalwerkzeug für jede Datenfrage eines S/4HANA-Programms.

Es ist kein Integrationswerkzeug

SAP stellt ausdrücklich klar, dass das Migration Cockpit nicht dafür gedacht ist:

• Daten dauerhaft synchron zu halten,
• kontinuierliche Datenflüsse abzubilden,
• ein Integrationsszenario aufzubauen.

Nach dem Go-live gehören dauerhafte Datenflüsse deshalb in eine Integrationsarchitektur – beispielsweise mit SAP Integration Suite, APIs oder anderen geeigneten Technologien.

Es löst keine Datenqualitätsprobleme

Fehlerhafte, redundante oder fachlich unklare Daten bleiben ein Business- und Governance-Problem.

Nicht jedes Datenobjekt ist automatisch im Standard verfügbar

Migration Objects hängen von:

• Release,
• Deployment,
• aktiviertem Scope,
• Migrationsansatz

ab.

Es ist nicht für eine vollständige historische Systemkopie gedacht

Der Schwerpunkt liegt auf den für den Start des neuen Systems erforderlichen Business Data.

Historienanforderungen benötigen gegebenenfalls eine separate Strategie.

Custom Objects können zusätzlichen Aufwand erzeugen

Wenn SAP-Standardobjekte nicht ausreichen, können Anpassungen über den Migration Object Modeler oder andere technische Ansätze erforderlich werden.

Es ersetzt keine Cutover Governance

Das Tool kann Migrationen ausführen.

Es entscheidet nicht:

• wann Fachbereiche ihre Arbeit stoppen,
• wann Daten eingefroren werden,
• welche Fehler akzeptabel sind,
• wer den Go-live freigibt.

Wann reicht das Migration Cockpit – und wann braucht man zusätzliche Werkzeuge?

Das Migration Cockpit ist besonders stark, wenn:

• SAP-Standard-Migration Objects den Scope gut abdecken,
• ein initialer Datenload benötigt wird,
• die Quelldaten strukturiert vorbereitet werden können,
• Transformationen überschaubar sind,
• SAP-unterstützte Quellsysteme oder Staging-Szenarien eingesetzt werden.

Zusätzliche Datenmigrationstechnologien können sinnvoll sein, wenn:

• sehr viele Non-SAP-Quellen zusammengeführt werden,
• umfangreiche ETL-Logik erforderlich ist,
• große Datenmengen vorab harmonisiert werden müssen,
• komplexe historische Anforderungen bestehen,
• mehrere Systeme konsolidiert werden,
• Selective Data Transition benötigt wird,
• umfangreiche Custom-Datenmodelle vorhanden sind.

LeverX setzt in Datenmigrationsprojekten neben SAP S/4HANA Migration Cockpit je nach Szenario unter anderem weitere Migrations- und Datenmanagementwerkzeuge ein. Entscheidend sollte jedoch nicht das Tool selbst sein, sondern welcher Ansatz Scope, Datenqualität, Transformation und Cutover am zuverlässigsten abbildet.

Migration-Cockpit-Checkliste für Ihr S/4HANA-Projekt

Vor Beginn der produktiven Datenmigration sollten mindestens folgende Punkte geklärt sein:

Scope

• Welche Daten werden nach S/4HANA migriert?
• Welche Daten werden archiviert oder stillgelegt?
• Welche historischen Daten müssen weiterhin zugänglich bleiben?

Quellen

• Welche SAP- und Non-SAP-Systeme liefern Daten?
• Welches System ist für welches Datenobjekt führend?

Migration Objects

• Welche SAP Migration Objects sind verfügbar?
• Welche Abhängigkeiten bestehen?
• Sind Erweiterungen erforderlich?

Datenqualität

• Sind Dubletten bekannt?
• Sind Pflichtfelder vollständig?
• Welche Daten müssen harmonisiert werden?

Mapping

• Welche Organisationswerte verändern sich?
• Sind Mapping-Regeln fachlich freigegeben?

Ownership

• Wer besitzt welches Datenobjekt?
• Wer bestätigt die fachliche Qualität?

Testing

• Wie viele Testmigrationen sind geplant?
• Wie werden Fehler dokumentiert und nachverfolgt?
• Welche Ergebnisse müssen je Testzyklus erreicht werden?

Reconciliation

• Welche Mengen und Summen werden verglichen?
• Welche Toleranzen sind zulässig?

Cutover

• Wann beginnt der Data Freeze?
• Welche Reihenfolge gilt?
• Welche Laufzeiten werden erwartet?
• Wer erteilt die finale Freigabe?

Wenn diese Fragen erst während des produktiven Loads beantwortet werden, ist das Problem normalerweise nicht das Migration Cockpit – sondern die fehlende Datenmigrationsplanung.

Fazit: Migration Cockpit ist das Werkzeug – nicht die gesamte Datenmigrationsstrategie

Das SAP S/4HANA Migration Cockpit bietet einen standardisierten und eng in SAP S/4HANA integrierten Weg, um Geschäftsdaten in ein neues Zielsystem zu übertragen.

Die aktuelle Lösung ist die Fiori-App Migrate Your Data – Migration Cockpit.

Die frühere Transaktion LTMC ist deprecated, während LTMOM weiterhin für die Erweiterung von Migration Objects verwendet werden kann.

Mit Staging Tables und Direct Transfer stehen unterschiedliche technische Wege zur Verfügung, deren Eignung von Quellsystem, Transformationsbedarf und Projektansatz abhängt.

Der größte Fehler wäre jedoch, Datenmigration auf die Bedienung dieses Tools zu reduzieren.

Eine erfolgreiche S/4HANA-Datenmigration muss zusätzlich beantworten:

Was migrieren wir?
Was lassen wir zurück?
Wie sauber sind die Daten?
Wie werden sie transformiert?
Welche Abhängigkeiten bestehen?
Wie testen und reconciliieren wir?
Wie sieht der produktive Cutover aus?

Das Migration Cockpit setzt diese Entscheidungen technisch um.

Die Qualität der Migration entscheidet sich jedoch schon lange vor dem Klick auf „Migrate“.

Häufige Fragen zum SAP S/4HANA Migration Cockpit

Was ist das SAP S/4HANA Migration Cockpit?

Das SAP S/4HANA Migration Cockpit ist das SAP-Werkzeug für die initiale Übernahme von Business Data nach SAP S/4HANA. Die aktuelle Fiori-App Migrate Your Data – Migration Cockpit unterstützt Migration Projects, Migration Objects, Mapping, Simulation und Datenmigration.

Ist LTMC noch verfügbar?

LTMC ist deprecated und kann laut aktueller SAP-Dokumentation nicht mehr verwendet werden, um Daten nach SAP S/4HANA zu migrieren. Bestehende ältere Projekte können weiterhin angezeigt werden.

Was ist der Nachfolger von LTMC?

Der aktuelle Nachfolger ist die SAP-Fiori-App Migrate Your Data – Migration Cockpit mit der App-ID F3473.

Was ist LTMOM?

LTMOM ist die Transaktion für den SAP S/4HANA Migration Object Modeler. Mit diesem Werkzeug können Migration Objects des Migration Cockpit erweitert werden. Welche Funktionen verfügbar sind, hängt vom jeweiligen Migrationsansatz ab.

Was ist ein SAP Migration Object?

Ein Migration Object beschreibt, wie Daten für ein bestimmtes Business Object in das S/4HANA-Zielsystem übertragen werden. Es enthält unter anderem Quell- und Zielstrukturen, Beziehungen, Feldmappings und Konvertierungsregeln.

Was ist besser: Staging Tables oder Direct Transfer?

Das hängt vom Szenario ab. Staging Tables eignen sich besonders, wenn Daten aus unterschiedlichen Quellen vorbereitet oder umfangreicher transformiert werden müssen. Direct Transfer kann für unterstützte SAP-Quellsysteme die direkte Selektion und Übernahme vereinfachen. Datenqualität, Transformationsbedarf und verfügbare Migration Objects sollten die Entscheidung bestimmen.

Kann das Migration Cockpit Non-SAP-Daten migrieren?

Ja, insbesondere der Staging-Table-Ansatz ermöglicht die Übernahme vorbereiteter Daten aus unterschiedlichen Quellen. Die Staging Tables können über SAP-Templates oder mit anderen Werkzeugen befüllt werden.

Kann das Migration Cockpit historische Daten migrieren?

Nicht als pauschale vollständige Transaktionshistorie. Das Migration Cockpit ist auf den initial benötigten Datenbestand ausgerichtet. In SAP S/4HANA Cloud Public Edition werden beispielsweise Stammdaten, offene Bewegungsdaten und Salden unterstützt, während abgeschlossene historische Bewegungsdaten grundsätzlich nicht über diesen Weg übernommen werden. Für bestimmte historische Salden existieren eigene Migration Objects.

Wird Migration Cockpit bei einer Brownfield Conversion eingesetzt?

Nicht für die eigentliche technische Conversion des bestehenden ECC-Systems. Bei Brownfield wird das vorhandene System auf S/4HANA konvertiert, statt Geschäftsdaten vollständig in ein neues System neu zu laden. Das Migration Cockpit ist besonders auf initiale Datenübernahmen und damit auf Neuimplementierungsszenarien ausgerichtet.

Kann das Migration Cockpit laufende Schnittstellen ersetzen?

Nein. SAP stellt ausdrücklich klar, dass Migration Cockpit nicht für kontinuierliche Datensynchronisation, permanenten Datenaustausch oder Integrationsszenarien konzipiert wurde.

Ist das SAP Migration Cockpit ein separates Datenmigrationstool?

Es ist als SAP-Fiori-App in der SAP-S/4HANA-Datenmigrationsfunktionalität integriert. Welche konkreten Nutzungsrechte und zusätzlichen Werkzeuge ein Unternehmen besitzt, sollte dennoch anhand des jeweiligen SAP-Vertrags und Deployment-Modells geprüft werden.