SAP Migration Tool: Wann SQL und Migration Cockpit ausreichen – und wann Zusatztools sinnvoll sind

Wer eine Datenmigration nach SAP S/4HANA plant, stößt früh auf eine scheinbar einfache Beschaffungsfrage: Reichen das SAP S/4HANA Migration Cockpit und die vorhandenen Datenbankwerkzeuge aus – oder braucht das Projekt zusätzlich SAP Data Services, Syniti ADMM oder eine andere Migrationsplattform?

Die richtige Antwort lautet nicht pauschal „ohne Tool“ oder „mit Tool“. Entscheidend ist, welche Aufgaben tatsächlich gelöst werden müssen. Für eine überschaubare Neueinführung mit beherrschbaren Quellen kann ein schlanker Ansatz aus kontrollierter Extraktion, nachvollziehbarer SQL-Transformation, reproduzierbaren Prüfungen und dem SAP Migration Cockpit sehr leistungsfähig sein. In einem internationalen Programm mit vielen Quellsystemen, parallelen Wellen, umfangreicher Datenqualitätsarbeit und zentraler Governance kann eine zusätzliche Plattform dagegen einen messbaren Nutzen stiften.

Dieser Beitrag trennt die Aufgaben sauber voneinander. Er zeigt, was LSMW, SAP Data Services und SAP Advanced Data Migration and Management by Syniti leisten, welche Kostenblöcke bei der Entscheidung häufig übersehen werden und unter welchen Bedingungen ein schlanker Standardansatz trägt.

Die kurze Antwort: Das kleinste tragfähige Werkzeugset ist meistens die beste Wahl

Ein zusätzliches SAP Migration Tool ist sinnvoll, wenn es ein konkretes Problem nachweisbar besser löst als die bereits vorhandenen Mittel. Das kann beispielsweise die Steuerung vieler Migrationswellen, eine zentrale Zusammenarbeit zahlreicher Teams, wiederverwendbare Datenqualitätsregeln oder die Anbindung einer stark heterogenen Systemlandschaft sein.

Es ist dagegen kein Selbstzweck. Wenn die Transformationen in verständlichem SQL abgebildet werden können, die Zahl der Quellen und Migrationsobjekte beherrschbar ist und das Ziel über das Migration Cockpit geladen wird, kann eine weitere Plattform zusätzliche Lizenz-, Einführungs- und Betriebsarbeit erzeugen, ohne das fachliche Mapping oder die Abnahme zu ersetzen.

Wir entscheiden deshalb nicht zuerst über einen Produktnamen. Wir prüfen zuerst den Migrationsweg, die Datenobjekte, die Quellen, die Wiederholungszyklen und die erforderliche Nachweisführung. Daraus ergibt sich das passende Werkzeugset.

Extraktion, Transformation und Beladung sind drei verschiedene Entscheidungen

Viele Tooldiskussionen bleiben unklar, weil drei Aufgaben unter dem Begriff „Datenmigration“ zusammengefasst werden:

1. Extraktion: Die benötigten Daten werden aus SAP ECC, einem anderen ERP-System, Datenbanken, Dateien oder weiteren Anwendungen reproduzierbar bereitgestellt.
2. Transformation und Qualität: Quellfelder werden Zielstrukturen zugeordnet, Werte bereinigt, Schlüssel übersetzt, Formate vereinheitlicht und fachliche Regeln angewendet.
3. Beladung und Zielprüfung: Die vorbereiteten Daten werden über die vorgesehene SAP-Schnittstelle angelegt, simuliert, verarbeitet und im Ziel fachlich geprüft.

Für die dritte Ebene ist bei einer S/4HANA-Neueinführung das SAP S/4HANA Migration Cockpit ein zentraler Ausführungsrahmen. Es stellt Migrationsobjekte, Mapping-Aufgaben, Simulationen, technische Meldungen und Ladefunktionen bereit. Es entscheidet aber nicht automatisch, welche Altdaten richtig sind und wie ein kundenspezifisches Quellfeld fachlich in das Ziel übersetzt werden muss.

