COBOL ist wieder da!

Zumindest könnte man diesen Eindruck gewinnen, wenn man die aktuelle Debatte rund um künstliche Intelligenz und Legacy-Modernisierung verfolgt. Plötzlich taucht eine Programmiersprache, die viele längst in die technische Mottenkiste einsortiert hatten, wieder in großen Überschriften auf. Nicht als nostalgisches Sammlerstück aus der Frühzeit der Unternehmens-IT, sondern als Prüfstein für eine sehr moderne Frage: Kann KI gewachsene Unternehmenssysteme schneller verstehen, übersetzen und modernisieren?

Die Antwort ist unbequem. Sie lautet: Ja, aber nicht so einfach, wie es manche Schlagzeile vermuten lässt.

Denn COBOL war nie wirklich weg. Es lief einfach weiter. Still, zuverlässig und meist unbeeindruckt von dem, was die IT-Branche in schöner Regelmäßigkeit als nächste Revolution ausruft. Während draußen Microservices, Cloud-native, Low-Code, No-Code und nun generative KI gefeiert wurden, haben COBOL-Systeme weiter Konten geführt, Versicherungen berechnet, Zahlungen verarbeitet, Renten ausgezahlt und Geschäftsprozesse am Laufen gehalten.

Vielleicht ist genau das der Grund, warum COBOL nun wieder so gut als Symbol funktioniert. Es steht für alles, was viele Unternehmen gleichzeitig schätzen und fürchten: Stabilität, Geschäftskritikalität, lange Historie, schwer dokumentierte Fachlogik und Systeme, die oft besser funktionieren als ihr Ruf.

Warum ausgerechnet COBOL?

Die aktuelle Aufmerksamkeit bekam Anfang 2026 zusätzlichen Schub, als Anthropic COBOL-Modernisierung als Beispiel dafür nutzte, wie KI die Kosten und Hürden bei der Ablösung alter Systeme senken könne. Im Mittelpunkt standen dabei weniger romantische Mainframe-Geschichten als sehr konkrete Aufgaben: Codeanalyse, Dokumentation, Abhängigkeitsanalyse, Risikobewertung und Unterstützung bei Modernisierungspfaden.

Die Reaktion blieb nicht auf Fachkreise beschränkt. Reuters berichtete kurz darauf, dass IBM nach der Anthropic-Kommunikation den stärksten Tagesverlust seit dem Jahr 2000 verzeichnete. Ob eine solche Börsenreaktion die technische Realität angemessen widerspiegelt, darf man bezweifeln. Interessant ist sie trotzdem. Sie zeigt, dass COBOL-Modernisierung plötzlich nicht mehr nur ein Thema für Mainframe-Spezialisten ist, sondern auch für Investoren, Analysten und die breite Technologiedebatte.

COBOL ist damit nicht zurück, weil die Welt neue COBOL-Anwendungen bauen möchte. COBOL ist zurück, weil KI-Anbieter an dieser Sprache zeigen wollen, dass sie eines der teuersten und schwierigsten Probleme der Unternehmens-IT lösen können: das Verstehen gewachsener Systeme.

Und genau hier beginnt der spannende Teil.

Der alte Code und das neue Versprechen

Die Erzählung ist verführerisch einfach. Man nimmt einen alten COBOL-Codebestand, gibt ihn in ein KI-Werkzeug, wartet einen Moment und erhält am Ende modernen Code, möglichst cloudfähig, dokumentiert, getestet und wartbar.

Klingt gut.

Es ist nur ungefähr so realistisch wie die Ansage: „Wir tauschen mal eben das Fundament eines Hochhauses aus, während im 17. Stock die Monatsabschlüsse laufen.“

Denn ein COBOL-System besteht selten nur aus COBOL. Es besteht aus Copybooks, Datenstrukturen, Batch-Ketten, JCL, CICS-Transaktionen, Datenbankzugriffen, Schnittstellen, Jobabhängigkeiten, Fehlerbehandlungen, Betriebswissen und fachlichen Sonderfällen. Oft steckt darin die Erfahrung aus Jahrzehnten produktiven Betriebs. Nicht immer schön. Nicht immer modern. Aber häufig geschäftskritisch.

Wer nur den Quellcode betrachtet, sieht vielleicht Syntax. Aber noch lange kein System.

Genau darauf weist auch IBM in seiner Reaktion auf die aktuelle KI-Code-Debatte hin. Codeübersetzung sei nicht dasselbe wie Modernisierung. Gerade Enterprise-Anwendungen auf IBM Z seien tief in Plattform, Datenhaltung, Sicherheit, Transaktionsverarbeitung, Skalierung und Betrieb eingebettet. Mit anderen Worten: Das Problem steckt nicht nur in der Programmiersprache. Es steckt im Zusammenspiel.

Das ist keine Verteidigungsrede für Stillstand. Es ist eine notwendige Erinnerung an die Realität.

Eine Anwendung wird nicht dadurch modern, dass sie in einer anderen Sprache geschrieben ist. Neuer Code ist noch keine neue Architektur. Und eine modernere Dateiendung löst keine fachlichen Altlasten.

