Japan's ¥12 Trillion Legacy-System Warning Isn't a COBOL-Skills Story. It's an Encoding Story.

The Cliff Everyone Talks About Is a Budget Line

Japan’s “2025 digital cliff” (2025年の崖) has been the reference point for legacy-system risk in Japan since METI’s DX Report first used the phrase in 2018: if companies don’t modernize aging core systems, the ministry estimated economic losses could reach as much as ¥12 trillion per year between 2025 and 2030 (ict-miraiz; c3index). Seven years on, the warning hasn’t aged into irrelevance — a 2025 follow-up survey found only 7% of companies say they’ve fully cleared the cliff, with roughly 40% still reporting serious unresolved challenges (ict-miraiz).

Most of the commentary around that number is about the things you’d expect: retiring COBOL engineers, ballooning maintenance cost on systems nobody fully documented, and the operational risk of a rip-and-replace cutover. What gets far less attention is a failure mode that doesn’t wait for cutover night to show up — it’s already sitting in the data the moment two systems that encode characters differently have to agree on what a byte means.

The Trap Nobody Budgets For

IBM’s own modernization guidance names this explicitly as one of ten recognized failure patterns in legacy transformation projects: character code and attribute handling (“文字コード・属性の罠”) gets its own entry in IBM’s “10 traps” of modernization (IBM) — not because it’s exotic, but because it’s the kind of problem that looks solved and isn’t.

Here’s the mechanism. Mainframe systems built since IBM’s System/360 in 1964 predominantly use EBCDIC, and EBCDIC and the encodings a modern estate actually runs on — Shift-JIS, Unicode — don’t even agree on basic collation. Sorted in ascending order, EBCDIC places letters before digits; Shift-JIS and Unicode place digits before letters (Hitachi ITPF). A COBOL sort step or an ORDER BY clause that has “worked correctly” for thirty years can silently reorder records the moment the same logic runs against re-encoded data — no error thrown, no exception logged, just output that’s wrong in a way nobody’s regression suite was written to catch.

User-defined characters (外字/gaiji) compound it. Migrating from an environment that uses custom-registered characters means those characters have to be re-created in the target environment, and how many you can even register depends on which character code you land on (Hitachi ITPF) — company-specific part-number characters and banking gaiji included. This is common enough as a compatibility problem that Oracle ships a dedicated EBCDIC binary-order emulation feature specifically so migrated applications don’t have to be rewritten around the mismatch (Oracle docs) — a sign that major vendors treat this as its own standing compatibility problem, not something a one-time file conversion quietly resolves.

A Parsing-Layer Problem, Not a Migration-Script Problem

The common way this gets handled is a conversion step bolted in front of whatever reads the data — pipe the export through an encoding converter, then hope the downstream logic (sort comparisons, fixed-width field boundaries, DBCS lead/trail byte detection) behaves the same against the converted copy as it did against the original. When save-side and read-side encoding assumptions don’t match, the result is mojibake — and worse, silent corruption in cases where the mismatch doesn’t produce garbled text, just wrong values.

Legacy Dragon reads Shift-JIS, EBCDIC, and DBCS natively, alongside the ten source languages it parses — COBOL, JCL, PL/I, VB6, VB.NET, PowerBuilder, Assembly, SQL/DB2, CICS, and REXX. That’s a deliberate placement: encoding handling sits inside the parser that builds the AST and dependency graph, not in a preprocessing script that runs before Legacy Dragon ever sees the file. A graph built from a pre-converted copy inherits whatever that conversion step got wrong. A graph built by parsing the source in its original encoding doesn’t have that particular class of error to inherit — which matters most exactly where the ¥12 trillion estimate assumes the risk lives: in estates where EBCDIC mainframe cores and Shift-JIS-era peripheral systems have been coexisting for decades, not in the workforce-attrition slide everyone already has memorized.

None of this claims that solving encoding fidelity by itself gets a company off METI’s cliff — workforce retirement and system-age risk are real and separate problems. What it does mean is that the assessment phase most modernization projects run before touching a line of logic can start by asking a smaller, checkable question: does the graph we’re building already understand how this data was actually encoded, or are we trusting a conversion step we haven’t verified?

---

Curious what “what does this actually touch” looks like once encoding is handled at the parsing layer instead of guessed at afterward? See Legacy Dragon, read more on why the AST graph is built for impact analysis first, or reach us at hello@aitytech.com.