HN Debrief

AI migrated legacy COBOL programs to Java, bugs included

  • AI
  • Programming
  • Infrastructure
  • Developer Tools
  • Enterprise Software

The paper reports an AI-assisted COBOL-to-Java migration flow that aims for behavioral equivalence rather than cleanup. That means preserving quirks and outright bugs on purpose, because in old enterprise systems those behaviors are often depended on. People were less interested in the headline result than in the paper’s narrow scope. The largest example was only a few thousand lines, and the setup mostly covered code that could already be isolated from the uglier parts of a real mainframe stack.

Treat AI migration as a tooling aid for extracting specs, tests, and narrow translations, not as proof that wholesale COBOL replacement is suddenly easy. If you own a legacy estate, the bottleneck is still hidden behavior and platform coupling, so invest first in test data, parallel runs, and scoping what can actually be detached from the mainframe.

Discussion mood

Skeptical. Most comments treated the paper as an interesting demo with very limited bearing on real COBOL estates, mainly because enterprise behavior lives in undocumented rules, mainframe services, and exact numeric semantics that simple source translation does not capture.

Key insights

  1. 01

    Undocumented behavior is the real spec

    What keeps these systems alive is not COBOL syntax. It is years of edge-case business behavior that other systems have quietly learned to rely on. Hyrum’s Law fits perfectly here. A bug in source code may also be a contract for downstream reports, reconciliation jobs, or customer workflows. That shifts the migration target from “correct code” to “production-compatible behavior,” which is much harder to discover than to translate.

    Inventory downstream consumers before touching core logic. Your test plan needs to validate observed behavior across interfaces and reports, not just function-level correctness.

      Attribution:
    • acdha #1
    • nicman23 #1
    • wwind123 #1
    • Maxion #1
  2. 02

    Exact decimal math can break a port

    COBOL’s numeric behavior is one of the places where a migration quietly dies. Financial code often depends on fixed decimal arithmetic with precise rounding rules. Plain Java numeric types are not enough, and even BigDecimal may not match COBOL semantics closely enough. That is why IBM ships dedicated decimal arithmetic libraries just to reproduce legacy behavior. If your translated code does not preserve these rules, you have not done a safe migration no matter how clean the Java looks.

    Force a numeric-semantics review early. Build golden test cases around money, rounding, overflow, and field formatting before you approve any language conversion approach.

      Attribution:
    • Zenst #1
    • edflsafoiewq #1
    • Yopolo #1
  3. 03

    The platform is bigger than the language

    Real COBOL applications are usually entangled with mainframe services like CICS, IMS, VSAM, batch schedulers, sort utilities, and job control. Those were mostly mocked away in the paper’s setup, which is exactly where many production migrations become painful. Translating the business logic is the easy slice. Recreating transaction semantics, data access patterns, and operational behavior off-mainframe is where cost and risk explode.

    Map external dependencies before you estimate migration effort. Separate pure computation from platform services so you can tell what is portable and what needs adapters, emulation, or redesign.

      Attribution:
    • Surac #1
    • TimByte #1
    • p_l #1
    • kukkeliskuu #1
  4. 04

    COBOL control flow defeats naive translation

    Legacy COBOL can have execution paths that are hard to infer statically because of global state, paragraph-based flow, PERFORM THRU ranges, and old-school GOTO usage. A commenter gave a small example where an AI-produced Java loop changed behavior immediately on entry conditions. That is a useful warning sign. Even toy control-flow mistakes can alter observable outcomes, and real programs layer these constructs deeply.

    Use differential testing against the original program on real inputs. Do not trust structurally plausible translations of control flow without runtime equivalence checks.

      Attribution:
    • prirun #1
  5. 05

    Test data is the migration bottleneck

    The strongest pro-migration comments all collapsed to the same requirement. If you already have rich test data and a decent grasp of the system, modern AI tools can speed up rewrites or spec extraction. Without that, you are just moving an opaque black box into a new syntax. The scarce asset is not code generation. It is a representative corpus of inputs and outputs that can stand in for the missing spec.

    Fund test-data capture like a core migration workstream. Record production cases, edge cases, and historical exceptions before you ask any tool or team to port behavior.

      Attribution:
    • ASalazarMX #1
    • codetiger #1
    • Yopolo #1

Against the grain

  1. 01

    AI can still help people understand COBOL

    The bleakest view was that a translated system just replaces one opaque codebase with another. A more pragmatic take is that AI does not need to recover perfect intent to be useful. Even if it cannot explain the original “why,” it can often summarize the “what” and “how” well enough to help engineers navigate a codebase that nobody fully understands today. That makes AI valuable as an analysis layer even if the migration itself is risky.

    Try AI first on comprehension tasks like walkthroughs, dependency mapping, and test generation. You may get most of the operational benefit without committing to a full rewrite.

      Attribution:
    • someone654 #1
    • free_bip #1
  2. 02

    The migration premise may be wrong

    Several commenters rejected the idea that COBOL itself is the problem. They argued the real failure is organizational. Companies underpay for critical maintenance, let expertise retire, then declare the language obsolete. If LLMs can assist with legacy languages too, translating everything into Java may just trade one staffing story for a riskier system with weaker domain continuity.

    Re-run the business case against a serious “keep COBOL, improve tooling, pay experts” option. A modernization budget may deliver better returns on integration, documentation, and staffing than on language replacement.

      Attribution:
    • gt0 #1
    • kome #1
    • Leonard_of_Q #1
    • mtct88 #1

In plain english

BigDecimal ↩
A Java type for exact decimal arithmetic, often used in financial software to avoid floating-point rounding errors.
CICS ↩
Customer Information Control System, an IBM transaction-processing system used on mainframes to run high-volume business applications.
COBOL ↩
Common Business-Oriented Language, an older programming language still widely used in large business and government systems.
fixed-point arithmetic ↩
A way of representing numbers with a fixed number of decimal places so calculations stay exact and predictable.
Hyrum’s Law ↩
The idea that if enough people depend on a system, every observable behavior of that system will eventually be relied on by someone.
IMS ↩
Information Management System, an IBM mainframe database and transaction system used in many legacy enterprise applications.
job control ↩
The scripts and configuration that tell a mainframe or scheduler how and when to run programs and manage their resources.
VSAM ↩
Virtual Storage Access Method, an IBM mainframe file storage method commonly used by COBOL applications.

Reference links

Migration vendors and product approaches

Technical references and tools

Background references