IT-Migration planen: Reihenfolge, Risiko und Rückweg

Eine IT-Migration planen heißt in der Praxis selten, sich zwischen Technologien zu entscheiden. Die Zielplattform steht meist früh fest. Was danach über Erfolg und Kosten entscheidet, sind drei Fragen, die in Konzepten regelmäßig zu kurz kommen: in welcher Reihenfolge die Systeme umziehen, welche Schnittstellen dabei wirklich betroffen sind, und wie der Weg zurück aussieht, wenn eine Welle nicht trägt. Dieser Artikel beschreibt, wie sich diese drei Fragen vor dem ersten Umzug beantworten lassen.

Warum die Zieltechnologie das kleinste Problem ist

In den meisten Migrationsprojekten, die wir übernehmen oder begleiten, ist die Zielarchitektur bereits beschlossen. Es gibt eine Entscheidung für einen Hyperscaler, für eine Datenbank, für ein Betriebsmodell. Diese Entscheidung ist selten falsch, und sie ist fast nie die Ursache, wenn ein Projekt aus dem Zeitplan läuft.

Die Ursachen liegen woanders. Eine Migration ist ein Eingriff in eine gewachsene Landschaft, deren tatsächlicher Zustand niemand vollständig kennt. Die Dokumentation beschreibt den Stand von vor einigen Jahren. Die Personen, die einzelne Verbindungen gebaut haben, sind teilweise nicht mehr im Unternehmen. Und die Abläufe, die auf diesen Verbindungen liegen, sind über die Zeit geschäftskritisch geworden, ohne dass das jemals jemand formal festgehalten hätte.

Wer eine IT-Migration plant, plant deshalb zuerst gegen die eigene Unkenntnis, nicht gegen die Technik. Die drei Abschnitte, die folgen, sind die Stellen, an denen diese Unkenntnis am teuersten wird.

Die Reihenfolge ist die eigentliche Entscheidung

Die naheliegende Reihenfolge ist die nach Wichtigkeit: zuerst das Kernsystem, weil dort der größte Nutzen liegt. Das ist in der Regel die schlechteste Wahl.

Das Kernsystem hat die meisten Abhängigkeiten. Es ist mit den meisten anderen Systemen verbunden, es trägt die meisten Prozesse, und es ist das System, bei dem ein Ausfall am schnellsten sichtbar wird. Wer damit anfängt, macht den riskantesten Schritt zu einem Zeitpunkt, an dem das Team am wenigsten über die reale Landschaft weiß, die geringste Routine im neuen Betriebsmodell hat und noch keine belastbare Vorstellung davon, wie lange ein Umzug tatsächlich dauert.

Eine tragfähigere Reihenfolge folgt drei Kriterien, in dieser Gewichtung:

• Abhängigkeitsgrad. Systeme mit wenigen eingehenden Verbindungen zuerst. Jedes migrierte Randsystem reduziert die Zahl der Unbekannten für die späteren Wellen.
• Lernwert. Der erste Umzug soll das Verfahren härten, nicht den größten Nutzen liefern. Ein mittelgroßes System mit echten, aber überschaubaren Abhängigkeiten liefert mehr verwertbare Erkenntnis als ein triviales Testsystem.
• Geschäftsrisiko. Systeme, deren Ausfall unmittelbar Umsatz oder Compliance berührt, gehören nicht in die erste Welle, sondern in die dritte oder vierte, wenn das Verfahren steht.

Der praktische Effekt dieser Reihenfolge ist, dass die Fehler früh und billig passieren. In der ersten Welle wird sich herausstellen, dass die Testdaten nicht repräsentativ sind, dass die Umschaltung länger dauert als geplant und dass ein Monitoring fehlt, an das niemand gedacht hat. Diese Erkenntnisse sind bei einem Randsystem eine Verzögerung von Tagen. Beim Kernsystem sind sie ein Vorfall.

