COBOL-Modernisierung mit KI

TL;DR. Ein großer Teil der deutschen Wirtschaft läuft auf Code, den kaum noch jemand lesen kann. KI übersetzt diesen Code nicht per Knopfdruck in ein neues System. Sie macht das Teuerste an jeder Modernisierung billiger: das Verstehen. Der belastbare Weg hat drei Schichten: Altcode verstehen, sein Verhalten mit Tests festhalten, dann Funktion für Funktion übersetzen. Die Modelle sind 2026 deutlich besser geworden. Ganze Programme ohne einen einzigen Fehler zu übertragen, gelingt aber weiterhin selten.

Kernbanken, Versicherungsbestände, die öffentliche Verwaltung: Ihre kritischsten Prozesse stecken in COBOL-Programmen, die seit Jahrzehnten zuverlässig laufen und genau deshalb niemand anfasst. Das Problem ist nicht die Technik. Das Problem ist, dass die Menschen, die diese Systeme verstehen, in Rente gehen und ihr Wissen mitnehmen.

COBOL-Modernisierung mit KI wird gerade deshalb zum Thema. Der Engpass jeder Legacy-Modernisierung war nie das Neuschreiben. Es war das Verstehen dessen, was das alte System eigentlich tut. Genau hier verschiebt KI die Kosten.

Warum der große Wurf scheitert

Die Geschichte der IT ist voll von gescheiterten Big-Bang-Rewrites. Ein Team schreibt das Altsystem über Jahre komplett neu. Am Stichtag stellt sich heraus, dass das neue System Hunderte ungeschriebene Geschäftsregeln nicht kennt, die im alten über Jahrzehnte gewachsen sind. In Bank, Versicherung oder Behörde ist dieser Schaden existenzbedrohend. Wer eine Bestandsführung oder ein Zahlungssystem über Nacht umstellt, riskiert genau das.

Die belastbare Alternative ist seit Jahren bekannt und heißt Strangler-Fig-Muster. Man legt das neue System wie eine Würgefeige um das alte, löst Funktion für Funktion heraus und ersetzt sie, während der Rest weiterläuft. KI macht dieses Vorgehen nicht überflüssig. Sie macht es schneller und sicherer.

Erste Schicht: Altcode verstehen und dokumentieren

Eine KI kann ein COBOL-Programm lesen und in verständlicher Sprache erklären, was es tut: welche Geschäftsregeln darin stecken, welche Datenflüsse, welche Sonderfälle. Aus undokumentierten Programmen wird eine durchsuchbare Wissensbasis. Das ersetzt nicht das Urteil einer erfahrenen Entwicklerin. Aber es gibt ihr in Stunden einen Überblick, für den sie früher Wochen gebraucht hätte. Bei der COBOL-Modernisierung mit KI ist das der erste, konkrete Hebel.

Die Modelle können inzwischen auch große Bestände auf einmal sehen. Die aktuellen Claude-Modelle verarbeiten zum Beispiel bis zu einer Million Token Kontext zum normalen Preis. Für eine ganze Enterprise-Codebasis reicht das trotzdem selten. Deshalb arbeitet man programmweise und hält die Ergebnisse in einer Wissensbasis fest.

Zweite Schicht: Tests als Sicherheitsnetz

Bevor man eine einzige Zeile Altsystem anfasst, braucht man ein Netz, das sein Verhalten festhält. Charakterisierungstests sind dieses Netz. Sie prüfen nicht, was das System tun soll, sondern was es tatsächlich tut. Solche Tests von Hand zu schreiben, ist mühsam. Genau das kann KI in großem Umfang vorbereiten: Eingaben und erwartete Ausgaben aus dem Altsystem ableiten, sodass jede spätere Migration gegen das dokumentierte Ist-Verhalten geprüft wird.

Erst das Sicherheitsnetz, dann die Migration. Ein Charakterisierungstest, den die KI vorbereitet und ein Mensch geprüft hat, fängt den Fehler ab, bevor er in Produktion geht.

Wie leicht ein Fehler durchrutscht, zeigt ein Beispiel aus unserem Beitrag zu OpenAIs COBOL-Messung: COBOL schneidet überzählige Nachkommastellen ab, eine Neufassung in Java rundet kaufmännisch. Beide laufen fehlerfrei. Bei einer Million Zinsbuchungen weicht trotzdem jede zweite um einen Cent ab. Ein Test, der nur prüft, ob das neue Programm läuft, findet das nicht. Ein Vergleich mit den alten Ausgaben findet es sofort.

Dritte Schicht: inkrementell übersetzen

Mit Verständnis und Testnetz wird die eigentliche Migration beherrschbar. Die KI schlägt für eine herausgelöste Funktion eine Übersetzung in die Zielsprache vor, etwa Java oder was sonst zur Zielarchitektur passt. Der Mensch prüft, die Tests bestätigen, dass sich das Verhalten nicht verändert hat. So wandert Funktion für Funktion vom Mainframe in die neue Welt, ohne dass der Betrieb je stillsteht. Das ist das Gegenteil des Big Bang: kleine, geprüfte, umkehrbare Schritte.

Werkzeuglandschaft 2026: Wer kann was

Der Werkzeugmarkt hat sich entlang einer Frage sortiert: Wollen Sie den Mainframe verlassen, oder wollen Sie auf ihm modernisieren? Die Werkzeugwahl folgt dem Zielbild, nicht umgekehrt. Wer zuerst ein Werkzeug kauft und dann eine Strategie sucht, hat die Reihenfolge vertauscht.

• IBM watsonx Code Assistant for Z setzt seit Version 2.8 vom Dezember 2025 auf einen agentischen Ablauf für die Modernisierung auf der Plattform: Abhängigkeiten erkennen, Auswirkungen analysieren, Code nach Standards erzeugen, Build und Kompilierung prüfen. Werkzeuge hängen über das Model Context Protocol an. Das Zielbild dahinter: Der Mainframe bleibt, der Code wird beherrschbar.
• AWS Transform for mainframe ist der Weg für den Ausstieg in die Cloud, als agentischer Dienst von der Bestandsaufnahme über das Herauslösen von Geschäftsregeln bis zur Übersetzung nach Java. Wichtig für laufende Planungen: Die selbst verwaltete Variante von AWS Mainframe Modernization nimmt seit Sommer 2026 keine Neukunden mehr an. Der Weg führt bei AWS jetzt über Transform.
• Claude Code zielt auf die Analyse. Am 23. Februar 2026 hat Anthropic beschrieben, wie Claude Code Abhängigkeiten kartiert, Abläufe dokumentiert und Risiken in Altcode benennt. Wie ernst der Markt das nahm, zeigte die Börse: Die IBM-Aktie verlor an diesem Tag rund 13 %, der schlechteste Handelstag seit Oktober 2000. Code lesen ist trotzdem nicht Code verstehen.
• Rocket Software hat im Mai 2024 das Modernisierungsgeschäft von OpenText übernommen, das aus Micro Focus stammt. Damit bedient Rocket das vierte Zielbild: COBOL behalten, aber die Plattform wechseln, ohne Neuschreiben.

Zur ehrlichen Einordnung gehört, was Sprachmodelle heute messbar können und was nicht. Drei Messungen zeigen, wie stark das Ergebnis davon abhängt, was man prüft.

• COBOLEval lässt 146 Aufgaben in COBOL lösen. Laut einer Studie vom April 2026 kompiliert bei GPT-4o nur 41,8 % des Codes, beim ersten Versuch richtig sind 16,4 %. Ein eigens auf COBOL trainiertes Modell kommt auf 73,95 % und 49,33 %.
• OpenAIs COBOL-Migration vom 19. Oktober 2026 misst das Übertragen von COBOL-Programmen in moderne Sprachen. GPT-6.1 Sol schafft 86,6 % fehlerfrei, sein Vorgänger 5,4 %, mit mehr Rechenzeit sind es 97,9 %. Gemessen hat der Hersteller selbst.
• Vals AI prüft unabhängig ganze Programme (Stand 19. Oktober 2026), 120 Migrationen mit je 100 bis 400 verborgenen Tests. Das beste Modell besteht 86,9 % der Tests. Alle Tests besteht es nur bei 18 von 120 Migrationen.