Codeübersetzung ist nicht Modernisierung

Der vielleicht wichtigste Satz in der ganzen Debatte lautet deshalb:

Codeübersetzung ist nicht Modernisierung.

Codeübersetzung kann ein Baustein sein. In manchen Szenarien sogar ein sinnvoller. Aber sie ist nicht das Ziel. Eine übersetzte Anwendung ist nicht automatisch besser verstanden, besser testbar, besser integrierbar oder fachlich sauberer geschnitten.

Das gilt übrigens nicht nur für COBOL. Viele Legacy-Landschaften bestehen aus einer Mischung unterschiedlicher Sprachen, Plattformen, Datenbanken, Scheduler, Schnittstellen und Betriebsprozesse. COBOL bekommt nur die meiste Aufmerksamkeit, weil der Name groß genug ist, um Schlagzeilen zu produzieren. Die eigentliche Herausforderung ist breiter: In vielen Bestandssystemen steckt Fachlogik, die Unternehmen bis heute trägt, aber nicht mehr ausreichend transparent ist.

Und genau hier kann KI sehr wertvoll werden.

Nicht als magischer Migrationsknopf. Nicht als digitale Abrissbirne. Nicht als Werkzeug, das aus 40 Jahren gewachsener Fachlogik per Knopfdruck eine perfekte Zielarchitektur erzeugt.

Sondern als Analysewerkzeug.

KI kann Code erklären, Muster erkennen, Abhängigkeiten sichtbar machen, Datenflüsse nachvollziehen, Dokumentationsentwürfe erzeugen, Testideen ableiten und Modernisierungsteams schneller zu einem belastbaren Gesamtbild führen. IBM nennt selbst mehrere Einsatzfelder für KI in der COBOL-Modernisierung, darunter Code Understanding, Refactoring, Code Conversion, Testgenerierung und Dokumentation.

Auch Thoughtworks ordnet die Diskussion differenziert ein. Erfolgreiche KI-gestützte Modernisierung bestehe nicht aus einem einzelnen Prompt, sondern aus strukturierten Vorgehensweisen: Code wird zerlegt, lokal analysiert, zusammengeführt, validiert und in einen größeren fachlichen und technischen Kontext gestellt.

Das klingt weniger spektakulär als ein „COBOL-to-Cloud“-Knopf. Es ist aber erheblich näher an der Wirklichkeit.

Modernisierung beginnt nicht mit dem Zielcode

Auch aus der Praxis der Mainframe-Modernisierung kommt derselbe Hinweis: Der erste Schritt ist nicht die Übersetzung, sondern die saubere Bestandsaufnahme. EasiRun beschreibt Mainframe-Modernisierung als schrittweisen Prozess, der mit Analyse des Ist-Zustands, Zieldefinition, Risikominimierung, automatisierten Tests, Parallelbetrieb, Interoperabilität sowie Schulung und Change Management verbunden ist.

Das ist ein wichtiger Gegenpol zur Vorstellung, Modernisierung beginne mit der Wahl einer neuen Programmiersprache. Sie beginnt mit einer nüchternen Frage: Was ist eigentlich vorhanden, was davon ist fachlich wertvoll, was ist technisch riskant und welcher Weg führt mit vertretbarem Risiko in eine bessere Zukunft?

Passend dazu stellt EasiRun im Bereich „Modernes Legacy“ nicht den reflexhaften Austausch von Bestandssystemen in den Mittelpunkt, sondern die Nutzung vorhandener Werte. Modernisierung wird dort nicht als Einheitslösung verstanden, sondern als individuell zu bestimmender Weg zwischen Konsolidierung, Modernisierung und Transformation.

Dieser Blick ist wichtig. Denn viele Legacy-Systeme sind nicht deshalb problematisch, weil sie alt sind. Sie werden problematisch, wenn sie nicht mehr verstanden, nicht mehr wirtschaftlich weiterentwickelt oder nicht mehr sinnvoll integriert werden können. Die Aufgabe besteht also nicht darin, Alter pauschal zu beseitigen. Die Aufgabe besteht darin, Wert von Risiko zu unterscheiden.

Auch beim Thema Code Transformation zeigt sich dieser Unterschied. Eine Transformation von Code kann ein wichtiger Baustein sein, aber sie muss in ein methodisches Vorgehen eingebettet werden. Nur dann wird aus technischer Übersetzung ein belastbarer Modernisierungsschritt.

Die eigentliche Stärke der KI liegt im Verstehen

Wenn KI in der Legacy-Modernisierung ihren Platz findet, dann wahrscheinlich nicht dort, wo sie am lautesten beworben wird. Nicht in der schnellen Vollautomatisierung ganzer Migrationsvorhaben. Sondern im mühsamen, aber entscheidenden Teil davor: im systematischen Aufbau von Verständnis.

