220 Billion Lines of COBOL: Who Will Modernize Them?

1. The Scale Nobody Talks About

COBOL is not a legacy curiosity. It is the invisible substrate of the global financial system. Written starting in 1959, COBOL programs today process more monetary transactions than any other technology on earth. The numbers are not debatable — they are documented by Reuters, Micro Focus, and the U.S. Government Accountability Office.

Every time you withdraw cash from an ATM, there is a 95% chance the transaction is processed by COBOL. Every time you swipe a credit card at a terminal, the authorization request routes through a mainframe running COBOL. Insurance claims, pension calculations, mortgage processing, interbank settlements, tax computations — COBOL handles them all.

In the United States alone, federal agencies run an estimated 10 billion lines of COBOL. The Social Security Administration, the IRS, the Department of Veterans Affairs, and the Federal Reserve all depend on COBOL for core operations. In Europe, every major bank — BNP Paribas, Deutsche Bank, ING, Societe Generale, HSBC — runs critical systems on COBOL mainframes.

This is not a system that can be switched off. It is not a system that can be ignored. And it is not a system that the people who built it will be around to maintain much longer.

2. The Talent Crisis: A Retirement Wave With No Successor

The average COBOL developer is 58 years old. This is not a projection or a warning — it is the current state. The generation that built the financial backbone of the modern world is leaving the workforce, and no equivalent generation is replacing them.

The pipeline is dry. Fewer than 2% of universities worldwide still offer COBOL courses. Computer science graduates learn Python, JavaScript, Rust, Go — languages with vibrant ecosystems, modern tooling, and career paths that do not involve maintaining 40-year-old batch processing systems on IBM z/OS.

The consequence is predictable and severe. COBOL specialists now command salaries of $150,000 to $250,000 — not because they are doing cutting-edge work, but because they are the last people who can read the code. When they retire, the knowledge retires with them. There are no handoff documents. There are no comprehensive test suites. There is tribal knowledge accumulated over decades, stored in the heads of people who are counting down to their pension.

The COVID-19 preview

In April 2020, U.S. state unemployment systems collapsed under the load of millions of simultaneous claims. New Jersey's Governor Phil Murphy publicly appealed for COBOL programmers to come out of retirement to fix their systems. Kansas, Connecticut, and several other states faced identical crises. The systems were not broken by volume alone — they were broken by the inability to modify COBOL code quickly enough to handle new federal requirements.

This was a preview. The next crisis will not be a pandemic. It will be a regulation change, a market event, or a security breach — and the COBOL experts who answered the call in 2020 will be five years deeper into retirement.

3. Current Players: Why the Market Leaders Fall Short

The COBOL modernization market is not empty. Several large players offer solutions. But each carries significant limitations that prevent them from solving the problem at the scale and speed required.

IBM Watsonx Code Assistant for Z

IBM's offering uses AI to assist in converting COBOL to Java. It is deeply integrated with the IBM Z ecosystem and leverages IBM's institutional knowledge of mainframes.

The problems are substantial:

• Java-centric output. IBM converts COBOL to Java — not because Java is the best target language, but because IBM has a Java ecosystem to sell. The resulting Java code is verbose, often mimicking COBOL patterns in Java syntax rather than producing idiomatic modern code.
• Prohibitive cost. Watsonx Code Assistant requires IBM Z infrastructure, IBM consulting engagement, and ongoing IBM licensing. A typical enterprise engagement starts at seven figures. For mid-market banks and insurers, this is not accessible.
• Vendor lock-in. You leave IBM's mainframe to enter IBM's cloud and Java stack. The dependency does not end — it transforms.
• Limited autonomy. The tool assists developers; it does not autonomously convert programs. Human COBOL expertise is still required to guide and validate the process, which brings you back to the talent shortage.

Micro Focus (now OpenText)

Micro Focus, acquired by OpenText in 2023, has been the dominant provider of COBOL development and runtime tools for decades. Their approach is not modernization — it is emulation.

