What Is COBOL & Why It's Still Everywhere

There is a good chance the last paycheck you received, the last card payment you made, and the last insurance claim you filed all passed through COBOL code older than the engineers maintaining it. The language is sixty-six years old. It is also, by any honest measure, one of the most successful pieces of software infrastructure ever built — quietly running the financial and administrative core of the modern world while every newer technology gets the attention. This series is about that language: what it is, why it endures, and what it actually takes to move off it without breaking the things it runs.

This first part defines the subject. The nine parts that follow go deep — the real-world footprint and the dialect landscape, the workforce cliff, the mechanics of migrating COBOL, the choice of target language, how business logic is preserved, the risks, where AI changes the work, and what it costs. Throughout, this series is about the language — its grammar, its data structures, its dialects, and the work of converting it. The platform it usually runs on, IBM Z, has its own series; the two are companions, not duplicates.

What COBOL actually is

COBOL stands for COmmon Business-Oriented Language. It was defined in 1959 by a committee convened by the US Department of Defense — Grace Hopper’s work on earlier business compilers was a direct influence — with an explicit goal that set it apart from every language around it: programs should read like English so that the business, not just programmers, could follow them. That design choice explains almost everything about how COBOL looks and why it has lasted.

A COBOL program is organized into four divisions, in a fixed order:

• IDENTIFICATION — names the program.
• ENVIRONMENT — describes the machine and the files it talks to.
• DATA — declares every piece of data the program touches, in exhaustive detail.
• PROCEDURE — the actual logic, written as paragraphs and sections that are executed and PERFORM-ed like subroutines.

The verbosity is deliberate. MULTIPLY HOURS BY RATE GIVING GROSS-PAY is not clever, but a payroll clerk can read it. Six decades of programmers leaned into that readability, which is part of why the code is still legible today — and part of why there is so staggeringly much of it.

The data structures are the real story

Most explanations of COBOL stop at “it reads like English.” That misses the part that actually matters for modernization. COBOL’s enduring advantage — and its migration difficulty — lives in the DATA DIVISION, in how it describes records.

• The PICTURE (PIC) clause declares the exact shape of every field: PIC 9(7)V99 is a seven-digit number with two implied decimal places. The shape is the type. There is no separate notion of “integer” or “float” the way modern languages have — there is the picture, and the picture is law.
• COMP-3, packed decimal, stores two decimal digits per byte with a sign nibble. It is exact base-ten arithmetic with no floating-point rounding error — which is exactly what you want for money, and exactly what does not map onto a naive float or double in a modern language. Get this wrong in a migration and you produce a system that is subtly, expensively incorrect about cents.
• Copybooks are shared record layouts pulled into many programs with COPY. They are how dozens of programs agree on the structure of “a customer record” — and how a single layout change ripples across an entire estate.
• REDEFINES lets the same bytes be read two different ways; OCCURS ... DEPENDING ON declares variable-length arrays whose length is set at runtime. Both are common, both are powerful, and both make “just read the data” far harder than it sounds.

Layered on top is EBCDIC, IBM’s character encoding, which is not ASCII. Text that looks fine on the mainframe arrives as garbage off it unless every field is converted with its picture in mind. None of this is exotic on a real COBOL estate — it is Tuesday. It is also why a COBOL migration is, underneath, a data-fidelity problem as much as a code problem. Part 7 returns to this in depth.

Where COBOL actually runs

“Everywhere” is easy to say and easy to wave off. Concretely, COBOL clusters in a handful of industries that share one trait: they move money or records at high volume, and being wrong is expensive.

• Banking. Core banking systems run heavily on COBOL. That means the ledgers behind accounts, deposits, interest, and end-of-day settlement, plus much of the card and payment-network processing that clears transactions in the background of every swipe and tap.
• Insurance. Policy administration and claims engines are a classic COBOL stronghold. A single policy can carry decades of rules about coverage, premiums, and payouts. The rules accrete, and the code outlives the actuaries who wrote it.
• Government. Tax processing, benefits and social-program administration, pensions, and licensing records run on COBOL across national and state agencies. These are the systems that made headlines in 2020, when a surge in unemployment claims led several US states to put out public calls for COBOL programmers to keep benefits systems running under load. That workforce cliff is Part 3 of this series.
• Payroll and HR. Calculating gross-to-net pay, tax withholding, and deductions across large workforces is exactly the arithmetic COBOL was built for, and much of it still runs there.
• Travel and logistics. Airline reservations, plus parts of shipping and supply-chain scheduling, carry long-lived COBOL and adjacent mainframe code.

The pattern is not nostalgia. These are the domains where COBOL’s exact-decimal arithmetic and overnight batch throughput are a genuine fit, and where the cost of a botched replacement is measured in missed payments and public failures, not a bad sprint.

Why it is still everywhere

The natural question is why anyone still runs a language from 1959. The honest answer is that COBOL is genuinely good at the one thing it was built for, and replacing it has always been expensive and risky. Three forces keep it in place:

It works, at a scale and reliability most systems never reach. COBOL batch jobs process enormous transaction volumes overnight, every night, correctly, for decades. “If it isn’t broken” is not laziness here; it is an accurate assessment of an asset that rarely fails.

Exact decimal arithmetic is a feature, not a relic. The packed-decimal math that is awkward to migrate is the same math that makes COBOL trustworthy for money. Modern languages can match it, but only with deliberate use of decimal types — the default behavior in most of them is the wrong behavior for a ledger.

The business rules are load-bearing and undocumented. Decades of edits have buried thousands of rules in the code — the rounding convention in an interest calculation, the special handling of one record type a downstream job has depended on since the 1990s. These rules are the business. They were never written down anywhere else, and rebuilding from a tidy specification loses them silently.

The scale is real, not rhetorical. Estimates of COBOL in production range from roughly 220 billion lines (Reuters, reported 2017, via IEEE Spectrum) to upper-bound figures above 800 billion (Micro Focus, by 2022). The range is wide because no one can inventory it precisely — but both ends say the same thing: this is load-bearing infrastructure, not a museum piece. Part 2 takes that footprint apart properly.

“Old” is not the same as “broken”

It is worth stating plainly, because the framing matters for any honest modernization conversation: COBOL is not end-of-life. IBM actively maintains and ships modern compilers — Enterprise COBOL for z/OS — and the language has an ISO standard that was revised as recently as 2023. There is no vendor pulling support out from under it next year. That is exactly why a credible case to modernize off COBOL is not built on a fake deadline. The real pressures are different and more durable: the workforce that understands these systems is retiring on a schedule, the operating cost is high, and the rate of change the business now demands is hard to deliver against a tightly coupled COBOL-and-batch estate.

If you take one idea from this part into the rest of the series, make it this: respect the asset. The teams that fail at COBOL modernization are usually the ones who started by assuming the old system was stupid. It is not stupid. It is precise, durable, and full of decisions that turned out to matter. The job is to carry those decisions forward into something maintainable — not to discard them and rediscover them in production.

So what do you do about it?

Defining COBOL is the easy part. The reason anyone reads about it is the harder question underneath. If this code is durable but expensive to keep and getting harder to staff, what are the actual options? At a high level there are five, and they trade off risk, cost, and how much of the original behavior you carry forward.

Approach	What it means	Keeps the business rules?	Best when
Retain	Leave it running and invest in documentation and support.	Yes, entirely	The system is stable and the pressure is not yet acute.
Rehost	Move the same COBOL onto cheaper infrastructure, often off the mainframe. Sometimes called lift-and-shift.	Yes	Cost is the driver and the code itself is fine.
Replatform	Recompile COBOL to run on a modern runtime or emulator with minimal code change.	Yes	You want off the mainframe quickly without rewriting logic.
Refactor or rewrite	Translate the logic into a modern language such as Java, C#, or Python, preserving behavior.	Only if done deliberately	Agility and talent are the drivers and you can invest in proving parity.
Replace	Swap the system for commercial off-the-shelf software.	No, you adopt the package’s rules	A packaged product genuinely fits your process.

The option that fails most often is the refactor done casually: a rewrite that treats the COBOL as a rough spec instead of the source of truth, and quietly loses the buried rules this article keeps pointing at. Which approach fits is a real analysis, not a slogan, and it is the subject of Part 4, the migration guide. If you would rather talk it through against a specific estate, that is what a discovery call is for.

Where this leads

This part defined the language and the data structures that make it both durable and hard to leave. The obvious next question is how much of it is actually out there — and the answer is more interesting than a single number, because COBOL is not one monolith but a family of dialects running on a range of compilers, from IBM’s mainframe COBOL to the versions that run off-mainframe entirely. Part 2, How Much COBOL Is Still in Use?, maps the real footprint, explains why the estimates vary so widely, and walks the dialect-and-compiler landscape you have to know before you can plan a migration.