COBOL PARK: Japan Just Created a Company to Save COBOL — Here's Why That Matters Everywhere

In early 2025, two technology giants—Vietnam's FPT Software and Japan's SCSK Corporation—did something remarkable. They created an entire company dedicated to a single programming language. Not a startup chasing the latest framework. Not an AI lab building foundation models. A company called COBOL PARK, focused on preserving and modernizing systems written in a language that first appeared in 1959.

When I first read the announcement, I didn't laugh. I nodded. Because after 35 years of working with legacy systems, I know exactly why they did it—and why every enterprise running mainframes should pay attention.

This isn't a Japan problem. It's a global infrastructure emergency hiding in plain sight. And the clock is ticking.

Why Japan Created a Company to Save COBOL

Japan's Ministry of Economy, Trade and Industry has a name for what's coming: the "2025 Digital Cliff." It's not hyperbole. The ministry estimates that if Japan's legacy systems fail due to unsupported code and absent expertise, the country could lose up to 12 trillion yen annually—roughly $80 billion USD.

The financial sector alone runs on an estimated 500 billion yen worth of COBOL-dependent infrastructure. Every major Japanese bank. Every insurance company. The payment rails that move money through the world's third-largest economy. All of it traces back to mainframe code, much of it written decades ago by engineers who are now retiring—or already gone.

FPT and SCSK saw what was coming. COBOL PARK isn't a vanity project or a nostalgic tribute to legacy technology. It's a survival mechanism. The joint venture's explicit mission: secure a robust talent pipeline for legacy system maintenance, mainframe migration, and modernization. In plain terms—find and train people who can keep these systems running before the last generation of experts disappears.

The Talent Crisis No One Wants to Talk About

Here's a number that should concern every CIO: the average COBOL programmer is over 55 years old. Not 45. Not 50. Over 55. By some estimates, 70-80% of the world's active COBOL programmers will retire by 2030. We're not talking about a gradual transition—we're talking about a cliff.

And it's not just COBOL. The developers who understand mainframe architecture, JCL, CICS, DB2, IMS—the entire ecosystem that enterprises depend on—are aging out of the workforce. Universities stopped teaching these technologies decades ago. Young developers want to build mobile apps and machine learning models, not maintain batch processing systems written before they were born.

The result is a knowledge vacuum. When the developer who wrote your core banking logic in 1987 finally retires, they take something with them that no documentation can fully capture: the understanding of why the code works the way it does. The edge cases. The undocumented business rules. The workarounds for bugs in systems that no longer exist. That institutional knowledge walks out the door, and it doesn't come back.

I've seen this play out dozens of times. A client calls in a panic because a batch job failed and nobody knows what it does. We dig through the code and find logic that references a business process that was discontinued in 2003. Except—the code still runs. It still does something. And nobody is quite sure what will break if we remove it. So it stays. Layer upon layer of accumulated logic, with the people who understand it disappearing one by one.

This Isn't Just Japan's Problem

When I tell Canadian clients about COBOL PARK, some of them shrug. "That's Japan," they say. "Our systems are different."

They're not.

As we've documented before, COBOL still runs the world. The Royal Bank of Canada, TD Bank, Bank of Montreal, Scotiabank—every major Canadian financial institution runs core operations on mainframes. Provincial governments. Federal agencies. The payment systems that process your mortgage, your tax return, your pension deposit. COBOL. Everywhere.

The United States faces the same crisis. The IRS runs on COBOL. Social Security runs on COBOL. State unemployment systems—remember the disasters during the pandemic when systems couldn't handle the load?—run on COBOL. The talent shortage isn't a regional phenomenon. It's a global infrastructure risk.

Why AI Won't Save You (Alone)

Every vendor has a solution these days. IBM has watsonx Code Assistant for Z, promising AI-powered COBOL modernization. Microsoft published guides on using AI agents for COBOL migration. Startups like Sanciti AI are launching products like LEGMOD, positioning "agentic AI" as the answer to legacy challenges.

These tools have their place. They can accelerate documentation. They can help translate straightforward code. They can identify patterns and suggest refactoring opportunities. What they cannot do is replace human understanding of business logic that was never documented, never explained, and exists only in the minds of developers who wrote it.

I've evaluated several of these tools on real client codebases. They work impressively well on clean, well-structured code with clear comments. They struggle badly on the kind of code that actually exists in production: decades of accumulated changes, cryptic variable names, business rules embedded in nested IF statements that nobody dares touch because the last person who tried broke payroll for 10,000 employees.

"AI can translate COBOL to Java. But it can't tell you why that one subroutine runs on the third Tuesday of every month except in December. That's not in the code. That's in someone's memory."

The organizations getting real results are using AI as an accelerator, not a replacement. They pair AI tools with experienced engineers who can validate the translations, catch the edge cases, and preserve the business logic that matters. It's the same hybrid approach we advocate for all legacy modernization: technology amplifies human expertise, it doesn't eliminate the need for it.

The Maintain + Modernize Approach

COBOL PARK's strategy reveals a truth that the "just rewrite everything" crowd ignores: sometimes you need to maintain systems while you modernize them. Not instead of modernization. Alongside it.

The joint venture explicitly targets both maintenance and migration. They're not pretending that enterprises can flip a switch and move to cloud-native microservices overnight. They're acknowledging reality: these systems need to keep running while you figure out how to evolve them. And keeping them running requires people who understand them.

This is the approach we've followed at BJPR for 35 years. When a client comes to us with a critical mainframe system, we don't immediately pitch a migration project. We start by understanding the system. Documenting what isn't documented. Identifying the components that are genuinely fragile versus the ones that have run flawlessly for decades. Then we build a realistic path forward—one that doesn't bet the business on a big-bang rewrite.

What This Means for Canadian Enterprises

COBOL PARK is a signal. When two major technology companies invest in a joint venture specifically to address legacy talent shortages, it means the problem has become impossible to ignore. The question for Canadian enterprises: are you ahead of this curve, or behind it?

If you're still running critical operations on mainframes—and statistically, you probably are—here's what you should be doing right now:

Audit Your Talent Exposure

How many people in your organization actually understand your legacy systems? What's their average age? What happens when they leave? If you don't have clear answers to these questions, you have a risk you haven't quantified.

Accelerate Knowledge Transfer

Get your senior developers working with junior staff—or external partners—before it's too late. Document everything. Record code walkthroughs. Create institutional memory that isn't dependent on individual people.

Build Relationships with Legacy Specialists

The pool of COBOL expertise is shrinking. The firms and consultants who genuinely understand these systems are in high demand. If you wait until you have an emergency, you'll be competing for scarce resources with everyone else who waited.

Start Your Modernization Journey—But Realistically

Modernization doesn't have to mean replacement. Start with the components that provide the most value or carry the most risk. Build adapter layers that let modern applications talk to legacy systems. Create optionality without betting everything on a single transformation project.

The BJPR Perspective

We've been doing this work for 35 years—since before "legacy system" was even a term. We've maintained COBOL codebases, migrated mainframe applications, and built bridges between systems that were never designed to communicate. We've seen the "just rewrite it" approach fail, and we've seen incremental modernization succeed.

COBOL PARK validates what we've always believed: you can't just replace these systems. You need people who understand them. People who can read 40-year-old code and see not just syntax, but business logic. People who can stabilize what's fragile, modernize what's exposed, and preserve what works.

Japan recognized this truth and created a company to address it. The question for every enterprise running legacy infrastructure is whether you'll act before the talent crisis hits—or after.

Because the developers who built your systems are retiring. The knowledge they carry is finite. And once it's gone, no AI tool can bring it back.