Modernisierung von Legacy-Code und Sprachmigration (z. B. COBOL → Java)

Banken, Versicherungen, Behörden und Mittelstandsunternehmen betreiben nach wie vor geschäftskritischen COBOL-, PL/I-, RPG- und ABAP-Code, den nur wenige Menschen verstehen und dessen Änderung teuer ist. KI macht aus der Modernisierung eine agentengestützte Pipeline statt einer manuellen, mehrjährigen Neuentwicklung: Geschäftsregeln rückwärts ermitteln, in eine moderne Sprache übersetzen, Tests erzeugen und die Gleichwertigkeit nachweisen. Berichtet wird typischerweise eine Verringerung des Analyse- und Umstellungsaufwands; schwierig bleibt die Verifikation, nicht das Schreiben von Code.

Problem & Nutzen

• Heute: Legacy-Code enthält Regeln aus Jahrzehnten, die nicht dokumentiert sind; Experten gehen in Rente, Änderungen sind langsam, der Betrieb ist teuer. Klassische Optionen: regelbasierte Transpiler (wörtliche Ausgabe), manuelle Neuentwicklung (langsam, riskant) oder Lift-and-Shift-Emulation.
• Nutzen durch KI: (1) Verständnis — Programme in verständlicher Sprache erklären und Geschäftsregeln extrahieren; (2) Übersetzung — idiomatischer Zielcode statt „JOBOL"; (3) Testerstellung — Characterisation-Tests aus dem vorhandenen Verhalten; (4) Planung — Abhängigkeitsgraphen und Wellenplanung.
• Belege (gemischte Qualität, meist Herstellerangaben oder Selbstauskünfte):
• Google berichtet, dass bei 39 LLM-gestützten Migrationen 74,45 % von 595 Codeänderungen vom LLM erzeugt wurden und Entwickler die gesamte Migrationszeit gegenüber früheren manuellen Projekten auf etwa 50 % weniger schätzten [4]. Es handelte sich überwiegend um mechanische Refactorings, nicht um Sprachumstellungen.
• IBM nennt einen Kundenfall, in dem die Analyse redundanten COBOL-Codes von 8 Stunden auf 30 Minuten sank (Herstellerdaten) [3].
• Veröffentlichte Zahlen decken selten die vollständige Umschaltung, die Datenmigration oder den Regressionsaufwand ab.

Varianten

• COBOL/PL/I/JCL → Java (Banken, Versicherungen, öffentlicher Sektor): CICS, Db2, VSAM, Batch. Der klassische Fall.
• SAP ABAP und Clean-Core-Migration von kundeneigenem Code für S/4HANA (prominente EU-/Mittelstandsvariante): Die reguläre Wartung (Mainstream Maintenance) von SAP ERP 6.0 endet 2027 (optionale erweiterte Wartung bis 2030; SAP-Hinweis 2881788 und aktuelle SAP-Aussagen prüfen) [5]. Kundeneigener Z-Code muss analysiert, vereinfacht und in Clean-Core-fähiges, upgradestabiles ABAP Cloud oder in Side-by-Side-Erweiterungen überführt werden. Werkzeuge von SAP: Joule for Developers in den ABAP Development Tools / SAP Build Code (auf ABAP abgestimmtes Modell; ABAP Program Explain, Documentation Chat zu Vereinfachungspunkten, Issue Explain für ATC-Befunde), der ABAP Test Cockpit (ATC) mit S/4HANA-Readiness-Prüfungen und die Fiori-App Custom Code Migration mit KI-Assistent [2]. Ablauf: ungenutzten Code stilllegen, ATC ausführen, KI erklärt und schlägt je Befund Korrekturen vor, Prüfung, Test. Dies ist ein großes Thema für den Mittelstand (SAP ist ein EU-Anbieter; EU-Integratoren sind unter anderem adesso, Capgemini, Sopra Steria, msg). ABAP-Programmierassistenz ist auch in CODE-001 verschlagwortet.
• RPG/AS400 (IBM i), Natural/Adabas, PowerBuilder, Delphi, VB6, Oracle Forms → moderne Stacks: gleiche Pipeline, weniger fertige Werkzeuge; allgemeine LLM-Agenten plus Parser.
• Versionsmigrationen (Java 8→21, .NET Framework→.NET, Python 2→3): siehe CODE-021.

