AI-Powered COBOL-to-Java Migration: Promise, Pitfalls, and What It Means for Legacy Code

There are an estimated 800 billion lines of COBOL still running in production today — inside banks, insurance companies, government agencies, and pension systems. Most of the engineers who originally wrote that code are retired or gone. The organisations running it face a stark choice: maintain a shrinking talent pool of COBOL specialists, or migrate to a modern language and accept the enormous risk that comes with it.

AI-assisted migration looked like the clean escape hatch. Recent research has now complicated that picture in a very instructive way.

What the Research Actually Found

A study from researchers examining LLM-driven COBOL-to-Java translation found that large language models can, in fact, produce structurally coherent Java code from legacy COBOL programs. Syntax is largely preserved in spirit. Logic flows are reasonably reconstructed. On the surface, the output looks like something a competent junior developer might have written.

The uncomfortable finding: the models also migrated bugs. Latent defects embedded in decades-old COBOL — off-by-one errors, incorrect boundary handling, subtle arithmetic assumptions tied to COBOL's fixed-point decimal behaviour — were reproduced faithfully in the output Java. The AI did not reason about correctness. It translated form, not intent.

This is a critical distinction. A human engineer migrating legacy code is expected to read the original, understand its business purpose, identify known and suspected defects, and produce an idiomatic, corrected version. A language model, operating as a sophisticated pattern-completion engine, reconstructs what it sees — including the mistakes.

Why This Is Harder Than It Looks

COBOL was designed for a specific computational model. A few characteristics make translation genuinely difficult:

  • Fixed-point decimal arithmetic. COBOL's COMP-3 packed decimal format carries different rounding and overflow behaviour than Java's double or even BigDecimal by default. A direct translation can silently change financial calculations.
  • Implicit state and global data divisions. COBOL programs rely heavily on a WORKING-STORAGE SECTION that behaves like a global variable store. Mapping this cleanly to Java's object model requires architectural decisions, not just syntactic substitution.
  • Paragraph and PERFORM logic. COBOL control flow via PERFORM with fall-through paragraphs has no clean Java equivalent. AI models tend to flatten this into procedural Java, which may work but often produces unmaintainable code.
  • Undocumented business rules. The most dangerous logic in a 40-year-old COBOL program is not the code that is hard to read — it is the code that looks simple but encodes a regulatory or business rule that no one remembers. An AI has no way to flag these.

The Real Risk: False Confidence

The worst outcome of AI-assisted migration is not a noisy failure — it is a quiet one. A codebase that compiles, passes superficial tests, and deploys successfully, but contains the same latent defects as the original system, gives engineering teams a false sense of having solved the problem. In financial services or healthcare, those defects are regulatory time bombs.

This is compounded by the test coverage problem. Legacy COBOL systems typically have sparse or no automated test suites. If you cannot characterise what the original program should do with precision, you cannot verify that the migrated version does it correctly — with or without AI.

A Practical Framework for AI-Assisted Migration

None of this means AI has no role in legacy migration. It means the role must be understood precisely.

Where AI adds genuine value:

  • Generating a first-pass structural translation that engineers then review and refactor
  • Producing inline documentation and code comments from opaque COBOL logic
  • Identifying repeated patterns and extracting candidate utility functions
  • Accelerating the scaffolding of test cases based on inferred input/output behaviour

Where human oversight is non-negotiable:

  • Validating arithmetic operations, especially in financial calculation paths
  • Reviewing any logic that touches date handling, rounding, or currency conversion
  • Confirming that business rules embedded in conditionals match actual policy documents
  • Establishing a characterisation test suite before migration begins, using production-representative inputs

A useful mental model: treat the AI output as a draft from a fast contractor who has never worked in your domain. It gets you 60% of the way there quickly. The remaining 40% — correctness, idiomatic style, edge-case handling — requires your senior engineers.

A Note on Tooling

Some teams are experimenting with a two-pass approach:

// Pass 1: AI generates literal translation
// Pass 2: Static analysis flags divergences from Java best practices
// Pass 3: Domain engineers review flagged sections against original specs

MigrationPipeline pipeline = new MigrationPipeline()
    .withLLMTranslator(model)
    .withStaticAnalyser(analyser)
    .withReviewGate(domainEngineer);

This is not a magic bullet, but it structures the human review workload rather than asking engineers to audit every line of output from scratch.

What This Means for Your Project

If your organisation is sitting on legacy code — whether COBOL, FORTRAN, VB6, or even old PHP — the lesson from this research is not to distrust AI tooling. It is to design a migration process that treats AI output as an input to engineering, not a replacement for it. The teams that will succeed are those who use AI to compress the mechanical translation work, while investing the time saved into rigorous testing and domain validation. Speed and correctness are not opposites here — but achieving both requires deliberate process design, not blind automation.

Source: "AI migrated legacy COBOL programs to Java, bugs included" — arxiv.org/abs/2607.28271, via Hacker News.