• COBOL on Linux/Windows. Micro Focus recompiles COBOL to run on commodity hardware instead of mainframes. This reduces infrastructure cost but does nothing to address the language problem. The code is still COBOL. You still need COBOL developers to maintain it.
• No language transformation. The fundamental issue — that COBOL expertise is disappearing — is not addressed. You have the same unreadable, untestable code, just running on cheaper hardware.
• Testing gap persists. COBOL running on Linux is no more testable than COBOL running on z/OS. The tooling deficit remains.

AWS Mainframe Modernization

Amazon offers two paths: replatforming (using Micro Focus runtime on AWS) and refactoring (using Blu Age to convert COBOL to Java). Both carry constraints.

• Replatforming is not modernization. Running COBOL on AWS is running COBOL. The talent crisis is unaddressed.
• Blu Age produces framework-dependent Java. The generated code depends on proprietary Blu Age runtime libraries, creating a new form of vendor dependency.
• Data sovereignty. For European financial institutions, routing core banking data through AWS raises RGPD and data sovereignty concerns that are increasingly scrutinized by regulators.

Consulting firms (Accenture, Capgemini, TCS, Infosys)

The traditional approach: hire hundreds of consultants to manually rewrite COBOL programs one by one.

• Slow. Manual rewriting of a large COBOL portfolio takes 3-7 years. Some projects stretch to a decade.
• Expensive. At $200-500 per hour for specialized consultants, a 10-million-line portfolio can cost $50-100 million to rewrite.
• Error-prone. Human rewriting introduces subtle bugs. Business logic that was encoded in COBOL's particular semantics — its decimal arithmetic, its REDEFINES, its COPY REPLACING — is easily misunderstood by developers who learned COBOL in a training course rather than spending 30 years with it.
• Ironic dependency. Manual rewriting still requires COBOL expertise to read and understand the source. The same talent shortage that motivates the project constrains its execution.

Vendor	Approach	Target language	Key limitation
IBM Watsonx	AI-assisted conversion	Java	Cost, lock-in, still needs COBOL experts
Micro Focus / OpenText	Recompilation	COBOL (on Linux)	No modernization — same code, same problem
AWS Blu Age	Automated refactoring	Java	Proprietary runtime, data sovereignty
Consulting firms	Manual rewrite	Various	3-7 years, $50-100M, error-prone
KIVUMIA.CODE	Semantic translation	Python	Service model — no self-service

4. The European Angle: DORA, RGPD, and Data Sovereignty

European financial institutions face pressures that their American counterparts do not. The regulatory environment in Europe creates both urgency and constraints that the current market leaders are poorly positioned to address.

DORA: Digital Operational Resilience Act

DORA became fully applicable on January 17, 2025. It requires all financial entities in the EU to demonstrate operational resilience across their ICT systems — including comprehensive testing, documentation, incident response, and third-party risk management.

COBOL systems are structurally non-compliant with DORA's requirements:

• Testing: DORA mandates comprehensive testing programmes including source code reviews. COBOL testing tooling is sparse and expensive. Python testing is standard practice with rich open-source frameworks.
• Documentation: DORA requires documented ICT assets and their dependencies. Most COBOL systems have no meaningful documentation. The code itself is the documentation — readable only by a shrinking pool of specialists.
• Incident response: DORA requires initial incident notification within 4 hours. When the only person who understands the failing COBOL program is on vacation or retired, that timeline is impossible.
• Concentration risk: If your COBOL capability depends on 2-3 individuals, DORA's framework requires you to address that single point of failure.

RGPD and data sovereignty

The General Data Protection Regulation imposes strict requirements on where and how personal data is processed. For financial institutions handling millions of EU citizens' data, routing core banking operations through American cloud providers raises fundamental questions:

• Data transfer risks: The Schrems II ruling invalidated the EU-US Privacy Shield. While the new EU-US Data Privacy Framework provides a replacement, its long-term stability is uncertain. Every COBOL program processing EU citizen data that gets modernized through an American vendor's cloud creates a dependency on transatlantic data transfer agreements.
• Regulatory scrutiny: European regulators — the ECB, BaFin, ACPR, DNB — increasingly question cloud concentration in American providers. A sovereign modernization approach eliminates this concern entirely.
• Client data exposure: Self-service modernization tools require uploading source code — which contains business logic, data structures, and processing rules — to vendor platforms. For regulated entities, this is a risk that must be governed.

The NIS2 dimension

The NIS2 Directive, applicable since October 2024, extends cybersecurity obligations to a broader range of sectors, including banking and financial market infrastructure. Legacy COBOL systems, with their limited security tooling and audit capabilities, create compliance gaps under NIS2 that mirror those created by DORA.

5. KIVUMIA's Position: Semantic, Sovereign, Service

KIVUMIA.CODE is built on a different premise than the incumbent solutions. Three principles define the approach.

Semantic translation, not syntactic conversion

Most COBOL modernization tools perform syntactic translation: they map COBOL constructs to equivalent constructs in Java or Python, line by line. The result is code that compiles in the target language but reads like COBOL. Variable names remain cryptic. Control flow remains convoluted. The knowledge problem is not solved — it is transferred.

KIVUMIA.CODE performs semantic translation. It understands the meaning of COBOL programs — the business logic, the data flows, the processing rules — and expresses that meaning in idiomatic Python. The output is code that any Python developer can read, maintain, test, and extend.

Dimension	Syntactic translation	Semantic translation (KIVUMIA)
Variable names	ws_acct_bal	account_balance
Data structures	Flat dictionaries	@dataclass with types
Control flow	GOTO-like jumps	Functions with clear boundaries
COBOL idioms	Preserved in target syntax	Translated to Python idioms
Readability	Requires COBOL context	Standard Python
Testability	Difficult — tightly coupled	Unit-testable functions

KIVUMIA.CODE handles the full complexity of enterprise COBOL: EXEC SQL, EXEC CICS, COPY/REPLACE, STRING/UNSTRING, INSPECT, COMPUTE with ROUNDED, EVALUATE, SEARCH/SEARCH ALL, PERFORM THRU with nested loops, REDEFINES, OCCURS DEPENDING ON, reference modification, and 88-level conditions. This is not a prototype. It is a production engine that has processed 976,144 lines of COBOL with a 100% success rate.

Brussels-based, European sovereign

KIVUMIA operates from Brussels as a Belgian SRL. Source code submitted for modernization stays within European jurisdiction. There is no transatlantic data transfer, no American cloud dependency, no FISA 702 exposure.

For European financial institutions navigating DORA, RGPD, and NIS2 simultaneously, a sovereign modernization partner eliminates an entire category of regulatory risk. Your COBOL source code — which embeds your business logic, your competitive advantage, your processing rules — never leaves Europe.

Service model, not self-service

KIVUMIA.CODE is not a downloadable tool. It is not a SaaS platform where you upload code and hope for the best. It is a managed modernization service.

The client sends their COBOL programs. KIVUMIA returns validated, tested Python. Every engagement follows a structured process:

1. Portfolio assessment: analysis of the COBOL codebase, complexity classification, prioritization by business risk.
2. Pilot conversion: a representative set of programs is converted and validated against original behaviour. The client sees quality before committing.
3. Production rollout: systematic conversion of the full portfolio, with validation at each stage.
4. Delivery: clean Python code with type hints, docstrings, dataclasses, and structured output — ready for integration into modern CI/CD pipelines.

This model exists for a reason. COBOL modernization is not a commodity. It requires domain expertise, validation rigour, and accountability for the output. A self-service tool that produces incorrect Python is worse than no tool at all — it creates a false sense of progress while introducing bugs into critical financial systems.

6. Market Sizing: Who Needs This Most

