Warum die SAP-Datenmigration scheitert und wie Sie es beheben

SAP-Datenmigrationen scheitern aus einem Grund häufiger als aus jedem anderen: Der Plan stützt sich auf das, was der Fachbereich für den Zustand seiner Daten hält, nicht auf das, was ein Extrakt zeigt. Dieser Leitfaden richtet sich an Programmverantwortliche, Data Leads und Finanzverantwortliche in einem S/4HANA-Programm. Er behandelt, warum Migrationen brechen, die fünf Fehler hinter den meisten gescheiterten Cutovers, einen Plan für Probemigrationen zum Übernehmen und welche SAP-Werkzeuge 2026 zu welcher Aufgabe passen. Wenn Sie diese Woche nur eines tun, ziehen Sie einen vollständigen Extrakt Ihrer Kunden-, Lieferanten- und Materialstämme und zählen Sie die Sätze selbst.

Ein Fertigungsunternehmen gab 18 Monate und 4,5 Millionen US-Dollar für seine SAP-Einführung aus. Der Starttag kam. Alle waren nervös, aber voller Vorfreude. Dann scheiterte die Datenmigration.

Nichts funktionierte richtig. Kundendaten fehlten. Die Bestandszahlen stimmten nicht. Das Rechnungswesen konnte die Bücher nicht schließen. Der CEO war außer sich.

Es lag weder an der Software noch am Einführungsteam. Der Fehler lag in der Lücke zwischen dem, was der Fachbereich für den Zustand seiner Daten hielt, und dem, wie sie tatsächlich aussahen.

Das Datenmodell von SAP ist kein flacher Import. Datensätze hängen voneinander ab. Ein Materialstamm hat einen allgemeinen Satz (MARA), Werksdaten (MARC), Bewertungsdaten (MBEW) und, wo MRP-Bereiche genutzt werden, MRP-Bereichsdaten (MDMA). Laden Sie den Kopf ohne die abhängigen Sichten, existiert das Material, ist aber in keiner Transaktion verwendbar.

S/4HANA bringt eine eigene Regel mit. Kunden und Lieferanten sind Geschäftspartner. Ein Alt-Kunde wird zu einem Geschäftspartner mit Kundenrolle, ein Lieferant zu einem mit Lieferantenrolle. Kreditlimits, Bankverbindungen und Steuernummern hängen an diesem Geschäftspartner. Ein Satz, den ein Altsystem mit Lücken tolerierte, fällt hier durch die Validierung.

Dazu kommt das Volumen. Die meisten Unternehmen sind schockiert, wie viele Daten sie tatsächlich haben. Ein Kunde glaubte, rund 50.000 Materialstammsätze zu haben. Zählte man alle Varianten und werksspezifischen Sätze, lag die Zahl näher bei 500.000. Ein Plan, der auf die erste Zahl ausgelegt ist, übersteht die zweite nicht.

Schätzung des FachbereichsVollständiger Extrakt

Materialstammsätze im Umfang500,000+450,000 · +900%

Schätzung des Fachbereichs50,000

Vollständiger Extrakt500,000

• Jede Variante und jeder werksspezifische Satz gezählt
• Ein Plan, der auf der Schätzung beruht, übersteht sie nicht

Das war kein Datenmigrationsproblem. Es war ein Problem der Umfangsplanung, das zu einem wurde.

Die Bewertung der Datenqualität zu Projektbeginn ist meist eine Beschreibung der Daten, keine Untersuchung. Der Finanzleiter sagt, der Lieferantenstamm sei gut gepflegt. Der Lagerleiter sagt, die Materialien seien größtenteils sauber. Das sind Eindrücke.

Der erste Extrakt sagt Ihnen die Wahrheit. Lieferanten, die vor Jahren hätten bereinigt werden sollen und es nicht wurden. Materialien, die längst ausgelaufen sind und nie deaktiviert wurden. Kundenadressen mit uneinheitlichen Ländercodes. Fehlende Bankverbindungen bei Lieferanten, die per Überweisung bezahlt werden.

