Die COBOL-Migration, die perfekt kompilierte — und trotzdem das Hauptbuch beschädigte
Der Code war perfekt. Genau das war das ganze Problem.
Ein Programm für Überweisungen war von COBOL nach Java übersetzt worden. Es ließ sich kompilieren. Die Unit-Tests bestanden. Es passierte jede Prüfschicht, die wir gebaut hatten, um Fehler abzufangen. Dann, im User-Acceptance-Test, brachte die allererste Transaktion die Konsistenzprüfung der Datenbank zum Auslösen, und das Ganze brach zusammen.
Die Fehleranalyse dauerte länger als sie hätte sollen, denn nichts am Java-Code sah falsch aus. Der Übeltäter war eine Variable namens TRN-LIMIT. Das Übersetzungswerkzeug hatte sie als gewöhnliche Zahl gelesen und ihr einen Standard-Integer-Typ zugewiesen. Aber TRN-LIMIT war nirgends dort definiert, wo das Werkzeug suchte. Sie wurde in einem Copybook deklariert — einer gemeinsam genutzten Header-Datei —, das Tausende Zeilen zuvor in die Ausführungskette eingebunden wurde, und dieses Copybook trug eine REDEFINES-Klausel: ein COBOL-Konstrukt, das es erlaubt, denselben Speicherplatz je nach einem ganz woanders gesetzten Flag als zwei völlig unterschiedliche Datentypen zu lesen. Auf dem Mainframe enthielt diese Adresse ein gepacktes Dezimal. Der neue Java-Code schrieb beschädigte Binärdaten in die Datenbankspalte, und die referenzielle Integrität des Hauptbuchs gab nach.
Der Code war syntaktisch fehlerfrei. Das Versagen lag im Kontext. Das Werkzeug hatte eine Abhängigkeit übersehen, die außerhalb seines Sichtfelds lag — und bei der Modernisierung von Legacy-COBOL verschwindet das Geld fast immer genau so.
Modernisierungsprojekte sterben in der Regel nicht an dem Code, den man sehen kann. Sie sterben an dem Code, den das Werkzeug nicht sehen konnte.
Das ist die Geschichte, warum ich aufgehört habe zu glauben, dass bessere Übersetzung die Antwort ist, und was wir bei Veriprajna stattdessen gebaut haben.
Warum funktioniert „COBOL einfügen, Java bekommen“ in der Demo immer?
Wenn Sie in den letzten zwei Jahren in irgendeinem Mainframe-Modernisierungsmeeting gesessen haben, kennen Sie den Pitch: Fügen Sie Ihr COBOL ein, bekommen Sie Java zurück. Er ist verführerisch, weil die Demo immer funktioniert. Jemand wirft ein ordentliches 200-Zeilen-Programm hinein, das Modell liefert sauberes, idiomatisches Java zurück, und alle im Raum atmen auf. Endlich.
Ich habe es eine Zeit lang auch geglaubt. Als mein Team sich zum ersten Mal daran versuchte, taten wir das Naheliegende — wir versuchten, die Übersetzung besser zu machen. Wir fütterten die Modelle mit mehr Kontext, stimmten sie auf COBOLs Eigenheiten ab, maßen die Ausgabequalität mit Benchmarks. Es gibt sogar ein feinabgestimmtes offenes Modell namens XMainframe, eigens dafür gebaut, das bei COBOL-Aufgaben rund 30 % besser abschneidet als allgemeine Code-Modelle. Die Übersetzungen wurden sauberer. Das Java wurde besser lesbar.
Und es brach trotzdem im UAT. Immer wieder, genau an der Art versteckter Abhängigkeit, die jenes Überweisungsprogramm zu Fall gebracht hatte. In diesem Monat wurde mir klar, dass wir das Falsche polierten. Die Qualität der Übersetzung war nie der Engpass. Der Code, der kompiliert, ist der einfache Teil. Der schwierige Teil ist der Code, den das Werkzeug nicht sehen kann.
Die Zahlen dazu sind brutal und beständig: 70 bis 80 % der Mainframe-Modernisierungsprojekte verfehlen ihre Ziele. Nicht 70 % laufen aus dem Zeitplan — 70 % scheitern. Die übliche Diagnose macht unterschätzte Tests oder chaotische Datenmigration verantwortlich, und das ist real. Aber unter fast allen liegt dieselbe Grundursache, die ich gerade live beobachtet hatte: Die Werkzeuge behandeln eine Codebasis als Text, der zu konvertieren ist, während sie in Wirklichkeit eine Topologie ist, die es zu verstehen gilt.
Was „COBOL einfügen, Java bekommen“ nicht sehen kann
Sobald man anfängt, nach kontextueller Blindheit zu suchen, sieht man sie überall. Drei Muster haben uns am häufigsten zu Fall gebracht, und keines davon ist in der Quelldatei sichtbar, auf die ein Übersetzer starrt.
Beginnen wir mit dem Copybook-Problem, das ich bereits beschrieben habe. Ein einziges COBOL-Programm kann auf mehr als vierzig Copybooks verweisen, und diese Copybooks binden weitere Copybooks ein, sodass die eigentliche Definition einer Variablen mehrere Ebenen tief in der Einbindungskette liegen kann. Ein textbasiertes Werkzeug liest die Anweisung, die vor ihm steht, und leitet einen Typ ab. Es hat keine Möglichkeit zu wissen, dass diese Ableitung bei einem gepackten Dezimalfeld stillschweigend falsch ist.
Dann ist da die Arithmetik. COBOLs COMP-3-gepacktes Dezimal hat in Java kein natives Äquivalent. Greifen Sie zu einem double und Sie haben soeben Fließkommarundung in ein System eingeführt, das Geld bewegt. Selbst BigDecimal, das richtige Werkzeug, entspricht COBOL nicht standardmäßig — Sie müssen den Rundungsmodus ausdrücklich auf HALF_EVEN festlegen, um COBOLs ROUNDED-Klausel abzubilden. Machen Sie es falsch, liegen Sie pro Transaktion einen Cent daneben. Dieser Cent summiert sich über Millionen von Transaktionen, bis Wochen später ein Abstimmungsbericht eine Abweichung meldet, die niemand erklären kann.
Das Muster, das fast jeder vergisst, ist genau das, das die Produktion tatsächlich lahmlegt: Ihr COBOL läuft nicht von allein. Ein Scheduler — CA-7 oder TWS — orchestriert irgendwo zwischen zweitausend und fünftausend Batch-Jobs, mit Abhängigkeitsketten, die sich durch sie hindurchziehen. Job A schreibt um 1 Uhr nachts einen Datensatz, den Job B um 2 Uhr liest. Sie können jede Zeile COBOL fehlerfrei migrieren und die Bank trotzdem um Mitternacht lahmlegen, weil niemand das Job-Netzwerk kartiert hat. Der Produktionsgraph stand nie im Quellcode. Er stand im JCL.
Der Job, der um 2 Uhr nachts die Produktion lahmlegt, ist nie derjenige, den man gerade betrachtet hat.
Das meine ich mit Topologie. Das Artefakt, das Ihr Geschäft tatsächlich betreibt, ist ein Netz von Beziehungen — Programme, Copybooks, Datensätze, geplante Jobs, DB2-Tabellen, CICS-Transaktionen — und der COBOL-Quellcode ist nur ein Strang davon.
Warum ich aufgehört habe, dem Übersetzer zu vertrauen, und angefangen habe, die Karte zu zeichnen
Der Wendepunkt für uns war die Entscheidung, dass die Karte das Produkt ist.
Bevor wir eine einzige Zeile übersetzen, bauen wir einen Knowledge Graph der gesamten Codebasis — jedes Programm, jede Copybook-Kante, jede JCL-Abhängigkeit, jede Datensatzübergabe, jeden DB2-Berührungspunkt — und lösen die transitiven Beziehungen auf, die die Quelldateien verbergen. Wenn Sie sehen, dass ein Programm über vierzig Copybook-Kanten hat und dass eine davon zwei Module entfernt ein REDEFINES trägt, passiert das TRN-LIMIT-Desaster schlicht nicht, denn Sie wussten, dass das Feld gepacktes Dezimal war, bevor Sie ein Zeichen Java tippten.
Ich möchte genau darlegen, warum sich das von dem unterscheidet, was der Rest der Branche verkauft, denn das Feld ist überfüllt und das meiste davon ist ehrlich gut in dem Teil, den es löst.
IBMs watsonx Code Assistant for Z ist der ernsthafteste etablierte Anbieter — ein agentisches System mit Orchestrierungs-, Architektur- und Code-Agenten, das COBOL-zu-Java und sogar PL/I und IMS bewältigt und den CPU-Verbrauch bis hinunter in die Copybooks analysiert. Es ist zugleich eine Verpflichtung von über 2 Mio. USD, läuft auf z/OS und stützt sich auf IBMs ADDI-Tooling, das Sie klammheimlich an den Mainframe bindet — während der Migration, die Sie eigentlich davon befreien soll. Es macht keine Verhaltensäquivalenztests, und es kartiert Ihr JCL-Job-Netzwerk nicht.
Dann ist da der Moment, der den ganzen Markt umgestaltet hat. Im Februar 2026 veröffentlichte Anthropic ein COBOL-Modernisierungs-Playbook für Claude Code; IBMs Aktie fiel am Tag der Ankündigung um 13,2 %, und im März folgte ein Partnernetzwerk im Wert von 100 Mio. USD. Claude Code ist hervorragend bei Discovery, Dokumentation und dem Lesen unbekannten Codes — in den frühen Phasen wirklich nützlich. Aber es ist ein Allzweckwerkzeug. Es hat keinen eingebauten Knowledge Graph zum Auflösen transitiver Abhängigkeiten, und es gibt nicht vor, JCL-Scheduling, Verhaltensäquivalenz oder die Audit-Trails zu lösen, die eine regulierte Bank vorlegen muss.
Microsofts Azure-Migrationsfabrik zielt auf Java Quarkus ab und bindet Ihre Zielplattform an Azure. Die großen Systemintegratoren — DXC mit seiner patentierten Konvertierungs-Engine, TCS mit MasterCraft, Infosys mit Cobalt, Accenture — führen Projekte von 500.000 bis über 5 Mio. USD durch und implementieren Herstellerwerkzeuge, statt Wissen über Ihr System aufzubauen; Accenture leitete die Kernmigration der Commonwealth Bank of Australia, die rund 749,9 Mio. USD kostete und fünf Jahre dauerte. Und Micro Focus’ Visual COBOL, oft als Ausgangspunkt angepriesen, ist überhaupt keine Modernisierung — es ist Rehosting. Ihr COBOL bleibt COBOL, nur auf einer neuen Laufzeitumgebung. Die technischen Schulden und das Personalproblem sind genau dort, wo Sie sie hinterlassen haben.
Jedes dieser Angebote leistet etwas Reales. Was keines davon leistet, ist, die vollständige Abhängigkeitstopologie — JCL, CICS, DB2, Copybooks und alles — zuerst aufzubauen, unabhängig von jeder Zielplattform, und diese Karte als das Fundament zu behandeln, auf dem alles andere ruht.
Die meisten Anbieter verkaufen Ihnen einen besseren Übersetzer. Die Übersetzung war nie der Teil, der versagt hat.
Die Uhr, die niemand anhalten kann
Hier ist der Teil, der das Ganze von einem Engineering-Problem in einen Notfall verwandelt.
Die Menschen, die diese Systeme verstehen, gehen. Der durchschnittliche COBOL-Entwickler in den USA ist rund 55 Jahre alt. Etwa 10 % dieser Belegschaft gehen jedes Jahr in Rente, und 85 % der Universitäten strichen COBOL bereits in den 1990er-Jahren aus dem Lehrplan, sodass so gut wie niemand nachrückt. Sechzig Prozent der Organisationen sagen heute, dass die Suche nach qualifizierten COBOL-Entwicklern ihre größte einzelne Modernisierungsherausforderung ist — und 58 % der Entwickler, die diese Stacks noch beherrschen, sagen, sie erwägen deswegen zu kündigen.
Ich habe an der Version davon gestanden, die mich verfolgt: der Abschiedsfeier für die eine Person, die das Batch-Fenster tatsächlich verstand. Alle lächeln, es gibt Kuchen, und irgendwo in meinem Hinterkopf sagt eine Stimme: Dieses Wissen ist gerade zur Tür hinausgegangen, und es ist nirgends aufgeschrieben. Ein Knowledge Graph ist unter anderem eine Möglichkeit, das festzuhalten, was im Kopf dieser Person steckt, bevor die Feier beginnt — die Abhängigkeitskarte die Menschen überdauern zu lassen, die sie auswendig kannten.
Und die Einsätze sind nicht klein oder abstrakt. Rund 220 Milliarden Zeilen COBOL sind noch immer aktiv in Produktion. Es betreibt 95 % der Geldautomaten-Transaktionen und wickelt täglich rund 3 Billionen USD ab. Dreiundvierzig Prozent der Bankensysteme basieren darauf. Die technischen Schulden der USA werden auf geschätzte 1,52 Billionen USD beziffert, und das durchschnittliche Unternehmen verbrennt rund 370 Mio. USD pro Jahr für Legacy-Ineffizienz, wobei Finanzdienstleister 70 bis 75 % ihres IT-Budgets allein dafür ausgeben, die alten Systeme am Leben zu halten. Die Teams, die die Migration richtig hinbekommen, berichten von Renditen von 114 bis 225 % und rund 25 Mio. USD Einsparungen pro Jahr — aber dieser Vorteil existiert nur auf der anderen Seite einer Migration, die nicht gescheitert ist. Dies ist die seltene Modernisierung, bei der Nichtstun die teure Option ist.
Werden die neuen KI-Werkzeuge das nicht einfach lösen?
Das ist die Frage, die ich am häufigsten höre, und sie ist berechtigt, besonders nachdem die Anthropic-Ankündigung es so aussehen ließ, als wäre das Problem soeben für gelöst erklärt worden.
Meine ehrliche Antwort: Die neuen Werkzeuge haben die Discovery-Phase dramatisch beschleunigt, und das ist echter Fortschritt — ich nutze sie. Aber dass agentische KI immer besser im Lesen von COBOL wird, ändert nichts an dem, was Projekte tatsächlich tötet. Gartner erwartet, dass bis 2026 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten; mehr Agenten, die Code schneller übersetzen, helfen nicht, wenn sie alle blind für dieselbe JCL-Abhängigkeit sind. Geschwindigkeit beim falschen Problem ist nur ein schnellerer Weg, im UAT anzukommen und dort zu scheitern.
Die andere Frage, die mir gestellt wird, betrifft die Regulierung, und es ist die, die mittelgroße Banken unterschätzen. Der Digital Operational Resilience Act der EU — DORA — trat im Januar 2025 in Kraft und verlangt operative Resilienz und bedrohungsgeführte Penetrationstests, die zu bestehen Legacy-Systeme schlicht nie ausgelegt waren. US-Prüfer bei FFIEC und OCC behandeln alternde Infrastruktur als aktive Compliance-Lücke, und Systeme, die älter als zehn Jahre sind, tragen ein rund dreimal so hohes Risiko einer Sicherheitsverletzung. Eine Migration, die keinen Audit-Trail liefern kann, der beweist, dass sich das neue System identisch zum alten verhält, ist keine Modernisierung — sie ist eine neue Haftung mit besserer Syntax.
Deshalb sind Verhaltensäquivalenztests genauso wichtig wie die Karte. Die Technik ist leicht zu beschreiben und schwer gut umzusetzen: Erfassen Sie echte Ein- und Ausgaben aus dem Legacy-System — einen Golden-Datensatz — und spielen Sie sie gegen das neue System ab, bis das Verhalten übereinstimmt, Grenzfall für Grenzfall. Diese Grenzfälle, über Jahrzehnte angehäuft, kodieren oft regulatorische Logik, die nirgendwo sonst existiert — nicht in einer Spezifikation, nicht im Kopf eines Menschen, nur im laufenden Code. Ich habe erlebt, wie das einen Versicherer härter traf als eine Bank: die Tarifierungsregel, die nur bei einem Policennachtrag von 1998 greift, die Schadenrückstellungsberechnung, deren Rundung kein lebender Mensch erklären kann, von der aber jede Prüfung abhängt. Verlieren Sie sie stillschweigend, und Sie erfahren an dem Tag, an dem ein Regulierer fragt, welche davon wichtig waren.
Welchen Stein ziehen Sie zuerst heraus?
Sobald Sie die Karte haben, verrät sie Ihnen etwas, das kein Übersetzer kann: wo es sicher ist zu beginnen.
Die vorherrschende Strategie ist heute — aus gutem Grund — der Würgefeige-Ansatz: Statt eines Big-Bang-Rewrites extrahieren Sie eine Fähigkeit nach der anderen, betreiben Alt und Neu nebeneinander und behalten das Legacy-System als aktives Fallback, bis das neue Stück Vertrauen verdient hat. Aber jeder Anbieter, der den Würgefeige-Ansatz empfiehlt, lässt die schwierigste Frage aus — welches Modul würgen Sie zuerst? Wählen Sie ein eng gekoppeltes, und Sie haben das Big-Bang-Risiko mit zusätzlichen Schritten neu erschaffen.
Der Knowledge Graph beantwortet sie direkt. Er bringt die Module mit der geringsten Kopplung ans Licht — die mit den wenigsten eingehenden Abhängigkeiten —, sodass Sie ein echtes Stück des Systems extrahieren, den Ansatz beweisen und organisatorisches Vertrauen aufbauen können, bevor Sie den gefährlichen Kern anfassen. Die Karte ist nicht nur eine Versicherung gegen das TRN-LIMIT-Versagen. Sie ist der Sequenzierungsplan.
Wir haben all dies — den Abhängigkeits-Knowledge-Graph, die Würgefeige-Sequenzierung, das Verhaltensäquivalenz-Harness, bewusst unabhängig von jeder Zielplattform — in Veriprajnas Praxis für die Modernisierung von Legacy-COBOL eingebaut, ganz gezielt auf die mittelgroßen Banken und Versicherer ausgerichtet, die die etablierten Anbieter mit 2-Mio.-USD-Mindestpreis und die Systemintegratoren im siebenstelligen Bereich als zu klein abtun, um sich damit zu befassen.
Worüber ich ehrlich bin
Ich werde nicht so tun, als löse die Technologie alles, denn die teuersten Fehlschläge, die ich gesehen habe, waren überhaupt nicht technisch.
Kein Werkzeug — unseres eingeschlossen — behebt organisatorische Zustimmung, räumt Jahre schlechter Daten auf oder gewinnt den politischen Kampf, zweihundert Entwickler davon zu überzeugen, ihre Arbeitsweise zu ändern. Der Markt soll voraussichtlich von rund 9 Milliarden USD im Jahr 2026 bis zum Ende des Jahrzehnts auf das Doppelte wachsen, gerade weil so viel der Ausgaben in die menschliche und organisatorische Schicht fließt, nicht in den Compiler. Und kein Parser der Welt, ob Open Source oder kommerziell, deckt jedes Konstrukt in IBM Enterprise COBOL perfekt ab — die ALTER-Anweisungen aus der Zeit vor 1985, die tiefsten REDEFINES. Wer Ihnen etwas anderes erzählt, verkauft Ihnen die Lücke. Die Technologie ist notwendig. Sie war nie hinreichend.
Aber den Teil, den die Technologie kann übernehmen, muss sie vollständig übernehmen. Der Grund, warum Migrationen Millionen verbrennen und nichts liefern, ist selten, dass jemand schlechtes Java geschrieben hat. Es ist, dass sie ein System übersetzt haben, das sie nie wirklich kartiert hatten — Stränge eines Netzes konvertierend, während das Netz selbst unsichtbar blieb, bis zu der Nacht, in der es riss.
Zeichnen Sie zuerst die Karte. Ein System, das die Menschen überlebt hat, die es geschrieben haben, verzeiht keine übersehene Abhängigkeit, und es gibt keine Version dieser Arbeit, die sicher ist, bevor Sie sehen können, was womit verbunden ist. Wir haben das aus einem Hauptbuch gelernt, das von einem einzigen gepackten Dezimalfeld zunichtegemacht wurde, von dem niemand wusste, dass es da war. Finden Sie diese Felder, bevor sie Sie finden.