So funktioniert es

1. inventory & scoping (repos, mainframe libraries, usage telemetry, dead code)
2. static analysis / parsing (AST, call + data-flow graph, copybook & schema resolution)
3. AI comprehension (per-program summaries, business-rule extraction, glossary) [knowledge graph + RAG]
4. target design (architecture, domain boundaries, strangler-fig slices) [human architect]
5. AI-assisted translation or agent rewrite per slice (code + config + DB mapping)
6. test generation (characterisation tests, golden-master data from production)
7. equivalence testing (run old vs new on the same inputs, diff outputs incl. rounding, dates, encodings)
8. review by domain expert + CI/CD + parallel run
9. cut-over

• Zentrale Komponenten: Deterministische Parser und Graphen erden das LLM (große Programme sprengen das Kontextfenster); ein codefähiges Reasoning-LLM erklärt und übersetzt; eine Agentenschleife kompiliert, testet und repariert.
• Mensch-in-der-Schleife (Human-in-the-Loop): Fachexperten zeichnen die extrahierten Geschäftsregeln ab; Architekten genehmigen das Zieldesign; Entwickler prüfen jede übernommene Änderung; Fachverantwortliche genehmigen die Ergebnisse des Parallelbetriebs und die Umschaltung. „Kompiliert" niemals als Beweis für Gleichwertigkeit akzeptieren.

Datenaufbereitung

Die „Daten" sind überwiegend Code und sein Umfeld: Quellcode-Repositories oder Mainframe-Bibliotheken, Copybooks, Datenbankschemata, JCL, Bildschirmmasken, Tickets und Laufzeit-Traces. In einem KMU liegen diese in alten SVN-/TFS-Repositories, auf Dateiservern, auf dem Laptop eines Entwicklers oder nur als Binärdateien; Dokumentation fehlt oder ist veraltet, und das Wissen steckt in den Köpfen weniger langjähriger Entwickler.

Typische Lücken: nicht versionierter oder fehlender Quellcode, toter Code, doppelte Kopien, uneinheitliche Zeichenkodierungen (EBCDIC, Codepages), fehlende Tests sowie Produktivdaten, die personenbezogene Daten enthalten können.

Schritte der Aufbereitung: - Repositories und Programme inventarisieren und mit Laufzeittelemetrie toten Code finden (PREP-001, PREP-005). - Code in Git überführen und Kodierungen korrigieren; Schemata und Copybooks extrahieren. - Golden-Master-Testdaten aus der Produktion erfassen, maskiert oder synthetisch (PREP-022). - Geschäftsregeln festhalten und die verbliebenen Experten befragen; ein Glossar anlegen (PREP-012, PREP-015). - Mit Fachexperten Auswertungsdatensätze für den Äquivalenztest aufbauen (PREP-018). - Werkzeuge: Parser auf Basis von tree-sitter/ANTLR, Git, SonarQube, Analysen im Stil von CAST.

Grober Aufwandsanteil: Etwa 40–50 Prozent des Projekts entfallen auf Inventur, Testdaten und Regelerfassung; die Übersetzung selbst ist der kleinere Teil. Siehe auch GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: B. Integratoren und Mainframe-Suiten zielen auf große Bestände; ein überschaubarer Bestand (VB6, Delphi, alte Java-/.NET-Versionen) passt zu eigenen Agenten-Pipelines auf APIs in EU-Regionen.
• Großunternehmen: B. Kernsysteme mit sensiblem Code und fachspezifischen Parsern sprechen für eine eigene Pipeline auf EU-APIs; Kaufen (A) nur bei Mainframe-/SAP-Beständen, die eine Herstellergewährleistung benötigen.
• Entwickler: C. Open-Weight-Codemodelle und Agenten halten den Code im Haus, bei vertretbaren Kosten für wiederholte Läufe.
• Öffentlicher Sektor: C. Souveränität, Vergaberegeln und sensible Bürgerdatensysteme sprechen für den Selbstbetrieb oder eine souveräne deutsche/EU-Cloud.