Jedes davon braucht eine fachliche Entscheidung, keine technische Korrektur. Nur die Kreditorenbuchhaltung kann sagen, welcher von zwei doppelten Lieferanten der richtige ist. Nur der Einkauf kann sagen, welche veralteten Materialien gesperrt werden und welche zurückbleiben. Diese Entscheidungen brauchen Zeit, und sie brauchen die Menschen, die die Daten kennen. Beruht die Bewertung nicht auf einem echten Extrakt, steht der Plan auf Annahmen, die den Kontakt mit den Daten nicht überleben. Mein kostenloser Schätzer für die Datenmigration hilft, den Aufwand zu bemessen, sobald Sie echte Zahlen haben.

1. Migration als späte technische Aufgabe behandeln

Die Migration gehört in jede Phase von SAP Activate. Explore legt den Umfang fest: Objekte, Quellsysteme, Volumen und Qualität. Realize baut die Vorlagen und führt die Probemigrationen durch. Deploy führt die Generalprobe und den Cutover-Ladelauf durch. Run stimmt den ersten Periodenabschluss auf Echtdaten ab.

Projekte, die die Migrationsarbeit erst in Deploy beginnen, fangen Monate zu spät an. Die Qualitätsprobleme, die in Realize hätten gelöst sein sollen, tauchen in der ersten Probemigration auf, Wochen vor dem Cutover. Mein Leitfaden zur SAP-Zeitplanung zeigt, wo die Migration im Gesamtplan sitzt.

2. Zu wenig Einbindung des Fachbereichs

Die Migration ist in der Ausführung technisch und in der Entscheidungsfindung eine fachliche Aufgabe. Die IT kann die Liste der doppelten Lieferanten nicht erstellen. Welche Kundenkonten als aktiv übernommen werden und welche als Historie bleiben, ist eine Entscheidung des Finanzwesens. Die Bereinigung veralteter Materialien braucht Einkauf, Lager und Produktmanagement.

Programme, die die Migration nur mit technischen Leuten besetzen und den Fachbereich am Ende als Abnahme behandeln, produzieren Daten, die sich laden lassen. Kaufmännisch sind sie falsch.

3. Zu wenige Probemigrationen einplanen

Eine gut geführte SAP-Datenmigration braucht vor dem Cutover mindestens drei Probemigrationen, komplexe Programme brauchen mehr. Projekte, die eine oder zwei einplanen, planen mit sauberen Daten und sauberem Mapping. Dieses Szenario ist selten. Mehr Zyklen sind kein Zeichen einer problematischen Migration. Sie sind das Zeichen einer sauber geplanten.

4. Probemigrationen nicht abstimmen

Ein Ladejob, der ohne Fehler endet, ist keine Validierung. Validierung vergleicht, was geladen wurde, mit dem, was erwartet wurde: Satzanzahlen, Finanzsummen, Salden offener Posten. Danach bestätigt ein Prozess-Smoke-Test, dass die Daten in den Transaktionen funktionieren.

Eine Probemigration, die nicht abgestimmt wird, kostet trotzdem Zeit. Die Lücke, die sie hinterlassen hat, ist bei der nächsten Probemigration noch da, nur lässt sie sich jetzt schwerer auf ihre Ursache zurückverfolgen. Stimmen Sie jeden Ladelauf ab, bevor Sie den nächsten starten.

5. Ein Cutover-Ladelauf, der von den Proben abweicht

Die Cutover-Migration sollte die letzte Probemigration exakt wiederholen: dieselben Extraktionsskripte, dieselbe Transformationslogik, dieselbe Ladereihenfolge, dieselben Prüfungen und dasselbe Timing. Jede Änderung beim Cutover ist ungetestetes Risiko im Moment des höchsten Drucks im Programm.

Das am wenigsten getestete Stück ist meist das Delta. Zwischen der letzten Probemigration und dem Cutover legt das Geschäft weiter Lieferanten an, ändert Bestellungen und bewegt Bestände. Legen Sie den Termin für den Data Freeze fest und proben Sie den Delta-Ladelauf als Teil der letzten Probemigration.

Nutzen Sie diese Zyklusstruktur als Ausgangspunkt. Jeder Zyklus hat ein Ziel und ein Exit-Kriterium, und er ist erst abgeschlossen, wenn die Abstimmung unterzeichnet ist.