Ein externes ETL- oder Migrationsprodukt betrifft vor allem die ersten beiden Ebenen und die übergreifende Projektsteuerung. Deshalb ist die Frage nicht, ob das Migration Cockpit „genug Funktionen“ hat. Die Frage lautet, wie die Daten zuverlässig bis zu seinem Eingang gelangen und wie Quelle, Übergabestand und Ziel anschließend miteinander abgeglichen werden.

So sieht ein schlanker SAP-Migrationsansatz aus

Ein schlanker Ansatz bedeutet nicht, Daten einmalig in Excel zu korrigieren und anschließend auf einen erfolgreichen Import zu hoffen. Er braucht dieselben kontrollierten Entscheidungen und Tests wie ein plattformgestützter Prozess. Der technische Weg bleibt nur kleiner und direkter:

1. Quellsysteme, Tabellen, Felder und Verantwortlichkeiten werden dokumentiert.
2. Die benötigten Datensätze werden über einen freigegebenen, möglichst lesenden Zugriff extrahiert.
3. Mapping- und Transformationsregeln werden in SQL und ergänzender Dokumentation nachvollziehbar umgesetzt.
4. Das Ergebnis wird als CSV-Datei oder über passende Stagingtabellen für das Ziel bereitgestellt.
5. Das Migration Cockpit simuliert und verarbeitet die vorbereiteten Migrationsobjekte.
6. SQL-Prüfungen und fachliche Tests gleichen Mengen, Summen, Schlüssel, Beziehungen und relevante Geschäftsvorgänge ab.

Das SQL ist dabei nicht nur ein technisches Hilfsmittel. Es dokumentiert, welche Quellen und Felder verwendet wurden, welche Filter gelten, wie Zielspalten entstehen und welche Datensätze ausgeschlossen werden. Eine Regel lässt sich erneut auf einen aktuellen Datenstand anwenden, statt vor jedem Testlauf manuell dieselben Dateien zu bearbeiten.

Dieser Ansatz passt besonders gut zu relational aufgebauten Quellen, klar abgegrenzten Migrationsobjekten und Projekten, in denen die technische Datenlogik bewusst sichtbar bleiben soll. Er verlangt allerdings qualifizierte Quellanalyse, sauberes Mapping und eine belastbare Teststrategie. Diese Arbeit verschwindet durch den Verzicht auf eine zusätzliche Plattform nicht.

Direkter SQL-Zugriff auf SAP: möglich, aber nicht pauschal richtig

Bei einem nicht von SAP stammenden Altsystem ist ein lesender Datenbankzugriff häufig der geradlinigste Extraktionsweg. Bei SAP ECC muss genauer geprüft werden. SAP beschreibt die direkte Extraktion aus der zugrunde liegenden Datenbank als technisch schnell, empfiehlt für SAP-Business-Suite-Daten aber den Zugriff über die Anwendungsschicht. Als Gründe nennt SAP unter anderem Lizenzbedingungen und Einschränkungen bei Pool- und Clustertabellen. Die konkrete Freigabe durch Systemverantwortliche und Lizenzprüfung gehört deshalb vor den ersten produktiven Zugriff.

Für transparente Tabellen kann SQL technisch geeignet sein, sofern Berechtigungen, Mandantentrennung, Semantik und Systembetrieb berücksichtigt werden. Ein Datenbankfeld ist jedoch nicht automatisch ein fachlich freigegebenes Migrationsfeld. SAP-Anwendungslogik, archivierte Bestände, kundeneigene Erweiterungen und indirekte Beziehungen müssen zusätzlich verstanden werden.