Weg A — Kaufen (Standardsoftware)

• Mainframe: AWS Transform for mainframe (agentische Analyse, Dokumentation, Zerlegung, COBOL→Java-Refactoring mit Blu-Age-Werkzeugen, Erzeugung von Testplänen; Eingaben sind unter anderem z/OS COBOL, JCL, CICS, BMS, Db2, VSAM) [1]; IBM watsonx Code Assistant for Z (Erkennung, Erklärung, COBOL→Java, On-Premises-Option) [3]; Micro Focus/OpenText, Rocket Software, mLogica, CAST (FR, Code Intelligence), Heirloom und andere.
• SAP: Joule for Developers, ATC, App Custom Code Migration (in den SAP-Werkzeugen enthalten; für Joule müssen die SAP-KI-Bedingungen akzeptiert werden) [2]; EU-Partner mit Beschleunigern.
• Systemintegratoren (viele aus der EU): Capgemini, Sopra Steria, adesso, msg, Tietoevry, Eviden, Thoughtworks. EU-Datenresidenz prüfen und klären, ob der Code Ihren Verantwortungsbereich verlässt.
• A wählen, wenn: Mainframe-/SAP-Bestände, regulierte Kunden, Bedarf an Gewährleistung.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Spitzen-Codemodelle über EU-Regionen oder EU-Anbieter (Mistral Codestral/Devstral, Claude, GPT, Gemini in den EU-Regionen von Azure/Vertex/Bedrock); Agenten-Frameworks (LangGraph, OpenHands, Claude Code/Agent-SDKs, Copilot Coding Agent, AWS-Transform-Agenten) mit eigenen Parsern (tree-sitter, ANTLR-COBOL-Grammatiken, ProLeap) und CI.
• Gut für mittelgroße Nicht-Mainframe-Bestände (VB6, Delphi, alte Java-Versionen). Vor dem Senden des Codes Geheimnisse und Kundendaten entfernen.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Codemodelle (Qwen3-Coder, DeepSeek-V3/R1-Klasse, Devstral, GLM, gpt-oss, offene Codestral-Varianten, soweit die Lizenz es erlaubt) über vLLM/SGLang/Ollama; Agenten wie OpenHands, Aider, Cline/Continue; Sourcegraph/Zoekt oder Graphdatenbanken für die Codesuche; GnuCOBOL zum Ausführen und Testen von COBOL außerhalb des Mainframes.
• Hardware: HW3 für Codiermodelle mit ca. 30–120 Mrd. Parametern zum Verständnis; HW4 für die größten offenen Modelle und parallele Agenten. Der Betriebsaufwand ist erheblich. Gerechtfertigt bei geheimhaltungskritischem Code oder sehr großen Beständen.

Weg D — Eigenes Training

Feintuning nur für seltene Sprachen (RPG, Natural, proprietäre 4GLs, hauseigene DSLs) mit gepaartem Legacy-/modernem Code (Tausende verifizierte Übersetzungspaare aus früheren Projektwellen) oder um die Inferenzkosten zu senken. Verifizierte Paare aus der eigenen Pipeline sind die besten Trainingsdaten; IBM hat sein COBOL→Java-Modell auf einer Granite-Basis trainiert [3].

Stand der Technik (2026)