Was macht das System fachlich wirklich? Welche Komponenten sind kritisch? Welche Regeln müssen erhalten bleiben? Wo liegen technische Risiken? Welche Teile sind historisch gewachsen, aber fachlich noch hochrelevant? Welche Strukturen dürfen verändert werden, ohne den Betrieb zu gefährden?

Das sind keine nebensächlichen Detailfragen. Sie entscheiden darüber, ob Modernisierung gelingt oder nur teurer neuer Code entsteht.

Futurum beschreibt in seiner Analyse der IBM-Anthropic-Debatte genau diese Breite. Erfolgreiche COBOL-Modernisierung erfordert neben möglicher Codeübersetzung unter anderem fachliche Abgrenzung, technische Bewertung, Datenmigrationsplanung, Validierung der fachlichen Gleichwertigkeit, Beobachtbarkeit und organisatorisches Change Management.

Das ist der Punkt, an dem viele Heilsversprechen dünn werden. Nicht, weil KI nichts kann. Sondern weil Modernisierung mehr ist als Transformation von Text.

Ein Programm ist nicht nur Code. Es ist Fachlichkeit, Betriebserfahrung, Datenhistorie, Risiko, Governance und oft auch ein Stück Unternehmensgedächtnis.

COBOL gegen KI ist die falsche Debatte

In der öffentlichen Diskussion klingt es manchmal so, als müssten sich Unternehmen entscheiden: COBOL oder KI, Mainframe oder Cloud, alt oder neu.

Das ist die falsche Gegenüberstellung.

Die bessere Frage lautet: Wie machen wir geschäftskritische Bestandssysteme wieder verständlich, bewertbar und planbar modernisierbar?

Genau dort kann KI ihren größten Nutzen stiften. Sie ersetzt nicht die fachliche Verantwortung. Sie ersetzt nicht Architekturarbeit. Sie ersetzt nicht Erfahrung. Aber sie kann helfen, die Menge an Code, Abhängigkeiten, Datenflüssen und Dokumentationslücken schneller zu durchdringen.

Oder kurz gesagt:

KI ersetzt nicht das Systemverständnis. KI kann helfen, es schneller aufzubauen.

Das ist ein großer Unterschied.

Wer COBOL nur übersetzt, bekommt neuen Code. Wer COBOL analysiert, bekommt Orientierung. Wer COBOL versteht, kann sinnvoll modernisieren.

Erst verstehen. Dann bewerten. Dann modernisieren.

Für Unternehmen ergibt sich daraus ein pragmatischer Dreiklang.

Zuerst muss verstanden werden, wie ein System wirklich funktioniert: technisch, fachlich und betrieblich. Danach folgt die Bewertung: Was ist stabiler Kernprozess, was ist technisches Risiko, was ist modernisierungswürdig, was sollte bewusst erhalten bleiben? Erst anschließend sollte entschieden werden, ob Refactoring, Modularisierung, API-Fähigkeit, Testautomatisierung, Plattformmodernisierung, schrittweise Migration oder gezielte Ablösung der richtige Weg ist.

Diese Reihenfolge klingt banal. In vielen Modernisierungsprojekten ist sie aber der Unterschied zwischen Fortschritt und Folgekosten.

Denn wer die Analyse überspringt, spart am Anfang Zeit und bezahlt am Ende mit Risiko.

Legacy ist nicht automatisch Ballast

Vielleicht ist das die wichtigste Botschaft der aktuellen KI-Debatte: Legacy ist nicht automatisch das Problem. Oft ist Legacy dokumentierter Geschäftserfolg in ausführbarer Form.

Natürlich gibt es technische Schulden. Natürlich gibt es veraltete Strukturen, Wissensrisiken und Integrationsprobleme. Natürlich müssen Systeme modernisiert werden, wenn sie nicht mehr entwicklungsfähig, sicher oder wirtschaftlich betreibbar sind.

Aber die bloße Existenz von COBOL, Batch, CICS oder anderen Legacy-Bestandteilen ist noch kein Beweis für Rückständigkeit. Häufig handelt es sich um Anwendungen, die zentrale Geschäftsprozesse über Jahrzehnte stabil getragen haben. Sie verdienen keine reflexhafte Abrisslogik, sondern eine professionelle Analyse.

KI kann dabei ein Wendepunkt sein. Nicht, weil sie Modernisierung automatisch erledigt. Sondern weil sie helfen kann, Systeme wieder lesbar zu machen, deren Verständnis bisher zu teuer, zu langsam oder zu abhängig von einzelnen Experten war.

Vielleicht wird COBOL durch KI also gar nicht abgelöst.

Vielleicht wird COBOL durch KI endlich wieder ernsthaft analysierbar.

Und vielleicht liegt genau darin die eigentliche Chance: bessere Architekturentscheidungen, weniger Migrationsrisiko, belastbarere Zielbilder und eine Modernisierung, die nicht gegen die Vergangenheit arbeitet, sondern auf ihrem Wert aufbaut.

Die Zukunft der Legacy-Modernisierung beginnt nicht mit Übersetzung. Sie beginnt mit Verstehen.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet