Datenmigration nach S/4HANA: Vorgehen, Probeläufe, Checkliste

Die Datenmigration ist nicht der letzte Schritt im S/4HANA-Projekt. Sie ist der Grund, warum der Go-Live verschoben wird.

Das ist etwas zugespitzt. Aber ich erlebe es in fast jedem Programm: Der dritte Probelauf, zwei Wochen vor dem Cutover. Technisch läuft alles durch. Und dann schaut der Fachbereich zum ersten Mal richtig hin.

Was in einer S/4HANA-Datenmigration wirklich schiefgeht

Die technischen Probleme sind lösbar. Ladeprogramme lassen sich korrigieren, Mappings nachziehen, Laufzeiten optimieren. Schwierig wird es bei den Dingen, die erst sichtbar werden, wenn jemand die Daten mit fachlichem Blick ansieht.

• Kunden ohne gültige Zahlungsbedingungen.
• Materialien, die seit Jahren niemand mehr bestellt hat und die trotzdem mitwandern.
• Lieferanten, die es doppelt gibt, einmal mit altem und einmal mit neuem Namen.
• Offene Posten, deren Herkunft niemand mehr erklären kann.

Nichts davon ist ein Migrationsfehler. Es sind Altlasten, die das alte System über Jahre toleriert hat. S/4HANA toleriert manches davon nicht mehr, und die Migration ist der Moment, in dem das auffällt.

Warum fällt es so spät auf? Weil die Migration im Projektplan oft als technisches Arbeitspaket steht. Die IT lädt, der Berater mappt, der Fachbereich ist in den Workshops zu den neuen Prozessen gebunden. Die Daten laufen nebenher, bis sie es nicht mehr tun.

Die Grundregel: Daten brauchen Eigentümer

Jedes Datenobjekt bekommt eine Person aus dem Fachbereich, die für dessen Inhalt geradesteht. Kundenstamm, Lieferantenstamm, Materialstamm, Stücklisten, offene Posten, Bestände. Mit Namen, nicht mit Abteilung.

Diese Person entscheidet, welche Sätze wandern, welche bereinigt und welche archiviert werden. Sie nimmt jeden Probelauf für ihr Objekt ab. Und sie gibt am Ende das Go für die Datenseite. Die IT liefert Werkzeug, Auswertungen und Tempo. Die Verantwortung für den Inhalt kann sie nicht übernehmen, und sie sollte es auch nicht versuchen.

Das klingt nach einer organisatorischen Formalie. Tatsächlich ist es die wichtigste einzelne Entscheidung in diesem Arbeitsstrang. Warum diese Rolle so oft unbesetzt bleibt und was das mit dem Selbstverständnis des Projekts zu tun hat, steht im Artikel S/4HANA ist kein IT-Projekt.

Vorgehen in fünf Schritten

1. Objekte und Umfang festlegen

Welche Datenobjekte werden übernommen, welche neu aufgebaut, welche gar nicht? Für jedes Objekt: Quelle, Menge, Eigentümer, Abhängigkeiten. Die Abhängigkeiten sind wichtiger, als sie aussehen, weil sie die Ladereihenfolge im Cutover bestimmen. Ohne Lieferanten keine Bestellungen, ohne Materialien keine Bestände.

Gleichzeitig wird entschieden, was nicht mitkommt. Eine klare Altdatenregel spart später Wochen. Zum Beispiel: Stammdaten ohne Bewegung in einem festgelegten Zeitraum wandern nicht, außer jemand begründet es.

2. Im Altsystem bereinigen

Die Bereinigung beginnt dort, wo die Daten heute liegen. Nicht im Migrationswerkzeug, nicht in einer Excel-Zwischenschicht, die nach dem Go-Live niemand mehr pflegt. Dubletten zusammenführen, Pflichtfelder füllen, Inaktives sperren.

Das braucht Zeit, und zwar die Zeit der Leute, die die Daten kennen. Deshalb gehört die Bereinigung als eigenes Arbeitspaket mit eigenem Aufwand in den Plan. Sie beginnt Monate vor dem ersten Probelauf, nicht wenige Wochen davor.

3. Werkzeug und Mapping

Für die meisten Projekte ist das SAP S/4HANA Migration Cockpit das Werkzeug der Wahl. In der aktuellen Fiori-App "Migrate Your Data" gibt es zwei Wege: das Laden über Staging-Tabellen, auch aus Nicht-SAP-Quellen, und die direkte Übernahme aus einem SAP-System. Die Details stehen in der SAP-Dokumentation zum Migration Cockpit.

Welches Werkzeug Sie nehmen, ist eine Frage für Ihr Migrationsteam. Wichtiger ist, dass jedes Mapping fachlich freigegeben wird. Ein Feld, das technisch passt, kann fachlich falsch sein. Das sieht nur, wer den Prozess dahinter kennt.

4. Probeläufe, die etwas aussagen

Planen Sie mehrere vollständige Probeläufe mit realistischem Datenvolumen. Jeder Lauf hat ein Ziel und ein Abnahmekriterium. Ein Lauf, der nur zeigt, dass die Programme durchlaufen, beweist wenig.

Ein brauchbarer Probelauf beantwortet drei Fragen:

• Vollständigkeit. Kommen alle Sätze an, die ankommen sollen? Mengen und Summen werden gegen die Quelle abgeglichen.
• Richtigkeit. Stimmen die Inhalte? Die Datenverantwortlichen prüfen Stichproben und die kritischen Felder.
• Laufzeit. Passt die Migration in das Cutover-Fenster? Mit Puffer, nicht auf Kante.

Jeder Lauf endet mit einer Fehlerliste, einem Eigentümer pro Fehler und einem Termin bis zum nächsten Lauf. Die Fehlerzahl sollte von Lauf zu Lauf sinken. Wenn sie es nicht tut, haben Sie kein Migrationsproblem, sondern ein Bereinigungsproblem.

5. Generalprobe und Cutover

Der letzte Probelauf ist eine Generalprobe des echten Cutovers: gleiche Reihenfolge, gleiche Leute, gleiches Zeitfenster. Daraus entsteht der Cutover-Plan mit Stunden und Verantwortlichen. Was bei der Generalprobe nicht funktioniert, funktioniert am Go-Live-Wochenende auch nicht. Es fühlt sich dort nur dringlicher an.

Die Ergebnisse dieser Generalprobe gehören direkt in die Go/No-Go-Entscheidung. Wie das zusammenhängt und warum die Hypercare danach mit genau diesen Daten startet, beschreibt Hypercare und Go-Live.

Datenqualität im Lenkungsausschuss

Hier fällt die Entscheidung, ob die Migration gesteuert wird oder nur berichtet. Eine gelbe Ampel neben "Datenmigration" sagt dem Lenkungsausschuss nichts. Zahlen schon.

Was in einen Bericht gehört:

• Fehlerquote pro Objekt und Probelauf, mit Trend.
• Anteil der fachlich abgenommenen Objekte.
• Offene Bereinigungsaufgaben mit Eigentümer und Termin.
• Laufzeit des letzten Laufs im Verhältnis zum Cutover-Fenster.

Wenn diese vier Zahlen über mehrere Läufe nicht besser werden, ist das ein Grund, den Termin zu hinterfragen. Früh. Nicht in der Woche vor dem Go-Live, wenn jede Verschiebung teurer ist als jede Bereinigung.

Wie die Datenverantwortung in die übrige Projektsteuerung passt, also in Rollen, Entscheidungswege und Berichtswesen, steht im Leitfaden zum S/4HANA-Projektmanagement.

Checkliste Datenmigration S/4HANA

✅ Jedes Datenobjekt hat einen namentlich benannten Verantwortlichen aus dem Fachbereich.

✅ Es gibt eine schriftliche Altdatenregel: was wandert, was nicht, und wer Ausnahmen entscheidet.

✅ Die Bereinigung ist ein eigenes Arbeitspaket mit Aufwand und Terminen und hat im Altsystem begonnen.

✅ Die Abhängigkeiten zwischen den Objekten sind dokumentiert und bestimmen die Ladereihenfolge.

✅ Jedes Mapping ist fachlich freigegeben.

✅ Jeder Probelauf hat ein Ziel, ein Abnahmekriterium und eine fachliche Abnahme.

✅ Mengen und Summen werden nach jedem Lauf gegen die Quelle abgeglichen.

✅ Die Laufzeit passt mit Puffer ins Cutover-Fenster.

✅ Die Generalprobe läuft unter echten Bedingungen.

✅ Datenqualität steht mit Zahlen im Lenkungsausschuss.

❌ "Das bereinigen wir nach dem Go-Live." Das passiert erfahrungsgemäß nicht, oder unter deutlich mehr Druck.

❌ Excel-Zwischenschichten, die nach dem Projekt niemand mehr versteht.

Mehr dazu, wie Qualitätssicherung und Testmanagement in die Gesamtsteuerung eingebettet werden, steht in unserem Whitepaper zur S/4HANA-Transformation.

Häufige Fragen

Wann sollte die Datenbereinigung beginnen?

Sobald klar ist, welche Objekte übernommen werden. Das ist in der Regel früh in der Projektvorbereitung, Monate vor dem ersten Probelauf. Wer erst mit den Probeläufen anfängt zu bereinigen, bereinigt unter Termindruck.

Wie viele Probeläufe braucht eine Datenmigration?

So viele, bis Fehlerquote, fachliche Abnahme und Laufzeit stabil sind. Eine feste Zahl gibt es nicht. Planen Sie mehrere vollständige Läufe und einen als Generalprobe unter echten Bedingungen.

Wer ist für die Datenmigration verantwortlich?

Für den Inhalt der Fachbereich, für Werkzeug und Technik die IT oder der Migrationspartner. Diese Trennung sollte vor dem ersten Lauf schriftlich stehen, mit Namen pro Datenobjekt.

Brauchen wir das Migration Cockpit?

Für viele Projekte ist es der naheliegende Weg, weil es zum Lieferumfang gehört und vorgefertigte Migrationsobjekte mitbringt. Ob es für Ihre Quellen und Mengen reicht, entscheidet Ihr Migrationsteam. Das Werkzeug ersetzt in keinem Fall die fachliche Abnahme.

Ihre Probeläufe laufen technisch durch, aber niemand traut den Daten? Das ist ein Steuerungsthema, kein Werkzeugproblem. In einem Erstgespräch sehen wir gemeinsam, wo es hakt.

Termin buchen