Not a manifesto for rewriting everything. A case for making what already works visible, governable, and transferable.
"If a COBOL system works, why change it?"
We largely agree. A payroll system, accounting platform, or banking application that has been running reliably for decades should not be rewritten simply because a newer language exists. History is full of expensive modernization projects that replaced stable systems with less reliable alternatives.
The real question is whether the business logic embedded inside COBOL remains understandable, governable, and transferable.
In our own work within financial institutions, we regularly see organizations moving toward SAP ecosystems, cloud platforms, APIs, and modern integration architectures. Rarely does this happen through complete replacement. More often, legacy systems remain in place while new capabilities are built around them.
What becomes increasingly important — and increasingly urgent — is understanding the logic that sits inside those legacy applications. Not just running it. Understanding it.
"The value is not in translating COBOL into Java. The value is in making business knowledge portable."
We are trying to make COBOL understandable.
If an organization can automatically document, analyze, test, and explain decades of accumulated business logic, it gains options. It can continue running the existing system. It can expose services through APIs. It can modernize gradually. It can train new staff. It can satisfy auditors and regulators. It can reduce dependency on a shrinking pool of specialists.
Regulation (EU) 2022/2554 entered into full effect on 17 January 2025. It applies to banks, insurance companies, investment firms, and critical ICT third-party providers operating in the EU.
DORA does not mandate migrating away from COBOL. It does require organizations to:
An institution that cannot fully explain what its COBOL systems do — or that relies on three people who retire next year — has a material DORA compliance gap. That is the problem we are designed to address.
An instructive parallel comes from the aviation industry. Contrary to popular belief, airlines are actively modernizing COBOL-based systems used for reservations, ticketing, crew scheduling, and operational support. They are not performing risky "big bang" replacements. Instead, they are gradually extracting functionality, building modern Java and cloud services around existing systems, and using automation and AI-assisted tools to preserve business logic while reducing migration risk.
This incremental approach — understand first, migrate selectively, validate continuously — is the only strategy that has consistently worked at scale. It is the strategy we are building tooling to support.
In our experience working with financial institutions, the pattern is almost always the same. Not replacement — wrapping. The existing COBOL system stays running. New capabilities are built around it: REST APIs, event streams, cloud-native reporting layers.
What changes is the outer shell, not the core. And that works — until the people who understand the core retire, until a regulator asks for an audit trail that doesn't exist, or until the business needs to change a calculation that nobody can confidently locate.
That is the moment organizations discover they needed documentation, test coverage, and a readable representation of their business logic years before they thought to ask for it.
The same problem — accumulated business logic that nobody can fully read, test, or transfer — exists across every major legacy language ecosystem. We are building a factory for language modernization packages, not a single-language tool. COBOL and RPG are live today. NATURAL and PL/I are next.
Each language gets its own pipeline — preprocessor, grammar, transpiler, runtime library, and equivalence test suite — built with the same deterministic methodology. The approach does not change. Only the language does. See the full language roadmap →
The ideas on this page — the scale of COBOL, the retirement cliff, the DORA compliance gap, why we don't believe in big-bang rewrites — explored in conversation.
Perhaps we are early. The conversations we are having suggest the need is real, and it is growing.
Not replacing COBOL. Not rewriting everything. Not chasing technology for its own sake.
Simply making decades of accumulated business logic visible, understandable, and usable in a world that increasingly demands transparency, integration, and operational resilience.
Get in touch to discuss your codebase, or try the live transpiler demo.