Zyklus	Ziel	Exit-Kriterium	Verantwortlich
Probemigration 1	Struktur: jedes Objekt lädt in Abhängigkeitsreihenfolge	Mapping-Lücken und Formatfehler je Objekt protokolliert	Leiter Datenmigration
Probemigration 2	Qualität: Mapping-Korrekturen testen und Datenprobleme aufdecken	Fehlerquote je Objekt sinkt; Bereinigungsentscheidungen protokolliert	Data Stewards
Probemigration 3	Geschäftsregeln: Ausnahmen und Grenzfälle	Stewards akzeptieren eine abgestimmte Stichprobe in jeder Domäne	Data Stewards
Probemigration 4	Volumen und Timing in voller Produktionsgröße	Vollständiger Ladelauf endet innerhalb des Cutover-Fensters	Cutover-Manager
Generalprobe	Cutover-Generalprobe, einschließlich Delta und Freeze	Anzahlen und Finanzsummen abgestimmt und unterzeichnet	Financial Controller und Data Lead

Um diesen Plan herum machen fünf Dinge den Unterschied:

1. Ein vollständiger Extrakt in Prepare. Alles, keine Stichprobe. Profilieren Sie Vollständigkeit, Richtigkeit, Konsistenz und Dubletten und bemessen Sie dann anhand der Ergebnisse Bereinigung und Zeitplan.
2. Mapping Objekt für Objekt. Dokumentieren Sie für jedes Objekt (Geschäftspartner, Materialien, offene Bestellungen und Kundenaufträge, offene Posten, Bestände, Anlagen) die Felder von Quelle zu Ziel, die Transformationsregeln, die Validierungsprüfungen und die Ausnahmeregeln.
3. Benannte Data Stewards. Das Finanzwesen verantwortet die finanziellen Kunden- und Lieferantendaten. Der Einkauf verantwortet den Materialstamm. Das Lager verantwortet die Bestände. Jeder Steward zeichnet seine Domäne nach jedem Zyklus ab.
4. Abstimmung vorab definiert. Legen Sie vor der ersten Probemigration fest, welche Anzahlen und Summen belegen, dass ein Ladelauf stimmt, damit beim Cutover niemand darüber streitet.
5. Eine schriftliche Cutover-Sequenz. Freeze, Extraktion, Transformation, Laden, Validierung, fachliche Abnahme, Go/No-go. Dieselbe Sequenz wie in der Generalprobe.

Für eine neue S/4HANA-Einführung ist das SAP S/4HANA Migration Cockpit das von SAP empfohlene Werkzeug für die initiale Datenübernahme. Seit S/4HANA 2020 läuft es als Fiori-App Migrate Your Data. Die Transaktion LTMC ist abgekündigt, bestehende LTMC-Projekte lassen sich nur noch anzeigen. Die App bietet zwei Ansätze: Daten über Staging-Tabellen migrieren (befüllt aus Dateien oder mit Ihren eigenen Werkzeugen) und Daten direkt aus einem SAP-Quellsystem migrieren. Teams in On-Premise und Private Cloud nutzen die Transaktion LTMOM, den Migrationsobjekt-Modellierer, um Standardobjekte anzupassen oder eigene zu bauen. Das Cockpit ist für initiale Datenübernahmen gebaut, nicht für wiederkehrende Schnittstellen oder Massenänderungen.

SAP Data Services ist die ETL-Plattform von SAP. Setzen Sie sie bei hohen Volumen, aufwendiger Transformationslogik oder mehreren Quellsystemen ein, oder wenn Sie ein wiederverwendbares Datenqualitäts-Framework wollen, das das Projekt überdauert.

ETL-Werkzeuge von Drittanbietern wie Informatica, Talend oder Microsoft SSIS sind sinnvoll, wo die Organisation sie bereits besitzt und die Kompetenz dafür hat.

SAP Datasphere, heute Teil von SAP Business Data Cloud, ist kein Migrationswerkzeug. Sein Platz ist die Analytics-Schicht nach dem Go-live. Es zählt, wenn Sie Historie im Altsystem belassen und trotzdem darauf berichten müssen.