• Agentische Pipelines, die analysieren, zerlegen, konvertieren, Tests erzeugen und gegen einen Build iterieren, werden inzwischen von Hyperscalern sowie von IBM und SAP angeboten; AWS positioniert seinen Dienst als agentische Modernisierung im großen Maßstab [1]. Googles veröffentlichte Arbeit zeigt, dass LLM-Migrationen bei eng gefassten, überprüfbaren Änderungen und automatisierter Validierung am besten funktionieren [4].
• Grenzen und Fehlerbilder: unbemerkte semantische Abweichungen (Packed-Decimal-/COMP-3-Arithmetik, Rundung, Datums- und EBCDIC-/Kodierungsbehandlung, Copybook-REDEFINES, GOTO-lastiger Ablauf, impliziter Zustand in CICS/IMS und Batch-Job-Ketten); wörtliche Übersetzung, die nicht wartbares Java erzeugt; halluzinierte Geschäftsregeln; Kontextfenstergrenzen bei Programmen mit 100.000 Zeilen; fehlende Tests und Testdaten; Nicht-Code-Bestandteile (JCL, Scheduler, Sicherheitskonfiguration, Datenmigration) bestimmen oft den Aufwand. Öffentliche Benchmarks für die Übersetzung ganzer Repositories sind noch unausgereift, führen Sie daher einen eigenen Piloten durch.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework): CODE-001, CODE-002 Coding-Agenten, CODE-003 Review der übersetzten Ausgabe, CODE-021.
• Kombinieren mit: CODE-004 (Testgenerierung = Äquivalenz-Orakel), CODE-006 (Dokumentation und Rückgewinnung der Architektur), CODE-012 (API-Kapselung und Konnektoren während der schrittweisen Migration), CODE-020 (Randbedingungen sicherheitskritischer Systeme), SEC-004 (übersetzten Code auf Schwachstellen prüfen).

Aufwand, Kosten & Kennzahlen

• Weg A: 1–3 Monate für Bewertung/Pilot; die Programmdauer beträgt typischerweise viele Monate bis Jahre, die Abrechnung erfolgt durch Hersteller/Integratoren pro Codezeile oder pro Anwendung.
• Weg B: 2–6 Monate für einen überschaubaren Bestand; Kostentreiber sind Token bei langen Dateien, Testdaten und Expertenprüfung. Weg C: 3–9 Monate; lohnt sich nur im großen Maßstab.
• Kennzahlen: Anteil des automatisch umgestellten und kompilierenden Codes; Rate der Verhaltensgleichheit bei Golden-Master-Tests; im Parallelbetrieb gefundene Fehler; Prüfminuten je 1.000 Zeilen; eingesparte Mainframe-Lizenzkosten; Anteil des stillgelegten toten Codes.

Menschen & Veränderung

Beziehen Sie vor der Abgrenzung die Geschäftsleitung (Budget, Risikobereitschaft) sowie die IT- bzw. Abteilungsleitung ein; Datenverantwortliche und die wenigen verbliebenen Legacy-Experten frühzeitig, denn ihr Wissen ist die knappste Ressource. IT-Sicherheit und Recht/Compliance prüfen die Übergabe des Codes an Anbieter oder APIs, Verträge und Ausstiegsoptionen (GUIDE-010, GUIDE-013). Entwickler und Fachverantwortliche als Endnutzer nehmen am Pilot und an der Prüfung jedes umgestellten Teilstücks teil.

Betriebsrat: abhängig. Das Werkzeug ist ein System zur Produktivitätssteigerung von Entwicklern, doch Telemetrie in IDEs oder Agentenplattformen kann eine Leistungsüberwachung ermöglichen, und die objektive Eignung genügt für die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG. § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung, wenn KI Arbeitsabläufe verändert, und § 80 Abs. 3 erlaubt die Hinzuziehung eines Sachverständigen. Im öffentlichen Dienst gelten die Personalräte.

Datenschutz: Quellcode enthält selten personenbezogene Daten, Testdaten und Logs dagegen schon; beziehen Sie die/den Datenschutzbeauftragte(n) ein, schließen Sie einen AVV (Art. 28 DSGVO) und führen Sie eine DSFA nur durch, wenn Produktivdaten in großem Umfang verwendet werden (GUIDE-005).