Bei klassischen Pool- und Clustertabellen reicht Native SQL nicht aus. SAP weist darauf hin, dass dafür Strukturinformationen aus dem ABAP Dictionary und die Open-SQL-Clusterschnittstelle benötigt werden. Seit SAP S/4HANA 1809 werden klassische Pool- und Clustertabellen im Zuge der Umstellung zu transparenten Tabellen transformiert. Davon zu unterscheiden sind Export-/Importtabellen wie STXL, die weiterhin ABAP-spezifisch serialisierte Datencluster enthalten können.

Das ist kein zwingendes Argument für eine große Migrationssuite. Wenn ein benötigtes Objekt nicht sicher über SQL gelesen werden kann, ist häufig ein kleiner, gezielt geprüfter ABAP- oder RFC-Extractor der bessere Ausnahmeweg. Der übrige Prozess kann weiterhin mit SQL, Dateien beziehungsweise Staging und dem Migration Cockpit arbeiten. Entscheidend ist, dass jeder Extraktionsweg reproduzierbar, lesend und gegen ein fachlich erwartetes Ergebnis geprüft wird.

Warum LSMW keine zukunftssichere Antwort für S/4HANA ist

Die Legacy System Migration Workbench wurde für frühere SAP-Generationen entwickelt. Sie kann unter bestimmten On-Premise-Bedingungen technisch noch vorhanden sein, ist aber nicht die von SAP empfohlene Lösung für eine neue Datenmigration nach S/4HANA.

In der aktuellen Simplification List für SAP S/4HANA 2025 beschreibt SAP die Verwendung von LSMW als eingeschränkt, nicht empfohlen und in der Verantwortung des Kunden. Als konkrete Risiken nennt SAP unter anderem geänderte Schnittstellen, nicht mehr passende Batch-Input-Verfahren, fehlende Aufzeichnungen für neue Fiori-Oberflächen und das geänderte Business-Partner-Datenmodell. Vor einem LSMW-Einsatz soll immer geprüft werden, ob ein passendes Objekt im Migration Cockpit verfügbar ist.

Hinzu kommt eine methodische Grenze: LSMW beantwortet nicht automatisch die Quellfrage. Auch ein funktionierendes LSMW-Objekt benötigt bereitgestellte Quelldaten, fachliche Zuordnungen, Konvertierungsregeln und eine eigene Ergebnisprüfung. Wer aus SAP ECC oder einem Fremdsystem nach S/4HANA migriert, sollte deshalb nicht „LSMW oder SQL“ vergleichen. SQL beziehungsweise ein kontrollierter Extractor bereitet die Quelldaten auf; das Migration Cockpit übernimmt den vorgesehenen Zielimport. LSMW wäre lediglich ein älterer alternativer Ladeweg.

Was SAP Data Services zusätzlich bietet

SAP Data Services, häufig noch als BODS bezeichnet, ist deutlich mehr als ein Werkzeug für einen einzelnen SAP-Import. SAP beschreibt es als Enterprise-Lösung für Datenintegration, Datenqualität, Profiling und Textverarbeitung. Es verbindet unterschiedliche Quellen und Ziele, modelliert ETL-Abläufe grafisch und bringt unter anderem Laufzeitumgebung, Repositories, Management Console, Fehlerbehandlung, Parallelisierung und wiederverwendbare Transformationen mit.

Das kann einen erheblichen Mehrwert liefern, wenn ein Projekt:

• viele heterogene Quellen und große Datenmengen verarbeitet,
• komplexe Jobs mit Abhängigkeiten, Wiederanlauf und zentraler Überwachung benötigt,
• Adressbereinigung, Matching, Dublettenerkennung oder wiederverwendbare Datenqualitätsregeln einsetzen will,
• SAP-Anwendungsdaten über eine etablierte ABAP-Schnittstelle extrahieren muss oder
• Data Services bereits produktiv betreibt und die notwendigen Kenntnisse vorhanden sind.

Genau diese Fähigkeiten verursachen aber auch einen eigenen Lösungsumfang. Data Services benötigt eine passende Lizenzsituation, Installation beziehungsweise Infrastruktur, Repositories, Job Server, Berechtigungen, Transport- und Betriebskonzepte sowie Fachkenntnisse im Werkzeug. Für eine begrenzte einmalige Migration kann dieser Aufbau größer sein als das Problem, das er lösen soll. Ist die Plattform bereits vorhanden oder soll sie nach dem Go-live für weitere Datenintegrations- und Qualitätsaufgaben genutzt werden, fällt die Bewertung anders aus.

Was Syniti ADMM zusätzlich bietet

SAP Advanced Data Migration and Management by Syniti, kurz SAP ADMM, positioniert sich als umfassende Plattform für SAP-Transformationen. Sie verbindet technische Migration mit Prozesssteuerung, Datenqualität, Wissenswiederverwendung und der Zusammenarbeit von Datenverantwortlichen. Projektwellen, Prozessbereiche und Migrationsobjekte werden in einem gemeinsamen Rahmen geführt; vorgefertigte Inhalte und Automatisierung sollen wiederholte Migrationsschritte beschleunigen.

Das ist besonders interessant für:

• globale Programme mit vielen Gesellschaften, Ländern oder Migrationswellen,
• zahlreiche Quell- und Zielsysteme sowie parallel arbeitende Teams,
• eine zentrale, programmweite Governance für Regeln, Freigaben und Datenqualität,
• stark wiederverwendbare Mappings und Qualitätslogik über mehrere Roll-outs sowie
• Vorhaben, bei denen eine Plattform und eine zugehörige Methodik ausdrücklich Teil der Programmorganisation sein sollen.

Für ein kleineres oder klar abgegrenztes Greenfield-Projekt muss dieser Nutzen gegen Subscription beziehungsweise Lizenz, Einführung, Konfiguration, Schulung, Plattformbetrieb und die Abhängigkeit von spezialisierten Rollen abgewogen werden. Eine umfangreiche Plattform kann Transparenz schaffen. Sie kann aber auch eine zweite technische und methodische Ebene zwischen Quelldaten, Projektteam und Migration Cockpit einziehen. Ob das wirtschaftlich ist, hängt von Programmgröße und Wiederverwendung ab – nicht allein vom Produktnamen.

Vier Ansätze im direkten Vergleich

Ansatz	Was er besonders gut abdeckt	Wann er typischerweise passt
SQL, gezielte Extractor-Ausnahmen und Migration Cockpit	Sichtbare Transformationen, direkte Prüfungen, wenige technische Schichten und Nutzung des vorgesehenen SAP-Zielimports	Beherrschbare Quellen und Objekte, klarer Greenfield-Scope, verfügbares SQL- und SAP-Wissen, nachvollziehbare Testzyklen
SAP Data Services	Enterprise-ETL, viele Konnektoren, Datenprofiling und -qualität, Jobsteuerung, Wiederanlauf und zentrale Repositories	Heterogene Landschaften, große oder komplexe Datenflüsse, vorhandene Plattform und Kenntnisse, Nutzung über die einmalige Migration hinaus
SAP ADMM by Syniti	Durchgängige Migrationsmethodik, Wellen- und Objektsteuerung, Zusammenarbeit, Datenqualität und Wiederverwendung von Wissen	Große, internationale oder mehrwellige Transformationsprogramme mit zentraler Governance und vielen Beteiligten
LSMW	Vorhandene ältere Ladeobjekte und bekannte Verfahren in einzelnen On-Premise-Ausnahmen	Nur nach Prüfung des Migration-Cockpit-Inhalts, der verwendeten Schnittstelle und der S/4HANA-Eignung; nicht als strategischer Standard

Diese Optionen schließen einander nicht vollständig aus. Data Services oder Syniti können Daten vorbereiten und das Migration Cockpit weiterhin als unterstützten Ladeweg verwenden. Umgekehrt kann ein SQL-basierter Kernprozess für einzelne SAP-Sonderfälle einen kleinen ABAP-Extractor ergänzen. Eine gute Architektur besteht nicht aus möglichst wenigen Produktnamen, sondern aus möglichst wenigen unnötigen Übergaben.

Der Kostenvergleich beginnt nicht beim Lizenzpreis

Öffentlich belastbare Pauschalpreise für SAP Data Services oder Syniti ADMM lassen sich nicht seriös auf jedes Projekt übertragen. Angebote hängen unter anderem von vorhandenen Verträgen, Deployment, Nutzungsumfang und Dienstleistungen ab. Für eine belastbare Entscheidung sollten mindestens diese Kostenblöcke gegenübergestellt werden:

1. Produktkosten: zusätzliche Lizenz, Subscription, Datenvolumen- oder Nutzerkomponenten und gegebenenfalls notwendige Zusatzprodukte.
2. Einführung: Installation, Cloud-Bereitstellung, Konfiguration, Sicherheitsfreigaben, Verbindungen, Repositories und Transportwege.
3. Kompetenzaufbau: Schulung, externe Spezialisten und die Zeit, bis das Team produktiv mit dem Werkzeug arbeiten kann.
4. Umsetzung: Quellanalyse, Mapping, Transformationsregeln, Datenbereinigung und Fehlerbehebung. Diese Arbeit entsteht bei jedem Ansatz.
5. Betrieb: Überwachung, Patches, Berechtigungen, Jobsteuerung, Support und Wissenstransfer.
6. Tests und Nachweis: Mengen- und Summenabgleiche, fachliche Stichproben, Prozessprüfungen und dokumentierte Freigaben.
7. Wiederverwendung: Nutzen die Organisation und weitere Roll-outs die Plattform nach der ersten Migration tatsächlich weiter?

Der schlanke Ansatz vermeidet eine zusätzliche Produktschicht und kann deshalb bei passendem Scope verhältnismäßig günstig sein. Seine Kosten liegen hauptsächlich in qualifizierter Analyse, Mapping, Skripterstellung und Test. Bei sehr vielen Wellen kann sich dieses Verhältnis umkehren: Dann können zentrale Orchestrierung, standardisierte Workflows und wiederverwendbare Regeln einer Plattform mehr Aufwand vermeiden, als ihr Betrieb verursacht.

Ein wirtschaftlicher Vergleich darf deshalb weder „SQL kostet nichts“ noch „eine Plattform automatisiert die Migration“ unterstellen. SQL benötigt Fachkompetenz und Qualitätssicherung. Eine Plattform benötigt ebenfalls Fachkompetenz und nimmt dem Projekt die fachlichen Entscheidungen nicht ab.

Wo KI den schlanken Ansatz sinnvoll beschleunigt

Eine wichtige Veränderung gegenüber früheren Migrationsprojekten ist die KI-gestützte Arbeit mit technischem Wissen. Freigegebene Systemdokumentationen, Datenbankmetadaten, Tabellenbeziehungen, Mapping-Entscheidungen, Testregeln und bekannte Fehlermuster können in einer projektspezifischen Wissensbasis zusammengeführt werden. Auf dieser Grundlage kann KI insbesondere unterstützen bei:

• der Suche nach relevanten Tabellen, Feldern und Beziehungen,
• der Vorbereitung lesender SQL-Abfragen und kleiner ABAP-Extractor-Ausnahmen,
• der Übersetzung dokumentierter Mappingregeln in Transformationen,
• der Erstellung von Prüfungen für Pflichtfelder, Schlüssel, Mengen und Summen,
• der Einordnung technischer Fehlermeldungen sowie
• der konsistenten Dokumentation von Quellen, Regeln und Testergebnissen.

Dafür müssen nicht automatisch vollständige Produktivdaten an ein KI-System übergeben werden. Für viele Aufgaben reichen freigegebene Dokumentationen, Metadaten und anonymisierte Beispiele. Welche Inhalte verarbeitet werden dürfen, über welchen Geschäftsdienst dies geschieht und welche Speicher- und Löschregeln gelten, muss vorab mit dem Kunden vereinbart und technisch begrenzt werden.

Die KI ersetzt weder die SAP-Semantik noch die fachliche Freigabe. Sie kann auch ein ABAP-spezifisches Datencluster nicht allein durch die Behauptung „das ist ein Blob“ zuverlässig in ein universelles SQL-Problem verwandeln. Sie beschleunigt die Vorbereitung von Code und Tests. Die anschließend verwendeten Skripte müssen geprüft, reproduzierbar ausgeführt und gegen bekannte Soll-Ergebnisse validiert werden.

Der Vorteil entsteht damit nicht durch eine Blackbox, sondern durch schneller nutzbares Projektwissen bei weiterhin sichtbarer Transformations- und Prüfungslogik.

Sieben Fragen entscheiden über das passende SAP Migration Tool

Bevor ein zusätzliches Produkt beschafft oder ausgeschlossen wird, sollten Projektleitung, IT und Datenmigration diese Fragen beantworten:

1. Handelt es sich um eine Neueinführung mit initialer Beladung, eine Systemkonvertierung oder einen selektiven Übergang?
2. Wie viele Quellsysteme, Gesellschaften, Länder, Migrationswellen und parallele Teams müssen gesteuert werden?
3. Sind die benötigten Daten relational und kontrolliert zugänglich, oder werden zahlreiche SAP-Anwendungsextraktoren und Spezialformate benötigt?
4. Wie komplex sind Bereinigung, Matching, Dublettenerkennung und objektübergreifende Transformationen?
5. Welche Nachweise, Freigabeworkflows und programmweite Governance sind verbindlich?
6. Welche Plattformen, Lizenzen und Kompetenzen sind bereits vorhanden und nach dem Go-live weiter nutzbar?
7. Welcher Ansatz lässt sich über mehrere Testmigrationen und den Cut-over vollständig reproduzieren und fachlich abnehmen?

Wenn diese Antworten noch fehlen, ist eine Toolentscheidung zu früh. Ein begrenztes Referenzobjekt kann dann zeigen, wie gut sich Quellanalyse, Transformation, Cockpit-Beladung und Ergebnisprüfung mit dem vorgesehenen Ansatz verbinden lassen.

Die beste Lösung ist nicht „ohne Tool“, sondern ohne unnötige Komplexität

Für viele klar abgegrenzte S/4HANA-Neueinführungen kann eine kontrollierte Extraktion, sichtbare SQL-Transformation, gezielte SAP-Anwendungsextraktion für Ausnahmen und das Migration Cockpit ein vollständiger, effizienter Migrationsweg sein. SAP Data Services oder Syniti ADMM sind dann nicht zwingend erforderlich.

Bei großen, heterogenen und mehrwelligen Programmen können genau diese Produkte jedoch Funktionen bereitstellen, die selbst gebaute Skripte nicht wirtschaftlich ersetzen sollten: zentrale Orchestrierung, Datenqualität, Zusammenarbeit, Wiederverwendung und programmweite Transparenz.

Für eine erste Architekturentscheidung benötigen wir deshalb keine vollständige Ausschreibung. Meist reichen der Übergangspfad, die Quell- und Ziellandschaft, eine vorläufige Objektliste, die Zahl der geplanten Wellen, besondere Datenqualitätsanforderungen und der nächste Testtermin. Daraus lässt sich ableiten, ob der schlanke Standardansatz trägt, wo kleine SAP-spezifische Extractor-Ausnahmen notwendig sind und ob eine zusätzliche Plattform einen belegbaren Mehrwert erzeugt.