Dass Verifikation der Schlüssel ist, zeigt auch die Forschung. Der Ansatz SEDCoT koppelt die Übersetzung durch ein Sprachmodell an symbolische Ausführung und Delta-Debugging: Tests entstehen automatisch, fehlgeschlagene Fälle gehen zur Reparatur an das Modell zurück. Das bestätigt die zweite Schicht dieses Beitrags. Ohne Testnetz ist jedes dieser Werkzeuge ein Blindflug.

Der Realitätscheck: Warum Gartner 70 Prozent scheitern sieht

Wer die Warnung vor dem Big Bang für Schwarzmalerei hält, sollte auf die Analysten schauen. Gartner sagt in einer Pressemitteilung vom 18. Juni 2026 voraus, dass mehr als 70 % der 2026 gestarteten Mainframe-Exit-Projekte ihren erhofften Nutzen nicht erreichen. Der genannte Grund ist bemerkenswert: nicht die Technik des Mainframes, sondern die Überschätzung dessen, was generative KI heute leisten kann. Bis 2030 werden laut Gartner zudem 75 % der Anbieter von Mainframe-Exits ihr Geschäftsmodell wechseln oder vom Markt verschwinden.

Die Empfehlung der Analysten deckt sich mit dem Vorgehen dieses Beitrags: generative KI eher für die Modernisierung am Ort einsetzen als für einen beschleunigten Ausstieg. Genau das leisten die drei Schichten. Sie modernisieren dort, wo das System läuft, in kleinen, geprüften, umkehrbaren Schritten, statt auf einen Stichtag zu wetten, an dem alles zugleich funktionieren muss.

Drei belegte Wege in der DACH-Praxis

Atruvia: Strangler-Fig auf der Plattform. Der IT-Dienstleister der genossenschaftlichen Banken hat laut IBM-Fallstudie rund 85 % seiner Kernbank-Transaktionen im IMS Java-fähig gemacht, etwa 400 Millionen Java-Transaktionen am Tag. Java läuft dort neben dem bestehenden COBOL auf dem Mainframe. Eine gemeinsame Laufzeit verbindet 31-Bit-COBOL und 64-Bit-Java, sodass Java einzelne COBOL-Unterprogramme ersetzen kann, ohne große Programme neu zu schreiben. Das ist Refactoring am Ort und das wohl beste DACH-Beispiel für das Strangler-Fig-Vorgehen im Kernbankumfeld.

Deutsche Bank: regelbasierte Transformation. Für den „KreditManager“ der Deutschen Bank dokumentiert eine Fallstudie des Anbieters TSRI die Übertragung von 383.358 Zeilen COBOL und 13.864 Zeilen JCL nach Java, zu 99,7 % automatisiert und in zwölf Monaten. Die Übersetzung war regelbasiert, nicht generativ. Der Fall zeigt: Auch ohne Sprachmodell ist automatische Übersetzung möglich, wenn die Regeln ausdrücklich beschrieben sind. KI ergänzt diesen Weg vor allem beim Verstehen und Absichern.

Deutsche Rentenversicherung: Kernverfahren trägerübergreifend modernisieren. Mit rvEvolution modernisiert die Rentenversicherung gemeinsam über alle Träger ihre Kernverfahren für Rentenberechnung und Kontenführung. Sie nennt es ihr größtes und wichtigstes Vorhaben der nächsten Jahre. Parallel hat die DRV Bund ein eigenes KI-Labor mit Fachkräften aufgebaut. Auch die öffentliche Verwaltung geht den Weg schrittweise.

Was nicht verhandelbar ist

KI erfindet Geschäftsregeln. Ein Sprachmodell kann eine plausible, aber falsche Erklärung für ein COBOL-Programm liefern. In einem Zahlungssystem ist eine falsche Regel teurer als gar keine. Jede KI-Ausgabe muss gegen Tests und gegen menschliches Urteil laufen. Die Verantwortung bleibt beim Team, nicht beim Modell.