KI-Kompetenz: Unterstützen Sie Entwickler mit Schulungen zur Prüfung von KI-Ergebnissen (GUIDE-006). Typische Sorge: Angst vor Arbeitsplatzverlust bei Legacy-Spezialisten; begegnen Sie ihr, indem Sie diese als Regelprüfer und Reviewer positionieren. Pilotieren Sie mit einem abgegrenzten Modul (GUIDE-009); Menschen zeichnen jede Übernahme und die Umschaltung ab. Siehe auch GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das Werkzeug ist ein System zur Produktivitätssteigerung von Entwicklern — minimales Risiko; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Ist die migrierte Anwendung selbst hochriskant (z. B. Kreditscoring, Anhang III) oder eine Sicherheitskomponente, muss das System seine Pflichten auch nach der Migration erfüllen; dokumentieren Sie Änderungen. Keine verbotene Praxis nach Art. 5 betroffen [6].
• DSGVO: Quellcode enthält selten personenbezogene Daten, Testdaten, Produktivauszüge, Logs und fest codierte Datensätze dagegen schon. Verwenden Sie maskierte oder synthetische Daten, eine Verarbeitung in der EU, einen AVV und Bedingungen ohne Training mit Ihren Daten bei API-Anbietern; halten Sie Produktivauszüge aus Prompts heraus.
• Finanz- und öffentlicher Sektor: DORA (IKT-Risiko, Register der Drittanbieter, Ausstiegsstrategien) für Banken und Versicherer; EBA-Auslagerungsregeln; BSI C5 für die Nutzung öffentlicher Clouds.
• Betriebsrisiko: Fehlschläge bei der Umschaltung, Lock-in in proprietäre Laufzeitumgebungen. Gegenmaßnahmen: Parallelbetrieb, Strangler-Teilstücke, umkehrbare Umschaltung, menschliche Freigabe, KI-gestützte Ergebnisse bis zum erfolgreichen Test als nicht vertrauenswürdig behandeln, Audit-Log der KI-erzeugten Änderungen.

Erste Schritte

1. Inventur und Triage: zuerst Nutzungstelemetrie und Erkennung toten Codes; Stilllegen ist die günstigste Modernisierung. Für SAP ATC-Readiness-Prüfungen auf dem kundeneigenen Code ausführen.
2. Mit dem Verständnis beginnen: KI 10–20 repräsentative Programme dokumentieren lassen und die Fachexperten die Genauigkeit bewerten lassen.
3. Das Sicherheitsnetz aufbauen: Golden-Master-Ein- und Ausgaben aus produktionsnahen (maskierten) Daten sammeln, bevor etwas übersetzt wird.
4. Ein abgegrenztes Teilstück (z. B. einen Batch-Job oder ein Modul) mit 2–3 Werkzeugen aus Weg A oder einem Agenten aus Weg B pilotieren; Äquivalenzrate und Prüfaufwand gegen eine manuelle Basislinie messen.
5. Teilstück für Teilstück mit CI, Parallelbetrieb und klaren Ausstiegskriterien skalieren.

Quellen

1. AWS — AWS Transform for mainframe — https://aws.amazon.com/transform/mainframe
2. SAP — Joule for developers — https://www.sap.com/products/artificial-intelligence/joule-for-developers.html
3. IBM — watsonx Code Assistant for Z — https://www.ibm.com/products/watsonx-code-assistant-z/pricing
4. Google — Migrating Code At Scale With LLMs At Google (arXiv 2504.09691) — https://arxiv.org/abs/2504.09691
5. SAPinsider — SAP Announces Extension of Mainstream Maintenance for SAP ERP 6.0 — https://sapinsider.org/blogs/sap-announces-extension-of-mainstream-maintenance-for-sap-erp-6-0/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. AWS Prescriptive Guidance — Modernize and deploy mainframe applications using AWS Transform and Terraform — https://docs.aws.eu/prescriptive-guidance/latest/patterns/modernize-mainframe-app-transform-terraform.html