Zur Reihenfolge gehört auch die Entscheidung, welche Systeme gar nicht migriert werden. In fast jeder Landschaft finden sich Anwendungen, deren Fachbereich sie seit Jahren kaum noch nutzt, und die im Zuge einer Migration abgeschaltet statt umgezogen werden können. Diese Prüfung kostet wenig und nimmt regelmäßig Aufwand aus dem Projekt heraus. Wie ein solcher Rückbau ohne Bruch abläuft, beschreiben wir ausführlicher in unserem Artikel über die Ablösung von Altsystemen ohne Big Bang.

Schnittstellen sind der Posten, der die Schätzung sprengt

Die Inventur der Schnittstellen ist der Teil der Planung, der am häufigsten zu kurz gerät, und der am zuverlässigsten die Aufwandsschätzung verändert.

Der Grund ist strukturell. Schnittstellen entstehen dezentral. Ein Fachbereich braucht eine Auswertung, ein Dienstleister baut eine Anbindung, ein nächtlicher Job wird um eine weitere Datei ergänzt. Keiner dieser Schritte durchläuft eine Architekturfreigabe, und keiner landet zwangsläufig in einer zentralen Übersicht. Was in der Dokumentation steht, ist deshalb systematisch eine Untermenge dessen, was tatsächlich läuft.

Eine belastbare Inventur stützt sich nicht auf Dokumente, sondern auf Beobachtung:

• Netzwerkverkehr über einen vollen Geschäftszyklus. Ein Monat reicht selten, weil Monats-, Quartals- und Jahresläufe unterschiedliche Verbindungen aktivieren. Der Quartalsabschluss bringt regelmäßig Schnittstellen ans Licht, die sonst elf Wochen lang still sind.
• Datenbankzugriffe von außen. Direkte Zugriffe fremder Systeme auf die Datenbank sind der häufigste undokumentierte Integrationspfad und der, der bei einem Umzug am unangenehmsten bricht.
• Datei- und Batch-Strecken. Verzeichnisse, in die ein System nachts eine Datei legt, die ein anderes System morgens abholt, tauchen in keiner API-Übersicht auf.

In gewachsenen Landschaften liegt das Ergebnis dieser Inventur regelmäßig 30 bis 50 Prozent über dem, was die vorhandene Dokumentation ausweist. Wer diese Differenz erst während der Migration entdeckt, entdeckt sie in Form von Störungen im Tagesgeschäft.

Besondere Aufmerksamkeit verdienen die Anbindungen an das ERP. In DACH-Landschaften ist das in der Mehrzahl der Fälle SAP, und die Verbindungen dorthin sind über die Jahre technisch heterogen geworden: ältere RFC-Aufrufe, IDoc-Strecken, direkte Tabellenzugriffe, dazu neuere OData-Dienste. Eine Migration ist der Moment, in dem diese Vielfalt entweder konsolidiert oder unverändert in die neue Umgebung übernommen wird. Die Konsolidierung ist Aufwand, die Übernahme ist Schuld. Wir behandeln die Entwicklung und Konsolidierung von SAP-Schnittstellen deshalb als eigenen Arbeitsstrang neben der eigentlichen Migration, nicht als Teilaufgabe innerhalb einer Welle.

Für die Frage, welches Integrationsmuster nach der Migration tragen soll, ist die Systemintegration geschäftskritischer Systeme der passende Einstieg.

Identitäten und Berechtigungen wandern nicht mit

Der zweite systematisch unterschätzte Bereich sind Identitäten. Anwendungen werden migriert, Daten werden migriert, und die Frage, wer im Zielsystem was darf, wird als Konfigurationsaufgabe am Ende eingeplant.

Das funktioniert nicht, weil Berechtigungsstrukturen in gewachsenen Landschaften keine Struktur sind, sondern Sediment. Rollen wurden für einzelne Personen angelegt, Ausnahmen wurden direkt auf Benutzer gesetzt, Rechte wurden bei Abteilungswechseln ergänzt und nie entzogen. Eine Migration überträgt diesen Zustand entweder unverändert, oder sie ist der Anlass, ihn zu bereinigen. Ein dritter Weg existiert praktisch nicht.

