Wie wechsle ich zum neuen System, ohne die Arbeit zu stoppen?

Sie wechseln ohne Arbeitsunterbrechung, wenn Sie das alte System erst abschalten, nachdem sich das neue bewährt hat: Betreiben Sie beide mit denselben echten Transaktionen und vergleichen Sie die Ergebnisse, testen Sie die seltenen Fälle, die Ihre Prozessverantwortlichen nennen, verlangen Sie für jedes Modul eine menschliche Freigabe vor dem Livegang und halten Sie das alte System für eine Rückkehr bereit. In seinem Leitfaden zur Durchführung der Migration empfiehlt Microsoft, das neue System in den ersten 24 bis 48 Stunden nach der Umstellung zu überwachen und die Quellumgebung während der Stabilisierung als Rückfalloption zu behalten.

In Teil 5 haben Sie für jedes System einen Weg gewählt. Dieser Teil wiederholt nicht die allgemeine Umstellungsmethode, die wir in Altsysteme ohne Ausfallzeit modernisieren beschrieben haben. Er konzentriert sich auf das Neue: was Sie testen, wenn KI den neuen Code geschrieben oder konvertiert hat.

Warum KI-konvertierter Code andere Tests braucht

Code aus Konvertierungswerkzeugen wirkt aufgeräumt und läuft beim ersten Versuch, und genau das macht seine Fehler schwer sichtbar. Der Fehler zeigt sich nicht im Alltag, sondern in dem Fall, der einmal im Monat oder einmal im Jahr vorkommt. Amazon erklärt in seinem Leitfaden zur Transformation von Mainframe-Anwendungen, dass die erste Konvertierung von COBOL nach Java dasselbe Verhalten beibehält und danach ein Schritt namens Reforge große Sprachmodelle nutzt, um den Code im modernen Java-Stil umzubauen. COBOL ist eine alte Programmiersprache, die noch viele Bank- und Mainframe-Systeme antreibt; ein Mainframe ist der große Zentralrechner, auf dem die Kernsysteme großer Organisationen laufen.

Jeder Schritt, der Code neu schreibt, kann eine Kleinigkeit verändern. Es reicht also nicht, dass ein Entwickler den neuen Code liest und sagt, er sehe richtig aus. Die Geschäftsleitung hat nur eine Frage: Liefert das neue System mit denselben Daten dasselbe Ergebnis wie das alte? Die Antwort kommt aus dem Vergleich der Ergebnisse, nicht aus dem Lesen des Codes.

Vergleichen Sie die Ergebnisse bei denselben echten Transaktionen

Nehmen Sie einen abgeschlossenen Zeitraum Ihres Geschäfts, etwa einen Monat mit bereits abgeschlossenen Büchern, spielen Sie seine Transaktionen in das neue System ein und vergleichen Sie, was herauskommt, mit dem, was das alte geliefert hat. Was Sie vergleichen:

• Endzahlen: Rechnungssummen, Salden und Lagerbestand am Ende des Zeitraums.
• Berichte: die Monatsberichte, auf die sich die Geschäftsleitung stützt, Zeile für Zeile.
• Was an andere Systeme geht: die Dateien und Nachrichten an die Bank, die Buchhaltung oder Behördenportale.
• Ablehnungen und Fehler: Eine Transaktion, die das alte System ablehnt, muss auch das neue ablehnen, aus demselben Grund.

Manche Werkzeuge helfen bei der Vorbereitung, nicht beim Urteil. AWS Transform für Mainframe etwa erstellt einen Testplan aus Codemerkmalen, Job-Komplexität und Scheduler-Pfaden in 3 Phasen (Konfiguration, Abgrenzung und Prüfung) und erzeugt dann Skripte, die Testdaten vom Mainframe in 4 Phasen sammeln. Amazon weist jedoch im selben Leitfaden darauf hin, dass diese Skripte auf Ihrem eigenen Mainframe und mit den Berechtigungen Ihres Teams ausgeführt werden müssen. Das Werkzeug bereitet vor; Ihr Team führt aus und entscheidet. Um die Daten selbst zu prüfen, schlägt Microsoft vor, zunächst die Zeilenzahlen als Schnelltest zu vergleichen und dann Prüfsummen für eine gründlichere Kontrolle: Eine Prüfsumme ist eine aus den Daten berechnete Zahl, die sich ändert, wenn sich ein einziges Zeichen ändert.

Die seltenen Fälle: Fragen Sie die, die sie kennen

Ein Monat echter Transaktionen enthält nicht alles. Die Fälle, an denen Systeme scheitern, kennen die Prozessverantwortlichen, nicht die Entwickler: den Jahresabschluss, eine Teilrückgabe zu einer alten Rechnung, einen Kunden mit Sonderpreisen, eine nach der Buchung stornierte Rechnung, das Gehalt von jemandem, der zur Monatsmitte eingetreten ist. Bitten Sie jeden Prozessverantwortlichen um eine Liste der Fälle, die ihm Sorgen machen, und machen Sie aus jedem einen Test mit einem vor der Ausführung schriftlich festgelegten erwarteten Ergebnis.

Hier kommen die Regeln zurück, die Sie in Teil 4 bestätigt haben: Jede bestätigte Regel wird zu mindestens einem Testfall. Eine Regel ohne Test ist eine Regel, von der Sie nicht sagen können, dass sie die Konvertierung überstanden hat. Zu den Testarten selbst lesen Sie unseren Leitfaden zu Softwaretests und Qualitätssicherung.

Eine menschliche Freigabe für jedes Modul

Das deutlichste veröffentlichte Beispiel für dieses Prinzip ist die Migrationsstrecke für Bankensysteme, die Thought Machine am 29. September 2026 mit Amazon angekündigt hat. Sie läuft in 4 Stufen: Extraktion der Geschäftslogik aus Altanwendungen mit AWS Transform, Zusammenführung redundanter Varianten zu einheitlichen Spezifikationen, Erzeugung der neuen Finanzprodukte und ihrer Testsuiten durch KI-Agenten und eine Validierungsstufe, die den Engineering- und Risikoteams der Bank ausdrückliche Freigabebefugnis gibt, bevor irgendetwas übernommen wird. Selbst nach der Freigabe geht das Ergebnis in eine isolierte Testumgebung zur weiteren Bewertung, nicht direkt in den Betrieb.

Die Lehre für Ihr Unternehmen braucht weder eine Bank noch Amazon: Jedes Modul des Systems, etwa Fakturierung, Gehaltsabrechnung oder Lager, bekommt vor dem Livegang zwei Unterschriften. Eine technische, die bestätigt, dass alle Tests gelaufen sind, und eine vom Prozessverantwortlichen, die bestätigt, dass die Ergebnisse fachlich stimmen. Microsoft verlangt dasselbe nach der Umstellung: Die Anwendungsverantwortlichen bestätigen, dass alle wichtigen Funktionen korrekt arbeiten.

Parallelbetrieb und Rückfallplan

Parallelbetrieb heißt, dass beide Systeme für einen festgelegten Zeitraum nebeneinander laufen und das alte weiterhin die offizielle Referenz ist. Legen Sie vor dem Start fest, wann dieser Zeitraum endet und welche Bedingung sein Ende erlaubt, etwa übereinstimmende Ergebnisse über einen vollen Geschäftszyklus. Organisieren Sie die Umstellung dann so:

Ein Rückfallplan ist kein Eingeständnis des Scheiterns, sondern eine Versicherung. Halten Sie vorab fest, was Sie zur Rückkehr bewegen würde, etwa ein Fehler in den Rechnungen oder der Stillstand eines Kernprozesses, wer darüber entscheidet und wie die Benutzer zum alten System zurückkommen. Schalten Sie das alte System erst endgültig ab, wenn die Stabilisierungsphase vorbei ist. Was in den ersten Wochen nach einem Wechsel typischerweise schiefgeht, beschreiben wir in Die ersten dreißig Tage nach der Migration.

Die Sicht von Origami

Wir behandeln die Umstellung als Managemententscheidung, nicht als technisches Ereignis. Deshalb bauen wir den Vergleich zwischen den beiden Systemen, bevor wir das neue System selbst bauen, und stimmen früh mit den Prozessverantwortlichen die seltenen Fälle und ihre erwarteten Ergebnisse ab, damit die Definition von Erfolg feststeht, bevor jemand die Ergebnisse sieht.

Wir nutzen KI, um die Konvertierung zu beschleunigen und Tests zu erzeugen, doch die Freigabe jedes Moduls bleibt bei namentlich benannten Personen in Ihrem Team. Wie wir arbeiten, sehen Sie bei unseren Leistungen.

Die Übung dieser Woche: ein Umstellungsblatt pro Modul

Füllen Sie für jedes System, das Sie in Teil 5 konvertieren oder neu bauen wollten, dieses Blatt mit den Prozessverantwortlichen aus, bevor Sie einen Umstellungstermin festlegen:

Das sind Beispiele zur Veranschaulichung; Ihr Blatt wird anders aussehen. Wichtig ist, dass kein Umstellungstermin feststeht, bevor jedes Modul zwei namentlich benannte Unterzeichner und einen schriftlichen Rückfallauslöser hat.

Was als Nächstes kommt

Eine Frage bleibt, die jede Führungskraft stellt, bevor sie Code und Daten an ein KI-Werkzeug schickt: Wohin gehen meine Daten während der Modernisierung? Teil 7, der letzte Teil, beantwortet sie und fasst die Übungen der gesamten Serie in einem 90-Tage-Plan zusammen.

Quellen

• Microsoft: Migration durchführen, Cloud Adoption Framework — Treffen zu Rückfallkriterien, Änderungsstopp, Datenprüfung, 24 bis 48 Stunden Überwachung und Beibehaltung der Quellumgebung als Rückfalloption.
• Amazon: Transformation von Mainframe-Anwendungen in AWS Transform — Testpläne, Skripte zur Testdatenerfassung und der Reforge-Schritt.
• Amazon: Ankündigung von Thought Machine und AWS zu Migrationen von Bankensystemen — die vier Stufen und die Freigabe durch Engineering- und Risikoteams.
• AWS Transform: offizielle Seite.