Eine IS-U-Migration scheitert selten an der Technik. Sie scheitert an unterschätzten Phasen: Datenbereinigung, die zu spät beginnt, und Testzyklen, die zu klein gedacht sind. Dieser Beitrag geht das Vorgehen Phase für Phase durch und zeigt, wo die Zeit wirklich verloren geht.
Phase 0: Discovery & Readiness – den Ist-Zustand ehrlich vermessen
Vor jeder Szenario-Entscheidung steht die Standortbestimmung. Der SAP Readiness Check analysiert das Bestandssystem, der Simplification Item Check zeigt, welche Funktionen sich in SAP S/4HANA ändern, und die Custom-Code-Analyse über das ABAP Test Cockpit (ATC) macht die Anpassungstiefe des Eigencodes messbar. Parallel gehört die Frage auf den Tisch, ob die Customer-Vendor-Integration (CVI), also die Umstellung auf den führenden Geschäftspartner, bereits vorbereitet ist, denn sie ist Pflicht-Voraussetzung jeder Konvertierung.
Ergebnis dieser Phase ist kein Bauchgefühl, sondern eine belastbare Entscheidungsgrundlage: Szenario (Brownfield, Greenfield oder Hybrid), Zielarchitektur und ein grober Zeitplan, rückwärts gerechnet von den Wartungsfristen 2027/2030.
Phase 1: Datenanalyse & Bereinigung – vor dem Projekt, nicht im Projekt
Der am häufigsten unterschätzte Hebel liegt vor dem eigentlichen Projektstart. Laut der Natuvion/adesso-Transformationsstudie 2025, für die über 200 IT-Entscheider aus Energieversorgern im DACH-Raum befragt wurden, nennen 64 Prozent die Datenqualität als wichtigsten Erfolgsfaktor, mehr als jeden anderen Punkt.
Konkret heißt das: Karteileichen identifizieren (stillgelegte Verträge mit offenen Posten), Sparten-Inkonsistenzen auflösen, die Abgrenzung Sondervertrags- vs. Tarifkunde prüfen, Dubletten im Geschäftspartnerbestand bereinigen. Jede dieser Aufgaben lässt sich im laufenden IS-U-Betrieb erledigen, und zwar bevor das Migrationsprojekt Budget und Kalender bindet. Ein strukturiertes Daten-Audit vor der Migration macht aus der diffusen Sorge „unsere Daten sind gewachsen" eine priorisierte Arbeitsliste.
Phase 2: Design & Aufbau der Migrationsstrecke
Jetzt entsteht die eigentliche Migrationslogik: Zuordnung der Quellstrukturen zu den Zielobjekten (PARTNER, ACCOUNT, CONNOBJ, PREMISE, INSTLN, DEVICE …), Festlegung der Schlüsselstrategie und Aufbau der Migrationsobjekte. Für den IS-U-Kern ist die Migration Workbench EMIGALL das Standardwerkzeug. Sie bleibt auch in S/4HANA on-premise und in der private edition enthalten; ihr Key- und Status-Management (KSM) übernimmt dabei die Verwaltung der Alt-zu-Neu-Schlüsselzuordnungen über alle Ladeläufe hinweg. Das Migration Cockpit deckt den IS-U-Kern dagegen nicht ab; einen Überblick gibt der Vergleich der Migrationswerkzeuge.
Kritisch in dieser Phase: die Extraktion aus dem Quellsystem. Wenn Altsystem-Hersteller die Extrakte liefern müssen, wird deren Lieferfähigkeit schnell zum Taktgeber des gesamten Projekts. Extraktformate, Lieferzyklen und Verantwortlichkeiten gehören deshalb vertraglich und terminlich früh fixiert, nicht erst, wenn der erste Testzyklus wartet.
Phase 3: Testzyklen auf dem vollen Mengengerüst
Hier entscheidet sich das Projekt. Dieselbe Studienreihe von Natuvion identifiziert das Testmanagement als den am meisten unterschätzten Aufwand in Transformationsprojekten. Die Praxis bestätigt das. Zwei Prinzipien trennen belastbare Tests von Scheinsicherheit:
- Volles Mengengerüst statt Stichprobe. Ein Testlauf mit 5.000 handverlesenen Verträgen findet die Fehler nicht, die bei 500.000 auftreten: Laufzeitprobleme, Reihenfolge-Konflikte, seltene Datenkonstellationen. Jeder Zyklus sollte den vollständigen Produktivbestand migrieren.
- Mengen- und semantische Prüfung. „Anzahl Quell- gleich Anzahl Zielsätze" ist notwendig, aber nicht hinreichend. Geprüft werden muss auch fachlich: Stimmen Salden, Vertragslaufzeiten, Gerätezuordnungen? Rechnet die Abrechnung auf den migrierten Daten dasselbe Ergebnis wie im Altsystem?
Drei bis vier volle Testzyklen sind ein realistischer Richtwert; nach jedem Zyklus werden Fehlerklassen ausgewertet, Migrationsregeln nachgeschärft und die Laufzeiten optimiert. Wie eine belastbare Prüfsystematik aussieht, beschreibt der Beitrag zur Qualitätssicherung in der Datenmigration.
Phase 4: Generalprobe – der Cutover im Maßstab 1:1
Die Generalprobe ist kein weiterer Testzyklus, sondern die vollständige Simulation des Cutovers unter Echtbedingungen: gleiche Reihenfolge, gleiche Skripte, gleiche Mannschaft, gestoppte Zeiten. Erst sie beantwortet die Frage, ob das Downtime-Fenster (typischerweise ein verlängertes Wochenende) wirklich reicht. Wer die Generalprobe streicht, erfährt die Antwort am Go-Live-Wochenende.
Phase 5: Cutover & Go-Live
Der Umstieg selbst folgt einem minutiös geplanten Drehbuch: Einfrieren des Altsystems, finale Delta-Extraktion, Migration, Validierung, Freigabe. Fachlich entscheidend ist die Terminierung im Abrechnungskalender: Der Cutover gehört in ein Fenster mit möglichst wenig offenen Abrechnungs- und Marktkommunikationsvorgängen, damit keine Fristen der GPKE-Prozesse reißen.
Phase 6: Hypercare
Nach dem Go-Live läuft das System, aber der Beweis steht aus: der erste vollständige Abrechnungslauf, die ersten Marktkommunikationszyklen, der erste Monatswechsel auf den migrierten Daten. Die Hypercare-Phase mit verstärkter Besetzung dauert realistisch vier bis acht Wochen, bis diese Meilensteine nachweislich sauber durchlaufen sind.
Wo die Zeit wirklich verloren geht
| Phase | Typischer Zeitfresser | Gegenmittel |
|---|---|---|
| Vorbereitung | Bereinigung startet erst im Projekt | Datenanalyse und Bereinigung vorziehen |
| Aufbau | Hersteller-Extrakte kommen spät oder unvollständig | Lieferformate und Termine früh vertraglich fixieren |
| Test | Zyklen auf Stichproben, Fehler zeigen sich erst spät | Jeder Zyklus auf dem vollen Mengengerüst |
| Cutover | Downtime-Fenster nie unter Echtbedingungen gemessen | Generalprobe im Maßstab 1:1 |
PwC beobachtete 2024, dass IS-U-Umstiegsprojekte oft doppelt so lang dauern wie geplant. Die Ursache liegt fast nie in einer einzelnen Katastrophe, sondern in der Summe dieser vier Zeitfresser. Realistisch dauert eine IS-U-Ablösung 18 bis 36 Monate, je nach Szenario, Datenqualität und Zahl der Quellsysteme. Kommen mehrere Quellsysteme zusammen, verlängern Harmonisierung und Schlüsselkonsolidierung die Design- und Testphasen zusätzlich; ein Brownfield mit gepflegtem Bestand liegt eher am unteren, ein Greenfield mit Fremdsystem-Ablösung am oberen Rand der Spanne.
Ein Migrationsprojekt wird nicht im Cutover gewonnen, sondern in der Bereinigung davor und in Testzyklen, die den Ernstfall vollständig vorwegnehmen.
Das Wichtigste in Kürze
- Datenanalyse und Bereinigung gehören vor das Projekt: Laut Natuvion-Studie 2025 ist Datenqualität für 64 % der EVU-Entscheider der wichtigste Erfolgsfaktor.
- EMIGALL ist das Standardwerkzeug für den IS-U-Kern; das Migration Cockpit deckt ihn nicht ab.
- Testzyklen immer auf dem vollen Mengengerüst fahren, mit Mengen- und semantischer Prüfung.
- Die Generalprobe simuliert den Cutover 1:1 und validiert das Downtime-Fenster.
- Realistische Gesamtdauer: 18–36 Monate; Hersteller-Extrakte und Testmanagement sind die häufigsten Zeitfresser.