Reguliertes Umfeld heißt Revisionssicherheit. In Banken und Versicherungen muss jeder Schritt nachvollziehbar und prüfbar sein. Eine Black Box, die Code ausgibt, den niemand begründen kann, ist hier unbrauchbar. Was zählt, ist eine geprüfte Spur: was wurde übersetzt, gegen welche Tests, von wem freigegeben.

Daten bleiben unter Kontrolle. Quellcode von Kernsystemen ist hochsensibel. Die Modelle, die ihn lesen, gehören auf kontrollierte Infrastruktur mit klarer Rechtslage, nicht in eine beliebige Schnittstelle in fremder Jurisdiktion.

Häufige Fragen zur COBOL-Modernisierung mit KI

Kann ChatGPT oder Claude COBOL wirklich nach Java übersetzen?

Als Startpunkt ja, als fertiges Ergebnis nein. Die neuesten Modelle übertragen in der Messung von OpenAI bis zu 97,9 % der Programme fehlerfrei. Bei ganzen Programmen mit vielen Tests besteht das beste Modell in der unabhängigen Messung von Vals AI aber nur 18 von 120 Migrationen vollständig. Produktionsreif wird eine KI-Übersetzung erst mit Charakterisierungstests und systematischer Prüfung, also mit der zweiten und dritten Schicht.

Was kostet eine COBOL-Modernisierung?

Eine seriöse Zahl gibt es erst nach der Analyse. Die Kosten hängen am Codeumfang, an der Dokumentation, an der vorhandenen Testabdeckung und an der Zielarchitektur, und diese Faktoren streuen zwischen Organisationen enorm. KI senkt vor allem die Kosten für Analyse und Verstehen, nicht die für die Absicherung. Tests, Reviews und Revisionsspur bleiben menschliche Arbeit.

Wie lange dauert eine COBOL-Modernisierung?

Inkrementell gerechnet eher Quartale je fachlicher Domäne als Jahre für das Ganze am Stück. Der entscheidende Unterschied liegt nicht in der Gesamtdauer, sondern im Risiko. Jeder Schritt liefert geprüften Wert und ist umkehrbar.

COBOL ersetzen oder behalten?

Öfter behalten, als viele denken. Gartner rät, generative KI eher für die Modernisierung am Ort einzusetzen, und erwartet, dass mehr als 70 % der 2026 gestarteten Mainframe-Exits ihr Ziel verfehlen. Die richtige Frage ist nicht „COBOL ja oder nein“, sondern: Welche Funktionen brauchen eine neue Heimat, und welche laufen auf der Plattform besser weiter, modernisiert und dokumentiert?

Warum scheitern KI-gestützte Mainframe-Migrationen?

Aus vier wiederkehrenden Gründen: Die Fähigkeiten der Werkzeuge werden überschätzt. Die Codebasis ist größer als das, was ein Modell auf einmal sieht. Code lesen wird mit Fachlogik verstehen verwechselt. Und es fehlen Vergleichstests, die das Ist-Verhalten festhalten. Keiner dieser Gründe ist ein KI-Problem im engeren Sinn. Alle vier sind Methodenprobleme, die das Schichtenmodell adressiert.

Welches Werkzeug: IBM watsonx, AWS Transform oder Claude Code?

Das Zielbild entscheidet, nicht das Werkzeug. Wer auf dem Mainframe bleibt, schaut auf IBM watsonx Code Assistant for Z oder auf Rocket Software (COBOL behalten, Plattform wechseln). Wer in die Cloud aussteigen will, landet bei AWS Transform. Wer zuerst verstehen muss, was das Altsystem tut, beginnt mit der Analyse, dort setzt Claude Code an.

Wie azena das angeht

Wir bauen keine Migrationsplattform von der Stange, sondern maßgefertigte KI für Organisationen, deren Kerngeschäft an einem Altsystem hängt: Verstehen, Absichern, schrittweise Übersetzen, mit menschlicher Prüfung an jedem Schritt. Der ehrliche Startpunkt ist keine Werkzeugauswahl, sondern eine Frage: Welches Altsystem hält Ihr Geschäft zusammen, und wer versteht es noch? Wenn Sie das einmal durchgehen wollen, sprechen Sie uns gern an.