Die Bereinigung gehört vor die erste Welle, aus zwei Gründen. Erstens ist eine Rechtestruktur, die im Altsystem unübersichtlich ist, im Zielsystem nicht plötzlich klarer. Zweitens ist der Moment des Umzugs der einzige, in dem der Fachbereich einen Aufwand zur Rechteprüfung akzeptiert, weil er ohnehin an der Umstellung beteiligt ist. Nach der Migration sinkt diese Bereitschaft auf null.

Konkret heißt das: Rollen fachlich neu schneiden statt technisch kopieren, Ausnahmen auf Benutzerebene auflösen, und einen zentralen Punkt für Authentifizierung schaffen, bevor die Anwendungen einzeln umziehen. Ein zentraler Identitätsdienst reduziert außerdem den Migrationsaufwand pro Anwendung, weil jede migrierte Anwendung gegen denselben Dienst spricht statt gegen eine eigene Benutzerverwaltung. Wie wir das aufsetzen, beschreibt unsere Leistung zur IAM-Beratung mit Keycloak; die technische Seite haben wir im Artikel Keycloak als IAM im Unternehmen ausgeführt.

Der Rückweg zählt erst, wenn er geprobt ist

In den meisten Migrationskonzepten gibt es ein Kapitel zum Rollback. In den wenigsten Projekten ist dieses Kapitel jemals ausgeführt worden, bevor es gebraucht wurde.

Ein Rückweg, der nur auf Papier existiert, ist keiner. Die Gründe, aus denen er im Ernstfall nicht funktioniert, sind immer dieselben: Das Altsystem wurde bereits abgeschaltet oder verändert. Daten, die im Zielsystem seit der Umschaltung entstanden sind, lassen sich nicht zurückspielen. Oder die Rückschaltung dauert länger als das Wartungsfenster, das noch verfügbar ist.

Drei Bedingungen machen einen Rückweg belastbar:

• Das Altsystem bleibt lauffähig, bis die Welle stabil ist. Nicht abgeschaltet, nicht umkonfiguriert, sondern betriebsbereit. Das kostet Lizenz und Betrieb für einige Wochen, und dieser Posten gehört in die Kalkulation.
• Der Datenrückfluss ist definiert. Für jeden Datensatz, der im Zielsystem entstehen kann, muss feststehen, was mit ihm bei einer Rückschaltung passiert. Meist ist die Antwort ein Nachlauf, kein automatischer Rücktransport.
• Die Rückschaltung wurde einmal vollständig durchgeführt. In einer Probe, mit Zeitmessung, unter realistischer Datenlast. Erst diese Messung sagt, ob der Rückweg in das verfügbare Fenster passt.

Der dritte Punkt ist der, der regelmäßig gestrichen wird, weil er Zeit kostet, ohne sichtbaren Fortschritt zu liefern. Er ist auch der einzige, der den Unterschied macht.

Die Datenmigration ist ein eigenes Vorhaben

In Migrationsplänen erscheint die Übernahme der Daten häufig als ein Arbeitspaket innerhalb einer Welle. In der Praxis hat sie einen eigenen Ablauf, eine eigene Fehlerklasse und einen eigenen Zeitbedarf, und sie ist der Teil, der eine Umschaltung am häufigsten verzögert.

Der Grund liegt in einer Eigenschaft gewachsener Bestände: Sie enthalten Daten, die nach den Regeln des Zielsystems nicht zulässig sind. Kundensätze ohne Pflichtfeld, weil das Feld erst später eingeführt wurde. Referenzen auf Datensätze, die nicht mehr existieren. Dubletten, die im Altsystem toleriert wurden, weil eine Prüfung fehlte. Historische Sätze aus Zeiträumen, in denen ein anderes Format galt.

Diese Sätze sind keine Fehler im engeren Sinn. Sie sind die dokumentierte Geschichte des Betriebs. Die Frage ist nicht, ob sie korrekt sind, sondern was mit ihnen geschehen soll, und diese Frage kann nur der Fachbereich beantworten.

Drei Entscheidungen gehören deshalb vor die technische Umsetzung:

• Der Stichtag der Historie. Wie weit zurück werden Bewegungsdaten übernommen. Alles, was nicht übernommen wird, braucht einen definierten Zugang für den Fall einer Prüfung, meist ein Archiv mit Lesezugriff.
• Der Umgang mit nicht konformen Sätzen. Bereinigen, mit Ersatzwerten übernehmen oder ausschließen. Jede der drei Antworten ist vertretbar, und jede muss je Datenklasse getroffen und protokolliert sein.
• Der Nachweis der Vollständigkeit. Nach der Übernahme muss beweisbar sein, dass die Zielmenge der Quellmenge entspricht. Ein Abgleich der Satzzahlen reicht dafür nicht, weil er Verschiebungen innerhalb der Menge nicht sichtbar macht. Nötig ist ein Abgleich fachlicher Summen, etwa offener Posten oder aktiver Verträge.

Der Probelauf der Datenmigration gehört auf den vollständigen Bestand, nicht auf einen Auszug. Ein Auszug läuft schnell und sagt nichts über die Laufzeit unter realer Menge, und die Laufzeit entscheidet, ob die Übernahme in das Wartungsfenster passt. In gewachsenen Landschaften ist der erste Lauf auf dem vollständigen Bestand regelmäßig um ein Vielfaches langsamer als die Hochrechnung aus dem Auszug.

Was in die Planung gehört und oft fehlt

Zwei Posten tauchen in Migrationsplänen selten auf und verursachen später verlässlich Diskussionen.

Der erste ist das Abschaltdatum des Altsystems. Ohne festes Datum bleibt die alte Landschaft in Betrieb, weil sich immer ein Fachbereich findet, der noch einen Bericht daraus zieht. Das Ergebnis ist ein Dauerzustand mit zwei Landschaften, doppelten Betriebskosten und einer Datenlage, bei der niemand mehr sagen kann, welche Seite führt. Das Abschaltdatum gehört in die Planung, mit einem benannten Verantwortlichen und einer Liste der Berichte, die vorher zu ersetzen sind.

Der zweite ist der Betrieb nach der Migration. Eine migrierte Landschaft wird anders betrieben als die alte: andere Werkzeuge, andere Alarme, andere Zuständigkeiten. Wenn das Betriebsteam diese Umstellung erst nach der letzten Welle lernt, entsteht genau in dem Moment eine Lücke, in dem das Projektteam abzieht. Der Betrieb gehört ab der ersten Welle in dieselben Hände, die ihn danach führen.

Wie wir eine Migration schneiden

Unsere Reihenfolge bei Cloud- und Infrastrukturmigrationen ist in der Regel dieselbe: zuerst eine Inventur über einen vollen Geschäftszyklus, dann die Konsolidierung von Schnittstellen und Berechtigungen, dann eine erste Welle mit mittlerem Lernwert und geprobtem Rückweg, dann die Kernsysteme. Die Wellen sind so geschnitten, dass jede einzelne für sich zurückgenommen werden kann.

Diese Reihenfolge ist langsamer im Start und schneller im Ergebnis, weil die teuren Überraschungen in die Phase fallen, in der sie noch billig sind. Für Landschaften, in denen die Ablösung des Altsystems selbst die eigentliche Aufgabe ist, greift zusätzlich unser Vorgehen zur Legacy-Modernisierung.

Wer vor einer IT-Migration steht und die Reihenfolge noch nicht festgelegt hat, hat den Zeitpunkt erwischt, an dem die Planung am meisten wert ist.