Für die meisten Standardeinführungen deckt das Migration Cockpit die Mehrzahl der Objekte ab. Hohe Volumen, stark angepasste Altsysteme oder ungewöhnliche Quellstrukturen brauchen meist zusätzlich Data Services oder ein ETL-Werkzeug. Konvertierungen von ECC sind eine andere Übung, die mein Leitfaden zur Migration von ECC auf S/4HANA behandelt.

Was ist SAP-Datenmigration?

Bei der SAP-Datenmigration werden Daten aus Altsystemen extrahiert, so transformiert, dass sie zu den Strukturen und Regeln von SAP passen, und im Rahmen einer Einführung oder Konvertierung in SAP geladen. Typische Objekte sind Geschäftspartner (Kunden und Lieferanten), Materialien mit Werksdaten, offene Bestellungen und Kundenaufträge, Bestandssalden, offene Posten im Finanzwesen und Anlagen. Schwierig ist sie, weil SAP Abhängigkeiten und Validierungsregeln durchsetzt, die Altsysteme oft nicht kannten.

Was sind die wichtigsten Ansätze der SAP-Datenmigration?

Eine Neueinführung (Greenfield) lädt ausgewählte Stammdaten und offene Posten in ein frisches S/4HANA-System und belässt die Historie im Altsystem oder in einem Archiv. Eine Systemkonvertierung (Brownfield) konvertiert ein bestehendes ECC-System samt Historie an Ort und Stelle. Die Selective Data Transition liegt dazwischen und bewegt ausgewählte Buchungskreise, Objekte oder Zeitscheiben. Die richtige Wahl hängt von der Datenqualität, den Anforderungen an die Historie und davon ab, wie viel des alten Prozesses Sie behalten wollen.

Was ist das SAP Migration Cockpit, und wann sollte man es einsetzen?

Das SAP S/4HANA Migration Cockpit ist das von SAP empfohlene Werkzeug für die initiale Datenübernahme in S/4HANA, in allen Editionen. Seit S/4HANA 2020 läuft es als Fiori-App Migrate Your Data; die Transaktion LTMC ist abgekündigt. Es bietet vordefinierte Migrationsobjekte, validiert Daten vor dem Buchen und meldet Fehler auf Feldebene. Nutzen Sie es für Standardobjekte bei normalen Volumen. Ergänzen Sie SAP Data Services oder ein anderes ETL-Werkzeug, wenn Volumen, Transformationslogik oder Quellstrukturen über das hinausgehen, was die Vorlagen leisten.

Für wie viele Probemigrationen sollte ein SAP-Datenmigrationsplan ausgelegt sein?

Für mindestens drei, wobei die letzte eine vollständige Cutover-Generalprobe ist. Komplexe Programme brauchen mehr. In einem typischen Plan findet die erste strukturelle Mapping-Lücken. Die zweite testet die Korrekturen und deckt Datenqualitätsprobleme auf. Die dritte arbeitet Geschäftsregeln und Grenzfälle durch. Der letzte Lauf wiederholt den Cutover exakt, und seine Abstimmung wird zur Baseline für den Go-live-Tag.

Wie migriert man Kunden und Lieferanten nach SAP S/4HANA?

Als Geschäftspartner. In S/4HANA werden Kunden- und Lieferantenstammdaten über den Geschäftspartner gepflegt, mit angehängten Kunden- und Lieferantenrollen. In einer Neueinführung lädt das Migration Cockpit sie über seine Geschäftspartner-Objekte. Bei einer Konvertierung von ECC muss die Customer-Vendor-Integration vor der Konvertierung selbst eingerichtet und ausgeführt werden.

Was lässt die SAP-Datenmigration beim Cutover scheitern?

Fünf Muster verursachen die meisten gescheiterten Cutovers. Zu wenige Probemigrationen. Eine Cutover-Sequenz, die nie durchgängig getestet wurde. Änderungen im Altsystem nach der letzten Probemigration mit einem ungetesteten Delta-Ladelauf. Offen gelassene Lücken in der Abstimmung. Eine fachliche Abnahme, die auf einer Stichprobe beruht. „Die ersten 1.000 Sätze sahen gut aus“ ist keine Validierung. Der Go-live braucht abgestimmte Anzahlen und Summen.