The Real Deadline for COBOL Modernization Isn't the Code — It's the People Who Understand It

The Code Isn’t Going Anywhere. The People Who Understand It Are.

Most conversations about legacy modernization treat the code as the constraint — too old, too undocumented, too risky to touch. That framing misses the part of the problem that’s actually on a clock. COBOL programs written in the 1980s will still run fine next year and the year after. The engineers who can explain why a given paragraph branches the way it does, or what edge case a strange-looking IF statement was written to catch, are a different story.

That workforce is aging out on a timeline that’s now well documented. Industry coverage this year puts the average COBOL developer at 55 to 58 years old, with roughly 10% of that specific workforce retiring every 12 months — a pace that would put something like three-quarters of today’s COBOL engineers out of the workforce within the next ten to fifteen years. The supply side isn’t refilling: more than 85% of university computer science programs dropped COBOL from their curriculum after the 1990s, so the people who could absorb that knowledge before it walks out the door mostly aren’t being trained to.

Documentation Was Never Going to Save This

The instinct is to say “write it down” — but COBOL shops have generally tried that, and documentation has a structural weakness here that’s worth naming plainly: it describes what someone believed the system did at the moment they wrote it, not what the system actually does after decades of patches, workarounds, and quiet fixes nobody logged. Reverse-engineering intent from comments and design docs that are themselves 20 or 30 years stale is often slower and less reliable than reading the code directly — except reading COBOL at scale, by hand, is exactly the bottleneck that made this a crisis in the first place.

Japan’s version of this problem has an official name. METI has been warning about what it calls the “2025 Digital Cliff” — the risk that Japanese financial institutions and other mainframe-dependent organizations hit a wall as COBOL-trained engineers retire faster than legacy systems get modernized or replaced. It’s serious enough that SCSK and FPT formed a dedicated joint venture, COBOL PARK, in October 2025 specifically to help organizations navigate that gap. That’s not a hypothetical risk being gestured at in a slide deck — it’s two established IT services companies standing up a new entity because the market decided the problem was big enough to need one.

What an AST Graph Actually Buys You Here

This is where Legacy Dragon’s interactive AST graph earns its place in the toolchain for reasons beyond raw migration speed. Parsing a 1,200-line COBOL program in about 6 milliseconds isn’t just fast — it makes it practical to sit down with a retiring engineer, pull up the actual control-flow and data-dependency graph for the program they wrote, and ask “walk me through this” while looking at structure instead of scrolling through fixed-column text. The graph doesn’t replace what that engineer knows. It gives their explanation something durable to attach to — a versioned, explorable artifact that outlives the conversation, instead of a memory that leaves the building with them.

That distinction matters more than it sounds like it should. A dependency graph regenerated from source every time the code changes stays accurate as the system evolves, in a way that a one-time knowledge-transfer interview or a wiki page written five years ago cannot. And because Legacy Dragon ships as a single binary that handles Shift-JIS, EBCDIC, and DBCS natively — the encodings that actually show up in Japanese mainframe shops running COBOL alongside JCL and PL/I — it can sit inside the same locked-down environment where the retiring engineer and the system both already live, without a security review becoming its own multi-week project.

The Window Is the Point

None of this makes the underlying modernization work optional, and it doesn’t turn a multi-year migration into a quick one. What it changes is what gets captured before the option disappears. Every year that passes without a structural way to extract what a retiring COBOL engineer knows is a year where that knowledge either gets written down imperfectly by someone who wasn’t there when the decision was made, or doesn’t get captured at all. Parsing speed and AST visualization sound like tooling conveniences. In an industry that’s watching its most experienced engineers retire faster than replacements can be trained, they’re closer to a narrowing window — and the tools that help teams use that window well are doing more than making migrations faster.

---

Facing a COBOL knowledge-transfer deadline of your own? See how Legacy Dragon’s AST graphs work at dragon.aitytech.com, read more on the parsing bottleneck it was built to solve, or reach us at hello@aitytech.com.