Banking's old code is too important to casually replace

Why replacing COBOL is harder than replacing a programming language

COBOL was designed for business data processing: reading records, applying rules, and producing updated accounts or reports. That makes it a natural fit for banking operations such as processing payments, calculating balances, and handling batches of transactions. Over decades, banks built these rules into large systems that now form part of their daily infrastructure.

The difficulty is not simply that the code is old. A mature banking system can encode countless business rules, including exceptions added over years as products and regulations changed. Some of those rules may be poorly documented or understood mainly by the people who have maintained them. Replacing the software means discovering what it actually does—not just translating its syntax.

The safest change can be the smallest one

Banks often keep established core systems running while newer software connects to them. An app may offer a modern interface, for example, while a back-end system still retrieves or updates account information. This lets a bank improve customer-facing services without replacing every proven component at once.

A full migration carries a different risk: a subtle mismatch could affect balances, payments, or records across many customers. Banks therefore have strong incentives to test changes carefully and preserve systems that continue to work. That caution can make modernization slower, but it avoids treating critical infrastructure as a routine software swap.

Expertise becomes part of the bottleneck

As experienced COBOL maintainers retire or move on, fewer specialists are available to interpret and update the code. That can make even necessary fixes harder to plan and review. The result is a tradeoff: keeping the system reduces immediate disruption, while depending on a shrinking pool of expertise makes long-term maintenance more difficult.

So COBOL persists not because banks cannot use newer languages, but because replacing a working system also means safely transferring its accumulated rules. The code may be decades old; the decisions hidden inside it can still govern what happens to a payment today.