The COBOL modernization market is not uniform. Some sectors face more acute pressure than others. Understanding who needs modernization most — and most urgently — shapes both the market opportunity and the prioritization of effort.

Banking: the largest COBOL concentration

Banks are the single largest consumers of COBOL. Core banking systems — account management, transaction processing, loan origination, regulatory reporting — run on COBOL in virtually every major bank globally. In Europe, this includes:

• Retail banks processing millions of daily transactions across ATM, POS, online, and mobile channels
• Investment banks running risk calculations, trade settlement, and regulatory capital computations
• Central banks operating payment clearing and settlement infrastructure (TARGET2 in the eurozone)
• Cooperative and mutual banks — often with the oldest and least documented COBOL portfolios

The European Banking Authority (EBA) oversees approximately 4,500 banking entities in the EU. A significant majority run COBOL for at least some critical operations. DORA applies to all of them.

Insurance: complex calculations, old code

Insurance companies run some of the most computationally complex COBOL programs in existence. Actuarial calculations, policy administration, claims processing, and reinsurance treaty management are deeply embedded in COBOL batch systems.

The insurance sector faces a particular challenge: their COBOL programs encode decades of actuarial logic — mortality tables, risk models, reserve calculations — that was developed by actuaries who understood both the mathematics and the COBOL implementation. Replacing the code without losing the mathematical precision requires semantic understanding, not line-by-line translation.

EIOPA (European Insurance and Occupational Pensions Authority) oversees the sector. DORA's requirements apply to insurance undertakings and reinsurance undertakings, with the same testing, documentation, and resilience mandates as banking.

Public sector: the forgotten COBOL estate

Government agencies across Europe run massive COBOL estates that rarely make headlines until they fail. Tax authorities, social security administrations, pension systems, and public health databases depend on COBOL. The COVID-19 unemployment crisis in the US demonstrated what happens when these systems cannot adapt.

European public sector COBOL modernization is complicated by procurement rules, budget cycles, and the sheer scale of the installed base. But the pressure is mounting: citizen expectations for digital services clash with backend systems written in the 1970s.

Payment processors and financial market infrastructure

SWIFT, card networks, clearing houses, and payment processors form the circulatory system of global finance. Much of this infrastructure runs on COBOL. These entities are classified as critical ICT third-party service providers under DORA, subjecting them to direct oversight by EU supervisory authorities.

Sector	COBOL intensity	Regulatory pressure	Modernization urgency
Retail banking	Very high	DORA, RGPD, NIS2	Critical
Insurance	High	DORA, Solvency II	High
Public sector	High	NIS2, citizen demand	High
Payment infrastructure	Very high	DORA (critical third-party)	Critical
Investment banking	Medium-high	DORA, MiFID II	High

The addressable market

Global COBOL modernization spending is projected to exceed $5 billion annually by 2027, driven by regulatory mandates, talent scarcity, and the operational cost of maintaining systems that resist modern engineering practices. Europe represents approximately 30-35% of this market, with DORA acting as an accelerant that has no equivalent in other jurisdictions.

The institutions that move first will gain a competitive advantage: lower operational risk, reduced COBOL salary burden, DORA compliance, and the ability to innovate on top of modern, testable, maintainable codebases. Those that wait will face escalating costs, shrinking talent pools, and increasing regulatory scrutiny.

The Question Is Not Whether, But Who

220 billion lines of COBOL will be modernized. This is not a prediction — it is arithmetic. The developers are retiring. The regulations demand it. The operational costs of maintenance are exceeding the costs of transformation.

The question is not whether modernization will happen. The question is who will do it, how well, and whether the result will be code that is genuinely modern — testable, readable, maintainable — or code that merely compiles in a newer language while preserving all the problems of the old one.

KIVUMIA exists to answer that question for Europe. Semantic translation. Sovereign infrastructure. Service accountability. No shortcuts, no vendor lock-in, no half-measures.

The code that runs the world deserves better than emulation. It deserves understanding.