Wenn in einem SAP-S/4HANA-Projekt der Satz fällt „Für die Datenmigration nutzen wir das Migration Cockpit“, klingt eine zentrale Aufgabe bereits gelöst. Tatsächlich ist damit zunächst der technische Weg in das Zielsystem benannt. Noch nicht beantwortet ist, wer die richtigen Quelldaten auswählt, sie reproduzierbar bereitstellt, fachliche Zuordnungen entscheidet und das Ergebnis im neuen Prozess abnimmt.
Genau an dieser Grenze entstehen Missverständnisse. Das SAP S/4HANA Migration Cockpit stellt Migrationsobjekte, Strukturen, Mapping-Aufgaben, Simulation und Ladefunktionen bereit. Es kennt jedoch nicht automatisch die Bedeutung individueller Altdaten, beseitigt keine fachlichen Widersprüche und entscheidet nicht, ob ein geladener Bestand für den Go-live tatsächlich verwendbar ist.
Dieser Beitrag ordnet das Werkzeug in eine SAP-Datenmigration ein. Er zeigt, welche Leistungen das Migration Cockpit abdeckt, welche Arbeit davor und danach bleibt und welche Informationen eine SAP-Projektleitung benötigt, bevor sie ein internes oder externes Datenmigrationspaket beauftragt.
Die kurze Antwort: Das Cockpit steuert die Übernahme, nicht den gesamten Migrationsauftrag
Die Aufgabengrenze lässt sich in einer Gegenüberstellung erkennen:
| Das Migration Cockpit unterstützt | Das Projekt muss zusätzlich klären und liefern |
|---|---|
| Arbeit mit bereitgestellten Migrationsobjekten und deren Quell- und Zielstrukturen | Welche Geschäftsobjekte und Datensätze für den Start wirklich benötigt werden |
| Staging-basierte oder – je nach Szenario – direkte Datenübernahme | Welcher Migrationsweg zur Bereitstellung, Datenmenge und Systemlandschaft passt |
| Vordefinierte Feldzuordnungen sowie Aufgaben für Werte und Festwerte | Welche fachliche Bedeutung Quellwerte besitzen und welche Zielwerte zulässig sind |
| Simulation, technische Meldungen und Ausführung der Migration | Wie Fehlerursachen in Quelle, Regel oder Zielkonfiguration behoben werden |
| Status- und Ergebnisinformationen für Migrationsobjekte | Welche Mengen, Werte, Beziehungen und Geschäftsprozesse fachlich abgenommen werden |
| Begrenzte Erweiterung unterstützter Migrationsobjekte | Wie nicht abgedeckte Informationen, Sonderlogiken und historische Zugriffe behandelt werden |
Das Werkzeug ist damit ein wesentlicher Teil der Ausführung. Die Migrationsleistung beginnt aber vor dem ersten Upload und endet nicht mit einer technisch erfolgreichen Meldung.
Zuerst muss der Übergangspfad feststehen
„Migration nach S/4HANA“ kann verschiedene Vorhaben bezeichnen. Bei einer Neueinführung wird ein initialer Datenbestand in ein neu aufgebautes Zielsystem geladen. Bei einer Systemkonvertierung wird ein vorhandenes SAP-System technisch umgestellt. Daneben gibt es selektive Übergänge und Konsolidierungsszenarien. Diese Wege unterscheiden sich darin, welche Daten bewegt, technisch konvertiert oder aus dem bestehenden System fortgeführt werden.
Dieser Beitrag behandelt den initialen Datenaufbau einer S/4HANA-Neueinführung. Dafür ist das Migration Cockpit vorgesehen. SAP beschreibt den direkten Transfer aus bestimmten SAP-Quellsystemen ausdrücklich als initiale Beladung und nicht als Werkzeug für eine laufende Synchronisation oder dauerhafte Integration. Wer eigentlich eine Systemkonvertierung oder einen kontinuierlichen Datenaustausch plant, braucht daher zuerst eine andere technische Einordnung.
Zusätzlich müssen Deployment und Release benannt sein. Die App „Migrate Your Data“ steht laut SAP Learning für On-Premise-, Private-Cloud- und Public-Cloud-Deployments bereit; Funktionen und verfügbare Migrationsobjekte können sich jedoch unterscheiden. Eine Aussage wie „das Cockpit kann Kunden, Materialien und Aufträge übernehmen“ ist deshalb erst belastbar, wenn Zielvariante, Release und konkrete Objektdokumentation geprüft wurden.
Was ein SAP-Migrationsobjekt tatsächlich bereitstellt
Ein Migrationsobjekt ist mehr als eine Importtabelle. SAP beschreibt darin, wie ein bestimmtes Geschäftsobjekt nach S/4HANA übertragen wird. Dazu können gehören:
- Quell- und Zielstrukturen sowie ihre Beziehungen,
- relevante Felder und bereits ausgelieferte Zuordnungen,
- Konvertierungs- und Wertezuordnungen,
- Voraussetzungen und Abhängigkeiten zu Vorgängerobjekten,
- technische Prüfungen während Simulation und Migration sowie
- Hinweise auf die Zielanwendung, in der das Ergebnis anschließend kontrolliert werden soll.
Im Cockpit legt das Team ein Migrationsprojekt an, wählt Objekte, stellt Daten bereit, bearbeitet offene Mapping-Aufgaben und kann den Lauf simulieren. Nach der Migration führen Ergebnisverknüpfungen in die relevante Zielanwendung. Für einige freigegebene Objekte lassen sich Strukturen oder Feldzuordnungen über den Migration Object Modeler erweitern.
Diese Funktionen reduzieren technische Eigenentwicklung. Sie ersetzen aber nicht die Übersetzung vom individuellen Altsystem in die erwartete Objektstruktur. Ein ausgeliefertes Zielfeld beantwortet beispielsweise nicht, aus welcher von mehreren Quellen der richtige Wert kommt, wie widersprüchliche Schlüssel zusammengeführt werden oder wer einen Standardwert fachlich freigeben darf.
Drei Bereitstellungswege verändern Aufwand und Verantwortlichkeiten
Für die SAP-Datenmigration in S/4HANA Cloud Private Edition beschreibt SAP mehrere Wege, Daten in das Migration Cockpit zu bringen. Welche davon im konkreten Deployment und Release verfügbar sind, muss anhand der aktuellen SAP-Dokumentation geprüft werden.
| Bereitstellungsweg | Technischer Grundgedanke | Arbeit außerhalb des Cockpits |
|---|---|---|
| Lokale Staging-Templates | Daten werden in bereitgestellte XML- oder CSV-Templates eingetragen und in das Cockpit geladen. | Extraktion, Zusammenführung, Bereinigung und reproduzierbare Befüllung der Dateien |
| Remote SAP HANA Staging | Generierte Stagingtabellen liegen in einer separaten SAP-HANA-Datenbank und werden mit dem Ziel verbunden. | Einrichtung der Umgebung und Integration sowie eigener ETL-Prozess aus den Quellsystemen in die Stagingtabellen |
| Direkter Transfer aus SAP | Ein kompatibles SAP-Quellsystem wird über eine definierte Verbindung angebunden; verfügbare Objekte werden direkt selektiert und übertragen. | Technische Voraussetzungen, Berechtigungen, zulässige Selektion, Datenbereinigung und fachliche Kontrolle des übertragenen Bestands |
Lokale Templates benötigen weniger technische Infrastruktur, können bei vielen Quellen, großen Datenmengen oder wiederholten Testläufen aber schnell zu manueller Arbeit führen. Remote Staging verlangt mehr Aufbau, ermöglicht dafür eine stärker automatisierte Datenbereitstellung. Der direkte Transfer kann die Extraktion aus einem passenden SAP-Quellsystem vereinfachen, ist jedoch an unterstützte Ausgangssysteme, Objekte und Auswahlmöglichkeiten gebunden.
Die Entscheidung sollte deshalb nicht allein nach dem vermeintlich schnellsten ersten Upload fallen. Maßgeblich ist, welcher Weg über mehrere Teststände hinweg reproduzierbar bleibt, Korrekturen gezielt übernimmt und innerhalb des Cut-over-Fensters erneut ausgeführt werden kann.
Ob dafür eine zusätzliche Plattform wie SAP Data Services oder Syniti ADMM benötigt wird oder ein schlanker Weg aus kontrollierter Extraktion, SQL und Migration Cockpit ausreicht, vertieft unser Beitrag zur Auswahl des passenden SAP Migration Tools.
Die sichtbaren Migrationsobjekte sind noch kein bestätigter Scope
Das Cockpit zeigt Migrationsobjekte passend zu den aktiven Geschäftsprozessen im Ziel. Diese Liste ist ein wichtiger Ausgangspunkt, aber noch keine vollständige fachliche Beauftragung. Für jedes Objekt bleibt zu entscheiden:
- Welche Organisationseinheiten, Werke, Buchungskreise oder weiteren Abgrenzungen gehören zum Projekt?
- Welche Datensätze werden für die künftigen Prozesse benötigt?
- Welche offenen Vorgänge können im Ziel fortgeführt werden?
- Welche abhängigen Objekte müssen vorher bereitstehen?
- Was bleibt außerhalb des operativen Zielsystems zugänglich?
Die Grenzen sind außerdem produktspezifisch. Für SAP S/4HANA Cloud Public Edition nennt SAP aktuell Stammdaten, offene Bewegungsdaten und Salden als typische initiale Bestände. Historische Bewegungsdaten und bestimmte Vorgänge mit Folgebelegen können über diesen Migrationsweg nicht übernommen werden. Daraus folgt keine allgemeine Regel für jedes SAP-Deployment, wohl aber eine wichtige Projektaufgabe: Die konkrete Objektdokumentation muss vor der Scope-Freigabe mit den benötigten Datenbeständen abgeglichen werden.
Wie sich operative Übernahme, Bereinigung, externer Zugriff und bewusster Ausschluss voneinander trennen lassen, zeigt unser Beitrag zur Frage, welche Daten beim ERP-Wechsel ins neue System gehören.
Fünf Arbeitspakete beginnen vor dem ersten Cockpit-Lauf
1. Quellen und Datenverantwortung klären
Ein SAP-Migrationsobjekt definiert die erwartete Zielstruktur, aber nicht automatisch die maßgebliche Quelle. Kundeninformationen können beispielsweise aus ERP, CRM, Tabellen oder ergänzenden Anwendungen stammen. Das Projekt muss festlegen, welche Quelle für welche Information führend ist, wie sie technisch erreichbar ist und wer Zweifelsfälle entscheiden darf.
2. Quelldaten profilieren und bereinigen
Bevor Daten in ein Template oder eine Stagingtabelle gelangen, müssen fehlende Pflichtwerte, Dubletten, ungültige Formate und widersprüchliche Schlüssel sichtbar sein. Nicht jeder Befund wird gleich behandelt: Manche Korrekturen gehören ins Quellsystem, andere in eine wiederholbare Transformation, weitere benötigen eine fachliche Einzelfallentscheidung.
Eine manuell korrigierte Upload-Datei löst das Problem nur für diesen einen Stand. Für mehrere Testläufe muss nachvollziehbar sein, aus welcher Quelle und mit welcher Regel der korrigierte Wert erneut erzeugt wird.
3. Fachliches Mapping aufbauen
Das Mapping im Cockpit verarbeitet die Zuordnungen, die das Projekt vorgibt oder bestätigt. Die fachliche Vorarbeit beantwortet jedoch erst, ob Quell- und Zielwert dasselbe bedeuten. Das betrifft besonders Organisationseinheiten, Konten, Einheiten, Status, Partnerrollen, Klassifikationen und kundeneigene Felder.
Zu jeder nicht direkten Zuordnung gehören Regel, Begründung, Entscheider und Prüferwartung. So kann ein Fehler aus der Simulation auf eine technische Formatabweichung, eine fehlende Zielkonfiguration oder eine falsche fachliche Regel zurückgeführt werden.
4. Zielsystem und Berechtigungen vorbereiten
Das Ziel muss die erwarteten Daten aufnehmen können. Benötigte Konfiguration, Wertelisten, Organisationseinheiten und Vorgängerobjekte müssen rechtzeitig vorhanden sein. Zusätzlich braucht das Migrationsteam nicht nur Zugriff auf die App „Migrate Your Data“, sondern auch die Berechtigung für die Zielanwendungen, in denen migrierte Datensätze geprüft werden.
Fehlt diese Vorbereitung, produziert das Cockpit zwar Meldungen, aber keinen entscheidungsfähigen Test. Das Team kann dann nicht sicher unterscheiden, ob die Ursache in den Daten, im Mapping, in der Objektfolge oder im noch unfertigen Ziel liegt.
5. Abnahme und Cut-over definieren
Vor dem ersten relevanten Test muss feststehen, welche Ergebnisse für das jeweilige Objekt erwartet werden. Dazu gehören je nach Datenart Datensatzmengen, Summen, Schlüsselbeziehungen, fachliche Stichproben und die Ausführung konkreter Zielprozesse. Außerdem muss geregelt sein, wie Änderungen zwischen Test und Go-live erneut extrahiert und verarbeitet werden.
Diese Festlegungen gehören in ein ausführbares Datenmigrationskonzept. Das Cockpit liefert dafür technische Ergebnisse und Statusinformationen; die fachlichen Abnahmeregeln und Entscheidungsrechte bleiben beim Projekt.
Warum eine erfolgreiche Simulation noch keine fachliche Abnahme ist
Die Simulation ist wertvoll, weil sie technische Prüfungen und Meldungen erzeugt, bevor Daten endgültig migriert werden. Sie zeigt beispielsweise, ob bereitgestellte Werte verarbeitet werden können und welche Mapping-Aufgaben oder Fehler noch offen sind.
Sie beantwortet jedoch nicht vollständig, ob der Datensatz im neuen Geschäftsprozess richtig funktioniert. Ein Kunde kann technisch angelegt sein und trotzdem eine falsche Vertriebszuordnung besitzen. Ein Material kann alle Pflichtfelder erfüllen, aber mit einer unpassenden Einheit oder Bewertung im Ziel stehen. Ein offener Vorgang kann geladen sein, ohne fachlich korrekt weiterbearbeitet werden zu können.
Eine belastbare Abnahme verbindet deshalb drei Ebenen:
- Cockpit-Ergebnis: Welche Datensätze wurden verarbeitet, welche Meldungen bleiben und welche Ziel-IDs wurden erzeugt?
- Datenabgleich: Stimmen erwartete Mengen, Summen, Schlüssel, Beziehungen und ausgewählte Werte zwischen bereitgestelltem Stand und Ziel?
- Prozessprüfung: Können berechtigte Anwender die vorgesehenen Geschäftsvorgänge mit den migrierten Daten korrekt ausführen?
Die SAP-Dokumentation verweist je Migrationsobjekt auf eine Post-Processing-Anwendung zur Kontrolle im Ziel. Diese Prüfung sollte nicht als informelles Nachsehen enden. Ihr Ergebnis braucht einen benannten Datenstand, dokumentierte Abweichungen und eine fachliche Freigabe.
Ein Migrationsobjekt ist noch keine kalkulierbare Arbeitseinheit
Zwei Migrationsobjekte können im Cockpit ähnlich aussehen und außerhalb des Werkzeugs sehr unterschiedlichen Aufwand erzeugen. Ein Objekt lässt sich möglicherweise aus einer sauberen Quelle nahezu direkt bereitstellen. Ein anderes benötigt mehrere Quellsysteme, komplexe Umwertungen, kundeneigene Felder und zahlreiche abhängige Datensätze.
Für Planung und Angebot sollte jedes priorisierte Objekt daher um folgende Angaben ergänzt werden:
| Angabe | Warum sie benötigt wird |
|---|---|
| Deployment, Release und Migrationsweg | Bestimmt verfügbare Funktionen, Objekte und technische Voraussetzungen |
| Quellen und Extraktionsweg | Macht sichtbar, wie der Cockpit-Eingang tatsächlich erzeugt wird |
| Auswahlregel und Datenmenge | Begrenzt den zu analysierenden, aufzubereitenden und zu prüfenden Bestand |
| Strukturen, Sonderfelder und Transformationen | Zeigt, wie weit Standardzuordnungen tragen und welche Regeln zusätzlich entstehen |
| Vorgänger und Zielvoraussetzungen | Verhindert, dass ein Objekt isoliert geplant wird, obwohl es andere Daten benötigt |
| Test- und Abnahmetiefe | Bestimmt die notwendigen Schleifen zwischen Bereitstellung, Simulation, Korrektur und Freigabe |
Erst mit diesen Informationen lässt sich entscheiden, ob das Objekt direkt umgesetzt werden kann oder zunächst eine begrenzte Analyse benötigt.
Ein sinnvolles erstes Arbeitspaket endet mit einem geprüften Referenzobjekt
Wenn Quelllage und Aufwand noch unsicher sind, ist ein kleines, vollständiges Arbeitspaket aussagekräftiger als eine pauschale Schätzung für sämtliche Migrationsobjekte. Dafür wird ein repräsentatives Objekt durch die entscheidenden Stationen geführt:
- aktuelle Objektdokumentation und Zielvoraussetzungen prüfen,
- Quelle und Auswahlregel festlegen,
- repräsentative Daten analysieren und aufbereiten,
- Mapping- und Transformationsentscheidungen dokumentieren,
- Daten über den vorgesehenen Weg bereitstellen,
- Simulation und Korrekturschleife durchführen sowie
- das Ergebnis in Zielanwendung und Geschäftsprozess prüfen.
Das Ergebnis ist nicht nur ein erfolgreicher Testlauf. Es umfasst eine belastbare Methodenauswahl, bekannte Rollen, reale Befunde zur Datenqualität, einen wiederholbaren Bereitstellungsweg und eine bessere Grundlage für die Schätzung der übrigen Objekte.
Wann zusätzliche Unterstützung für die SAP-Datenmigration sinnvoll wird
Ein zusätzliches Arbeitspaket ist besonders dann sinnvoll, wenn der SAP-Partner Zielkonfiguration und Cockpit bedient, aber die Kette aus Altquellen, Datenaufbereitung, fachlichem Mapping und objektübergreifender Prüfung noch keinen eindeutigen Eigentümer hat. Ein externer Datenmigrationsdienstleister kann diese Lücke zwischen Quellsystem, Fachbereichen und SAP-Ziel strukturieren und technisch umsetzen.
Ist die Kette intern bereits klar besetzt, alle Quellen sind beherrscht und der SAP-Partner übernimmt neben dem Laden auch Mapping, Testorganisation und Cut-over, ist zusätzliche Unterstützung nicht automatisch nötig. Entscheidend ist nicht die Zahl der beteiligten Anbieter, sondern eine geschlossene Verantwortung für den Weg von der freigegebenen Quelle bis zum fachlich nutzbaren Zielbestand.
Bei der Auswahl sollte daher nicht nur nach Erfahrung mit dem Migration Cockpit gefragt werden. Relevant ist, wer Quellanalyse, ETL, Regelentscheidungen, Fehlerursachen, Testevidenz und Übergabe tatsächlich übernimmt. Unsere zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern helfen, diese Leistungsgrenze sichtbar zu machen.
Welche Lücke besteht zwischen Ihren Quellen und dem Migration Cockpit?
Das SAP S/4HANA Migration Cockpit ist ein leistungsfähiger Ausführungsrahmen für die initiale Datenübernahme. Es wird jedoch erst dann zu einem belastbaren Migrationsprozess, wenn Scope, Quellen, Aufbereitung, Mapping, Zielvoraussetzungen und Abnahme miteinander verbunden sind.
Für eine erste Einordnung reichen meist das geplante S/4HANA-Deployment und Release, die bekannten Quellsysteme, eine vorläufige Liste der Migrationsobjekte sowie der nächste Testtermin. Daran lässt sich erkennen, ob die technische Route bereits trägt, welche Projektarbeit noch unbesetzt ist und ob ein abgegrenztes Referenzobjekt der sinnvollste nächste Schritt ist.