A LinkedIn post recently made the rounds: a calculator estimating how long it would take to convert the world's 800 billion lines of COBOL to Java. The answer, even with AI assistance, was 844 years. The post was well done — sliders, scenario modeling, a full SDLC phase breakdown. It also made the problem feel insurmountable.

Is it though?
‍

Inside the Original Formula

Working with Claude, I pulled apart the underlying model. The core calculation is straightforward: take 800 billion lines, divide by lines per developer per day, divide by the number of available developers, divide by 365.25. That gives you raw coding years — about 146 years with the original's assumptions of 150 lines per dev per day and 100K developers.

The model accurately recognizes that code translation is only a fraction of a real migration. The original model applies an 8.3x SDLC multiplier to account for the full lifecycle — discovery, requirements, architecture, testing, compliance, deployment, stabilization. That pushes the no-AI total to 1,212 years. AI then reduces roughly 38% of that effort (the phases where automation helps: code translation, test generation, discovery). The remaining 62% — UAT sign-off cycles, parallel running, regulatory approval, business acceptance testing — stays largely untouched.
The result: 844 years.

The formula is sound for what it models (minor nit: it doesn’t account for weekends). But what it models is a conversion-first SDLC — eleven phases, most of them manual, with AI applied as an accelerant to a fundamentally human process.

‍

Mapping to the MO Process

At Mechanical Orchard, our process is structurally different. We don't start with code conversion. We start with what the system actually does — capturing real production data as ground truth, then generating a modern replica and verifying behavioral equivalence against it.

The phases reflect that: analyze source code (3%), capture production data (25%), generate a modern replica candidate (20%), verify behavioural equivalence (18%), verify performance and integration equivalence (10%), regulatory and compliance (4%), integrate into production (10%), and project management overhead (10%). The long tail of debugging and rework that dominates a conversion-first approach gets absorbed into the verification loops themselves, because the specifications are deterministic — derived from actual production data flows, not inferred from reading code.

The formula changes accordingly. Time to C14N (characterization testing, the first layer of our multilayered verification process) assumes a base rate of 1,200 lines per dev per day — reflecting the higher throughput of an AI-native, data-driven process, seen with Imogen on actual customer engagements in the field. A 5x production multiplier accounts for the full lifecycle beyond code generation, given that the first verification loop is only 20% of the entire process. And an AI benefit factor recognizes that roughly 61% of the effort responds to AI acceleration, while the remaining 39% — data capture, regulatory compliance, production integration — stays human-intensive.

The base case: 47 years with AI. The most optimistic scenario, with 200K developers and a 15x AI multiplier: 4 years.

‍

Why the Gap Matters

The difference between 844 and 47 isn't about plugging in friendlier numbers, it's about what you're modeling. A conversion-first approach front-loads translation and back-loads the pain — months of functional testing, parallel running, UAT sign-off, and stabilization. A behavior-first approach integrates verification into every step so that when a slice is done, it's done and ready for production.
‍
844 years is the answer to the wrong question: how long it takes to rewrite the code. It should be how long it takes to ship something that is ready for rapid innovation.

‍

Try the calculator yourself here: