Vom Mainframe in die Cloud: Legacy Software modernisieren ohne Ausfall

Eine Mainframe-Migration scheitert selten an der Zieltechnik und fast immer an dem, was niemand über das Altsystem weiß. Wer ein kritisches Altsystem in die Cloud bringen will, ohne dass der Betrieb steht, braucht deshalb vor allem eine vollständige Karte der Abhängigkeiten und den Verzicht auf den großen Knall.

Warum der Mainframe zum Risiko wird

Mainframes tragen seit Jahrzehnten Kernprozesse, und sie tun das zuverlässig. Das Risiko liegt woanders. Die Lizenz- und Wartungskosten steigen, die Entwickler, die COBOL lesen können, gehen in Rente, und jede neue Anforderung wartet Monate, weil niemand den Code anfassen will. Dazu kommen Vorgaben wie DORA für Finanzunternehmen und NIS2 für weitere Sektoren, die Nachweise über Resilienz und Reaktionsfähigkeit verlangen, die ein undokumentiertes Altsystem nicht liefern kann. Die Migration ist keine Modernisierungslaune. Sie ist der Weg, ein System wieder beherrschbar zu machen.

Das gilt im Mittelstand genauso, auch wenn dort selten ein echter Mainframe steht. Das jahrzehntealte Warenwirtschaftssystem auf einem Server im Keller, das nur noch ein Mitarbeiter versteht, folgt denselben Regeln: Was hier über Mainframes gesagt wird, gilt für jedes Altsystem, an dem der Betrieb hängt.

Legacy Software modernisieren ohne Ausfall: die Abhängigkeitskarte zuerst

Der erste Schritt ist eine vollständige Inventur: alle Schnittstellen, alle Datenflüsse, alle Batch-Läufe, alle Stellen, an denen Geschäftslogik im Code versteckt ist. Ohne diese Karte entstehen die Ausfälle, die später in der Presse stehen. Ein nachgelagertes System, von dem niemand wusste, bekommt nach der Umstellung keine Daten mehr. Automatisierte Code-Analyse hilft, toten Code, ungenutzte Tabellen und kritische Transaktionspfade sichtbar zu machen. Das Ergebnis ist eine priorisierte Reihenfolge, und regelmäßig stellt sich dabei heraus, dass ein erheblicher Teil des Systems gar nicht migriert werden muss, weil ihn niemand mehr nutzt.

Schrittweise statt Big Bang

Der große Knall, bei dem am Wochenende alles umgestellt wird, ist die riskanteste Variante, und sie wird trotzdem gewählt, weil sie im Projektplan am einfachsten aussieht. Der bessere Weg ist das Strangler-Fig-Muster: Neue Dienste wachsen um das Altsystem herum, übernehmen nacheinander einzelne Funktionen, und der Mainframe wird erst abgeschaltet, wenn nichts mehr an ihm hängt. Typischerweise beginnt man mit der Batch-Verarbeitung, die sich gut isolieren lässt, und geht dann zu den Online-Transaktionen über. Jede Stufe läuft im Parallelbetrieb, bis Alt und Neu über einen vollständigen Geschäftszyklus dieselben Ergebnisse liefern. Das dauert länger. Es ist aber die einzige Variante, bei der Sie jederzeit zurückkönnen.

Datenkonsistenz und Compliance von Anfang an

In regulierten Branchen ist die Zielarchitektur keine Nebenfrage. Sie muss von Beginn an auf Souveränität ausgelegt sein: europäischer Cloud-Anbieter, Verschlüsselung auf allen Ebenen, eigene Schlüssel, Redundanz innerhalb Deutschlands oder der EU. Während der Migration müssen Daten in beiden Welten konsistent bleiben; Change-Data-Capture-Verfahren replizieren Änderungen aus dem Altsystem laufend ins neue, sodass der Parallelbetrieb keine Lücken hat. Wer das erst am Ende nachrüstet, holt sich das Audit-Problem ins Zielsystem.

Automatisierte Tests und Monitoring

Ohne automatisierte Regressionstests ist eine Mainframe-Migration ein Blindflug. Der belastbarste Testbestand entsteht aus den historischen Transaktionsprotokollen des Altsystems: dieselben Eingaben ins neue System, Ergebnisse vergleichen, jede Abweichung erfassen und priorisieren. Monitoring nach der Umstellung zeigt, ob Antwortzeiten und Fehlerraten halten, was das Projekt versprochen hat. Die neue Plattform ist meist schneller, aber der Beweis dafür gehört ins Monitoring, nicht in die Projektzusammenfassung.

Wissenstransfer: das Team mitnehmen

Der Verlust von Mainframe-Wissen ist eines der größten Risiken, und die Migration macht ihn nicht kleiner, sondern verschiebt ihn: Jetzt fehlt Cloud-Wissen. Wer parallel zur Migration die eigenen Administratoren und Entwickler in Containerisierung, Dienste-Architektur und Cloud-Sicherheit ausbildet, betreibt die neue Plattform am Ende selbst. Wer das dem Dienstleister überlässt, hat den Mainframe gegen eine neue Abhängigkeit getauscht. Wir übernehmen Migration und Betrieb, aber wir bauen so, dass Ihr Team übernehmen kann.

Häufige Fragen

Wie lange dauert eine Mainframe-Migration?

Das hängt von der Zahl der Module und Schnittstellen ab; für ein mittelgroßes System sind es eher Jahre als Monate. Ein reines „Lift and Shift“ geht schneller, verschiebt aber die Altlasten in die Cloud.

Welche Cloud-Plattform eignet sich?

Für regulierte Unternehmen in Europa eine, die digitale Souveränität garantiert: Rechenzentren in Deutschland oder der EU, Anbieter unter europäischem Recht. Große US-Anbieter sind möglich, erfordern aber zusätzliche vertragliche und technische Maßnahmen.

Kann ich ohne Refactoring migrieren?

Ja, aber Sie nutzen dann die Vorteile der Cloud nicht und behalten die Abhängigkeiten. Mindestens die Geschäftslogik sollte in Dienste zerlegt und die Datenbank auf einen Cloud-Dienst umgestellt werden.

Wie vermeide ich Datenverlust?

Vollständige Sicherung vor Beginn, Parallelbetrieb über einen kompletten Geschäftszyklus, laufender automatisierter Datenabgleich zwischen Alt und Neu.

Ihr nächster Schritt

Zählen Sie die Schnittstellen Ihres Altsystems, von denen Sie sicher wissen, was sie tun, und die, bei denen Sie raten müssten. Mit dieser Liste buchen Sie den kostenlosen Potenzial-Check, eine halbe Stunde, in der wir gemeinsam einschätzen, ob Ihr System eine Migration braucht und welcher Teil zuerst.