Banks, insurers, public authorities and Mittelstand companies still run business-critical COBOL, PL/I, RPG and ABAP code that few people understand and that is costly to change. AI shifts modernisation from a manual, multi-year rewrite to an agent-assisted pipeline: reverse-engineer the business rules, translate to a modern language, generate tests and prove equivalence. Typical benefit is a reported cut of analysis and conversion effort; the hard part remains verification, not typing code.
Problem & value
- Today: legacy code holds decades of undocumented rules; experts retire, change is slow, hosting is costly. Classic options: rule-based transpilers (literal output), manual rewrites (slow, risky) or lift-and-shift emulation.
- AI value: (1) comprehension — explain programs in plain language and extract business rules; (2) translation — idiomatic target code rather than "JOBOL"; (3) test creation — characterisation tests from existing behaviour; (4) planning — dependency graphs and wave planning.
- Evidence (mixed quality, mostly vendor or self-reported):
- Google reports that in 39 LLM-assisted migrations, 74.45% of 595 code changes were LLM-generated and developers estimated about 50% less total migration time versus earlier manual efforts [4]. These were mostly mechanical refactorings, not language rewrites.
- IBM cites a customer case where analysing redundant COBOL fell from 8 hours to 30 minutes (vendor data) [3].
- Published numbers rarely cover full cut-over, data migration or regression effort.
Variants
- COBOL/PL/I/JCL → Java (banks, insurers, public sector): CICS, Db2, VSAM, batch. The classic case.
- SAP ABAP & S/4HANA custom-code clean-core migration (prominent EU/Mittelstand variant): SAP ERP 6.0 mainstream maintenance ends in 2027 (optional extended maintenance to 2030; check SAP Note 2881788 and current SAP statements) [5]. Custom Z-code must be analysed, simplified and moved to clean-core, upgrade-stable ABAP Cloud or side-by-side extensions. SAP's tooling: Joule for Developers in ABAP Development Tools / SAP Build Code (ABAP-tuned model; ABAP Program Explain, Documentation Chat on simplification items, Issue Explain for ATC findings), the ABAP Test Cockpit (ATC) with S/4HANA readiness checks, and the Custom Code Migration Fiori app with an AI assistant [2]. Workflow: decommission unused code, run ATC, AI explains and proposes fixes per finding, review, test. This is a big Mittelstand topic (SAP is an EU vendor; EU integrators include adesso, Capgemini, Sopra Steria, msg). ABAP coding assistance is also tagged in CODE-001.
- RPG/AS400 (IBM i), Natural/Adabas, PowerBuilder, Delphi, VB6, Oracle Forms → modern stacks: same pipeline, fewer ready-made tools; general LLM agents plus parsers.
- Version migrations (Java 8→21, .NET Framework→.NET, Python 2→3): see CODE-021.
How it works
- inventory & scoping (repos, mainframe libraries, usage telemetry, dead code)
- static analysis / parsing (AST, call + data-flow graph, copybook & schema resolution)
- AI comprehension (per-program summaries, business-rule extraction, glossary) [knowledge graph + RAG]
- target design (architecture, domain boundaries, strangler-fig slices) [human architect]
- AI-assisted translation or agent rewrite per slice (code + config + DB mapping)
- test generation (characterisation tests, golden-master data from production)
- equivalence testing (run old vs new on the same inputs, diff outputs incl. rounding, dates, encodings)
- review by domain expert + CI/CD + parallel run
- cut-over
- Key components: deterministic parsers and graphs ground the LLM (large programs exceed context windows); a code-capable reasoning LLM explains and translates; an agent loop compiles, tests and repairs.
- Human-in-the-loop: domain experts sign off on extracted business rules; architects approve target design; developers review every merged change; business owners approve parallel-run results and cut-over. Never accept "compiles" as proof of equivalence.
Data preparation
The "data" is mostly code and its context: source repositories or mainframe libraries, copybooks, database schemas, JCL, screen maps, tickets and runtime traces. In an SMB these live in old SVN/TFS repos, file shares, a developer's laptop or only as binaries; documentation is often missing or outdated, and knowledge sits in the heads of a few long-serving developers.
Typical gaps: unversioned or missing source, dead code, duplicated copies, inconsistent encodings (EBCDIC, code pages), absent tests, and production data that may contain personal data.
Preparation steps: - Inventory repos and programs, and use runtime telemetry to find dead code (PREP-001, PREP-005). - Move code into Git and fix encodings; extract schemas and copybooks. - Capture golden-master test data from production, masked or synthetic (PREP-022). - Record business rules and interview the remaining experts; collect a glossary (PREP-012, PREP-015). - Build evaluation sets with domain experts for equivalence testing (PREP-018). - Tools: tree-sitter/ANTLR parsers, Git, SonarQube, CAST-style analysis.
Rough share of effort: about 40-50 percent of the project goes into inventory, test data and rule capture; translation itself is the smaller part. See also GUIDE-003.
Implementation paths
Which path for whom
- SMB: B. Integrators and mainframe suites target large estates; a bounded estate (VB6, Delphi, old Java/.NET) fits own agent pipelines on EU-region APIs.
- Enterprise: B. Core systems with sensitive code and domain-specific parsers favour an own pipeline on EU APIs; buy (A) only for mainframe/SAP estates that need a vendor warranty.
- Developer: C. Open-weight code models and agents keep the code in-house at acceptable cost for repeated runs.
- Public sector: C. Sovereignty, procurement rules and sensitive citizen-data systems favour self-hosting or a sovereign German/EU cloud.
Path A — Buy (off-the-shelf)
- Mainframe: AWS Transform for mainframe (agentic analysis, documentation, decomposition, COBOL→Java refactor with Blu Age tooling, test-plan generation; inputs include z/OS COBOL, JCL, CICS, BMS, Db2, VSAM) [1]; IBM watsonx Code Assistant for Z (discovery, explanation, COBOL→Java, on-prem option) [3]; Micro Focus/OpenText, Rocket Software, mLogica, CAST (FR, code intelligence), Heirloom and others.
- SAP: Joule for Developers, ATC, Custom Code Migration app (included in SAP tooling; Joule requires accepting SAP AI Terms) [2]; EU partners with accelerators.
- System integrators (many EU): Capgemini, Sopra Steria, adesso, msg, Tietoevry, Eviden, Thoughtworks. Check EU data residency and whether code leaves your perimeter.
- Choose A when: mainframe/SAP estates, regulated customers, need for warranty.
Path B — Build on cloud APIs
- Frontier code models via EU regions or EU providers (Mistral Codestral/Devstral, Claude, GPT, Gemini on Azure/Vertex/Bedrock EU regions); agent frameworks (LangGraph, OpenHands, Claude Code/agent SDKs, Copilot coding agent, AWS Transform agents) with your own parsers (tree-sitter, ANTLR COBOL grammars, ProLeap) and CI.
- Good for mid-sized, non-mainframe estates (VB6, Delphi, old Java). Strip secrets and customer data before sending code.
Path C — Self-host (open source)
- Open-weight code models (Qwen3-Coder, DeepSeek-V3/R1-class, Devstral, GLM, gpt-oss, Codestral open variants where licensing permits) via vLLM/SGLang/Ollama; agents such as OpenHands, Aider, Cline/Continue; Sourcegraph/Zoekt or graph databases for code search; GnuCOBOL for running and testing COBOL off-mainframe.
- Hardware: HW3 for ~30–120B coding models for comprehension; HW4 for the largest open models and parallel agents. Ops effort is substantial. Justified for secrecy-critical code or very large estates.
Path D — Custom training
Fine-tune only for rare languages (RPG, Natural, proprietary 4GLs, in-house DSLs) with paired legacy/modern code (thousands of verified translation pairs from earlier project waves) or to cut inference cost. Verified pairs from your own pipeline are the best training data; IBM trained its COBOL→Java model on a Granite base [3].
State of the art (2026)
- Agentic pipelines that analyse, decompose, convert, generate tests and iterate against a build are now offered by hyperscalers and IBM/SAP; AWS positions its service as agentic modernisation at scale [1]. Google's published work shows LLM migrations work best with narrow, verifiable changes and automated validation [4].
- Limits and failure modes: silent semantic drift (packed-decimal/COMP-3 arithmetic, rounding, date and EBCDIC/encoding handling, copybook REDEFINES, GOTO-heavy flow, implicit state in CICS/IMS and batch job chains); literal translation producing unmaintainable Java; hallucinated business rules; context-window limits on 100k-line programs; missing tests and test data; non-code assets (JCL, scheduler, security config, data migration) often dominate effort. Public benchmarks for repository-level translation are still immature, so run your own pilot.
Shared resources & combinations
- Same stack (llm-code + agent-framework): CODE-001, CODE-002 coding agents, CODE-003 review of translated output, CODE-021.
- Combine with: CODE-004 (test generation = equivalence oracle), CODE-006 (documentation and architecture recovery), CODE-012 (API wrapping and connectors during phased migration), CODE-020 (safety-critical constraints), SEC-004 (scan translated code for vulnerabilities).
Effort, cost & KPIs
- Path A: 1–3 months for assessment/pilot; programme duration typically many months to years, priced per line of code or per application by vendors/integrators.
- Path B: 2–6 months for a bounded estate; cost drivers are tokens on long files, test data and expert review. Path C: 3–9 months; pays off only at scale.
- KPIs: share of code auto-converted and compiling; behavioural equivalence rate on golden-master tests; defects found in parallel run; review minutes per 1,000 lines; mainframe licence cost avoided; share of dead code decommissioned.
People & change
Involve management (budget, risk appetite) and the IT/department lead before scoping; data owners and the few remaining legacy experts early, because their knowledge is the scarcest resource. IT security and legal/compliance review code transfer to vendors or APIs, contracts and exit options (GUIDE-010, GUIDE-013). Developers and business owners as end-users take part in the pilot and in review of every converted slice.
Works council: depends. The tool is a developer productivity system, but telemetry in IDEs or agent platforms can allow performance monitoring, and the objective suitability suffices for co-determination under §87(1) no. 6 BetrVG. §90(1) no. 3 requires timely information when AI changes work processes, and §80(3) allows an expert. Staff councils apply in the public sector.
Data protection: source code rarely holds personal data, but test data and logs do; involve the DPO, use an AVV (Art. 28 GDPR), and run a DPIA only if production data is used at scale (GUIDE-005).
AI literacy: support developers with training on reviewing AI output (GUIDE-006). Typical concern: fear of job loss among legacy specialists; address by positioning them as rule validators and reviewers. Pilot with one bounded module (GUIDE-009); humans sign off every merge and the cut-over. See also GUIDE-008.
Risks, regulation & compliance
- EU AI Act: the tool is a developer productivity system — minimal risk; AI literacy duty (Art. 4) applies. If the migrated application itself is high-risk (e.g. credit scoring, Annex III) or a safety component, the system still must meet its obligations after migration; document changes. No Art. 5 prohibited practice involved [6].
- GDPR: source code seldom contains personal data, but test data, production extracts, logs and hard-coded records do. Use masked or synthetic data, EU processing, a DPA and no-training terms with API vendors; keep production extracts out of prompts.
- Financial and public sector: DORA (ICT risk, third-party register, exit strategies) for banks and insurers; EBA outsourcing rules; BSI C5 for public cloud use.
- Operational risk: cut-over failures, lock-in to proprietary runtimes. Mitigations: parallel runs, strangler slices, reversible cut-over, human sign-off, AI-assisted output treated as untrusted until tested, audit log of AI-generated changes.
Getting started
- Inventory and triage: usage telemetry and dead-code detection first; decommissioning is the cheapest modernisation. For SAP, run ATC readiness checks on custom code.
- Start with comprehension: have AI document 10–20 representative programs, and let domain experts rate accuracy.
- Build the safety net: collect golden-master inputs/outputs from production-like data (masked) before translating anything.
- Pilot one bounded slice (e.g. a batch job or one module) with 2–3 tools from Path A or a Path B agent; measure equivalence rate and review effort against a manual baseline.
- Scale slice by slice with CI, parallel run and clear exit criteria.
Sources
- AWS — AWS Transform for mainframe — https://aws.amazon.com/transform/mainframe
- SAP — Joule for developers — https://www.sap.com/products/artificial-intelligence/joule-for-developers.html
- IBM — watsonx Code Assistant for Z — https://www.ibm.com/products/watsonx-code-assistant-z/pricing
- Google — Migrating Code At Scale With LLMs At Google (arXiv 2504.09691) — https://arxiv.org/abs/2504.09691
- 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/
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- 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