Wenn heute über künstliche Intelligenz und Legacy-Modernisierung gesprochen wird, steht fast immer eine Sprache im Mittelpunkt: COBOL. Das ist verständlich. COBOL ist bekannt, geschäftskritisch, historisch aufgeladen und medial hervorragend verwertbar. Die Geschichte schreibt sich fast von allein: Eine jahrzehntealte Programmiersprache trifft auf generative KI, und plötzlich scheint die Modernisierung alter Kernsysteme nur noch eine Frage guter Prompts zu sein.
Das klingt modern. Das klingt effizient. Und es klingt vor allem sehr gut in Überschriften.
Die Realität in den IT-Landschaften großer Unternehmen ist allerdings etwas weniger glamourös. Denn wer Legacy-Modernisierung ernsthaft betreibt, weiß: COBOL ist oft nur der sichtbarste Teil eines deutlich größeren Ökosystems. Dahinter stehen Programmiersprachen wie Assembler, PL/I und RPG, dazu kommen JCL, CL, Datenbanken, Scheduler, Transaktionssysteme, Schnittstellen, Datenflüsse, Batch-Ketten, Copybooks, Makros und jahrzehntelang gewachsene Betriebslogik.
Mit anderen Worten: Der Hype zeigt gern auf den Quellcode. Die eigentliche Komplexität sitzt aber im Zusammenhang.
COBOL bekommt die Bühne, weil COBOL die bessere Geschichte ist
COBOL eignet sich hervorragend als Symbol für Legacy-IT. Die Sprache steht für Stabilität, lange Laufzeiten, kritische Geschäftsprozesse und Systeme, die nicht selten seit Jahrzehnten zuverlässig das tun, was sie tun sollen. In Banken, Versicherungen, Behörden, Industrieunternehmen und Handelsorganisationen laufen bis heute zentrale Geschäftsprozesse auf Anwendungen, deren fachliche Logik in COBOL oder vergleichbaren Legacy-Sprachen implementiert ist.
Genau deshalb ist COBOL für die KI-Debatte so attraktiv. „KI modernisiert COBOL“ ist eine einfache Botschaft. Sie ist verständlich, anschlussfähig und lässt sich auch außerhalb der Mainframe-Community gut erzählen.
Nur ist sie eben nicht vollständig.
IBM positioniert watsonx Code Assistant for Z beispielsweise ausdrücklich im Kontext der Mainframe-Modernisierung und adressiert dabei nicht nur COBOL, sondern auch PL/I-Anwendungen, etwa durch Analyse, Refactoring und die Bildung modularer Business Services. AWS wiederum beschreibt für die Mainframe-Modernisierung mit KI nicht bloß eine Übersetzung einzelner Programme, sondern die Analyse ganzer Anwendungslandschaften, inklusive Code-Struktur, Laufzeitverhalten und Datenbeziehungen.
Das ist ein wichtiger Unterschied. Denn erfolgreiche Modernisierung beginnt nicht mit der Frage, ob eine KI syntaktisch gültigen Zielcode erzeugen kann. Sie beginnt mit der Frage, ob ein Unternehmen seine bestehenden Systeme überhaupt vollständig verstanden hat.
Und genau hier wird es spannend.
Assembler, PL/I und RPG: weniger Hype, aber nicht weniger Relevanz
Dass über COBOL so viel gesprochen wird und über Assembler, PL/I oder RPG deutlich weniger, liegt nicht daran, dass diese Sprachen unwichtig wären. Im Gegenteil: In vielen Organisationen sind sie Bestandteil hochkritischer Anwendungslandschaften. Sie sind nur weniger präsent im öffentlichen Diskurs, weil sie spezieller, technischer und weniger leicht zu vermarkten sind.
Assembler ist ein gutes Beispiel. Während COBOL zumindest sprachlich noch stark an Geschäftslogik erinnert, bewegt sich Assembler deutlich näher an Systemlogik, Speicherstrukturen, Makros, Registerverwendung und plattformnahen Abläufen. Das ist für KI-Marketing ungefähr so dankbar wie ein dreistündiger Vortrag über Abendverarbeitung in einem historisch gewachsenen Batch-Fenster. Fachlich hoch relevant, aber nicht unbedingt der Stoff, aus dem virale Headlines gemacht werden.
Für Assembler existieren Modernisierungspfade, bei denen Assembler-Programme und Makros zunächst in besser wartbare Strukturen oder andere Zielsprachen überführt werden. Schon dieser Ansatz zeigt, dass Assembler nicht einfach als weiterer Kandidat für „Prompt rein, Java raus“ behandelt werden kann.
PL/I wiederum ist in vielen Mainframe-Landschaften tief verankert, aber außerhalb der Fachcommunity deutlich weniger bekannt als COBOL. Dabei ist PL/I keineswegs ein Randthema. Auch hier gibt es inzwischen Ansätze für KI-gestützte Analyse, Erklärung, Refactoring und Transformation. Nur ist PL/I eben weniger prominent im öffentlichen Schaufenster der Legacy-Debatte.
RPG schließlich lebt in einem anderen Ökosystem: IBM i. Dort ist RPG vielfach das Rückgrat stabiler Unternehmensanwendungen, etwa in Handel, Produktion, Logistik oder mittelständisch geprägten Branchenstrukturen. Auch hier geht es nicht nur um eine Programmiersprache, sondern um ein gesamtes Betriebs- und Anwendungsökosystem mit Datenbanken, Jobsteuerung, Schnittstellen, Masken, Reports und historisch gewachsener Fachlogik.
Die Schlussfolgerung ist eindeutig: Der Markt bewegt sich längst nicht mehr nur rund um COBOL. Aber COBOL bleibt das Schaufenster, weil es die einfachste Geschichte erzählt.
KI sieht Code. Experten sehen Kontext.
Der zentrale Fehler vieler Modernisierungsdebatten liegt darin, Legacy-Systeme primär als Codeproblem zu betrachten. Natürlich ist Code wichtig. Ohne Quellcode keine Analyse, keine Transformation, kein Refactoring und keine Testautomatisierung. Aber in geschäftskritischen Systemen ist der Code nur ein Teil der Wahrheit.
Die eigentliche Semantik entsteht häufig erst durch das Zusammenspiel vieler Ebenen. Ein COBOL-Programm ist nicht isoliert zu betrachten, wenn seine Eingaben aus bestimmten Batch-Ketten kommen, seine Datenstrukturen über Copybooks definiert sind, seine Verarbeitung durch JCL gesteuert wird und seine Ergebnisse regulatorisch nachweisbar bleiben müssen. Ein PL/I-Modul ist nicht vollständig verstanden, wenn man seine Schnittstellen nicht kennt. Ein RPG-Programm auf IBM i lässt sich nicht seriös bewerten, wenn Datenbankzugriffe, CL-Programme, Display Files, Jobsteuerung und Geschäftsprozesse ignoriert werden. Und bei Assembler kann eine scheinbar kleine technische Annahme eine große fachliche Wirkung haben.
Genau deshalb ist der Satz „KI kann Legacy modernisieren“ zwar nicht falsch, aber gefährlich unvollständig.
Richtig wäre: KI kann Legacy-Modernisierung massiv beschleunigen, wenn sie in einen kontrollierten, nachvollziehbaren und fachlich validierten Transformationsprozess eingebettet wird.
Dazu gehören deterministische Analyseverfahren, Abhängigkeitsmodelle, Datenflussanalysen, Teststrategien, Fachexpertise, Plattformwissen und eine klare Governance. Moderne KI-Ansätze können Codebasen analysieren, Dokumentation erzeugen, Geschäftslogik extrahieren, monolithische Strukturen zerlegen, Transformationsprozesse unterstützen und menschliche Eingaben gezielt einbinden.
Das ist weit entfernt von der Vorstellung, man könne jahrzehntelang gewachsene Kernsysteme einfach mit ein paar Prompts neu erfinden. So schön diese Vorstellung auch wäre.
Das eigentliche Risiko ist nicht Legacy. Das eigentliche Risiko ist fehlendes Verständnis.
Viele Unternehmen stehen heute vor einer strategischen Herausforderung: Sie müssen modernisieren, ohne die Stabilität ihrer geschäftskritischen Prozesse zu gefährden. Gleichzeitig geht Wissen verloren. Expertinnen und Experten gehen in den Ruhestand. Dokumentationen sind unvollständig. Historische Entscheidungen sind nicht mehr nachvollziehbar. Und nicht selten weiß das Unternehmen zwar, dass ein System funktioniert, aber nicht mehr vollständig, warum es funktioniert.
Das ist der Punkt, an dem KI einen echten Mehrwert liefern kann.
Nicht als Zauberstab. Sondern als Verstärker.
KI kann helfen, Code zu erklären, Strukturen sichtbar zu machen, Dokumentation zu erzeugen, Testfälle vorzubereiten, technische Schulden zu identifizieren und Wissen für neue Generationen von Entwicklerinnen und Entwicklern zugänglicher zu machen. Sie kann insbesondere dort wertvoll sein, wo große Codebestände systematisch analysiert und in verständliche Zusammenhänge gebracht werden müssen.
Aber KI ersetzt nicht die Verantwortung. Sie ersetzt nicht die fachliche Validierung. Sie ersetzt nicht das Plattformverständnis. Und sie ersetzt schon gar nicht die Notwendigkeit, geschäftskritische Systeme mit der nötigen Sorgfalt zu behandeln.
Das gilt für COBOL. Und es gilt noch stärker für Assembler, PL/I und RPG.
Legacy-Modernisierung muss ganzheitlicher gedacht werden
Die aktuelle COBOL-und-KI-Debatte ist wichtig, aber sie greift zu kurz, wenn sie nicht auf das gesamte Legacy-Portfolio ausgeweitet wird. Unternehmen sollten sich nicht allein fragen, ob sie COBOL automatisiert analysieren oder transformieren können. Sie sollten sich fragen, wie gut sie ihre gesamte Anwendungslandschaft verstehen.
Dazu gehören mehrere strategische Fragen:
- Welche Sprachen und Technologien sind tatsächlich im Einsatz?
Nicht nur COBOL, sondern auch PL/I, Assembler, RPG, Natural, JCL, CL und weitere Bestandteile historisch gewachsener Systeme. - Welche Abhängigkeiten bestehen zwischen Programmen, Daten, Jobs, Schnittstellen und Geschäftsprozessen?
Modernisierung scheitert selten an einem einzelnen Programm. Sie scheitert an übersehenen Zusammenhängen. - Welche fachliche Logik ist kritisch, regulatorisch relevant oder unternehmensspezifisch?
Gerade diese Logik ist oft der eigentliche Wert des Systems. - Welche Rolle kann KI sinnvoll übernehmen?
Analyse, Dokumentation, Refactoring, Testunterstützung und Wissenssicherung sind häufig realistischere und wertvollere Einstiege als eine sofortige Kompletttransformation. - Wo braucht es zwingend menschliche Expertise?
Überall dort, wo fachliche Korrektheit, regulatorische Nachvollziehbarkeit, Plattformverhalten und Produktionssicherheit betroffen sind.
Fazit: Nicht COBOL ist das Problem, sondern die Vereinfachung der Debatte
COBOL ist nicht der Gegner der Modernisierung. Assembler, PL/I und RPG sind es ebenfalls nicht. Diese Technologien sind in vielen Unternehmen nicht deshalb noch vorhanden, weil niemand aufgeräumt hat. Sie sind vorhanden, weil sie über Jahrzehnte stabile, performante und hochspezifische Geschäftsprozesse getragen haben.
Das Problem entsteht erst dann, wenn man diese Systeme nur noch als Altlast betrachtet und ihre fachliche Bedeutung unterschätzt.
KI wird Legacy-Modernisierung verändern. Daran besteht kaum Zweifel. Sie wird Analyse beschleunigen, Wissen zugänglicher machen, Modernisierung strukturieren und neue Formen der Zusammenarbeit zwischen alten und neuen Technologien ermöglichen. Aber sie wird nicht die Notwendigkeit ersetzen, Systeme wirklich zu verstehen.
Die eigentliche Frage lautet daher nicht: „Kann KI COBOL modernisieren?“
Die bessere Frage lautet: „Verstehen wir unser gesamtes Legacy-Portfolio gut genug, um KI verantwortungsvoll darauf anzuwenden?“
Denn COBOL ist nur der Teil, über den alle reden.
Assembler, PL/I, RPG, JCL, CL, Datenbanken, Scheduler, Schnittstellen und jahrzehntelang gewachsene Betriebslogik sind der Teil, über den man besser reden sollte, bevor jemand „Migration abgeschlossen“ in die Projektfolie schreibt.
KI kann viel. Aber Kontext bleibt Chefsache.
Ü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
