COBOL in Insurance & the Talent Cliff

Part 1 named the rules as the asset and big-bang replacement as the trap. This part goes under the floorboards to the language most of those rules are written in: COBOL. Established insurers run an enormous amount of it — the policy admin, the rating engine, the claims adjudication, the nightly batch that closes the books — and the central fact about COBOL in insurance is not technical. It is demographic.

COBOL is durable, and that’s the trap

COBOL gets dismissed as a dead language, which is exactly backwards. It is alive at a scale most modern systems never reach: estimates put roughly 220 billion lines of COBOL in production worldwide (Reuters, reported 2017, via IEEE Spectrum), with later upper-bound figures above 800 billion lines (Micro Focus, by 2022). A large share of that runs the financial core of banks and insurers, because the code is reliable, the transactions are correct, and nobody wants to be the person who broke the system that prices the book.

That durability is the trap. Because COBOL keeps working, the decision to modernize keeps getting deferred — and every year of deferral subtracts from the one resource that makes safe modernization possible: people who understand it.

The talent cliff is the real exposure

The risk in an insurance COBOL estate is not that the language stops working. It is that the people who can read and safely change it are leaving on a schedule. The average COBOL developer is around 58 years old, and about 10% of the COBOL workforce retires each year (IBM, 2020, reported via Fujitsu). For a system that’s been edited by hundreds of hands over four decades, that statistic describes a slow-motion emergency.

Here is why it bites harder in insurance than almost anywhere else. The COBOL doesn’t just run transactions — it encodes the company’s pricing and adjudication judgment: the order credits and surcharges apply, the rounding rule on minimum premium, the special handling for a class of risk that one state required in 1998, the reason a particular claim type routes the way it does. None of that was documented. It lives in the code and in the memory of the few people who’ve maintained it. The institutional-knowledge-loss problem is universal in legacy systems; in insurance, the knowledge walking out the door is also the knowledge regulators expect you to be able to explain.

When the last person who understands the rating engine retires, the company doesn’t lose the ability to run it — it keeps running. It loses the ability to change it safely, and to prove what it does. That is the cliff.

Why “just convert it” doesn’t work

The seductive shortcut is automated COBOL-to-Java (or C#) translation: point a tool at the source, get modern-looking code out the other end. It fails for a reason worth understanding, because it’s a reason that recurs across this whole field.

Translation converts syntax, not understanding. The output faithfully reproduces the original structure — including the dead branches that no longer fire, the undocumented rules nobody has validated, and the accumulated workarounds — now expressed in a language your team trusts. You’ve traded COBOL nobody understands for Java nobody understands, and added a new risk: the translation might be subtly wrong in ways no one can see, because there’s no specification to check it against. Worse, it does nothing to prove the converted system still rates and pays identically. In insurance, “looks like it works” is not a standard you can file against.

The durable move is the opposite of a one-shot conversion. It starts by recovering what the COBOL means.

Retiring COBOL safely: rules first, slice by slice

The approach mirrors Part 1, applied specifically to the language risk:

1. Capture the rules before the people go. Recover the rating, underwriting, and claims rules from the COBOL — including the copybooks, the batch logic, and the data layouts — as reviewable specifications. Where the original authors are still around, capture the why while you can; it is the most perishable part and the one the code can never supply.
2. Slice by capability, not by program. Carve the estate into coherent business slices — a product, a line, a calculation — each sized to rebuild and ship in weeks.
3. Rebuild against the recovered specs, in a modern language and architecture chosen for the team that will own it, not auto-translated from the old structure.
4. Prove equivalence on real traffic. Run the modern slice in the shadow of the COBOL against mirrored inputs and compare outputs — premiums, decisions, reserves — exactly. This is parity validation; divergence is a bug found before a customer feels it.
5. Cut over gradually, retire the COBOL last. A facade shifts load to the modern slice incrementally with rollback at every step. The COBOL program is decommissioned only once the modern slice has carried live traffic and proven itself.

The mainframe-specific mechanics — CICS, DB2, JCL batch, VSAM — are covered in depth in the mainframe modernization series. The insurance-specific point is the sequencing: capture the rules first, because the people who hold them are the resource you can’t buy back.

The batch window is part of the problem

There’s a piece of the COBOL core that’s easy to overlook until it bites: the nightly batch. A great deal of an insurer’s real work happens not in the online day but overnight, in scheduled batch jobs — renewal processing, premium and commission calculations, statement and notice generation, reserving runs, statutory and regulatory extracts, reconciliation. That batch runs in a finite window before the business reopens, and the COBOL and JCL that drive it encode their own load-bearing, undocumented rules: the order jobs must run in, the dependencies between them, the handling of the records that don’t fit the happy path.

This matters for modernization in two ways. First, the batch logic is rule-rich and has to be recovered just as carefully as the online rating and claims code — a renewal batch encodes renewal rules, a reserving batch encodes reserving practice. Second, whatever you build has to fit the same operational reality: the overnight window is a hard constraint, and a modern slice that’s elegant but can’t finish the night’s work in time has failed a requirement nobody wrote down but everybody depends on. Treating batch as an afterthought is a classic way for an otherwise-careful insurance modernization to come apart at go-live.

Where AI changes the economics

The reason COBOL modernization stalled for years is that reading it is slow and depends on scarce people. AI-accelerated discovery breaks that bottleneck: it deep-reads the COBOL, copybooks, and batch together and drafts the rules and call graphs as specs senior engineers review — an analysis-time gain on the order of 10× faster than manual review. For an insurer racing the retirement schedule, that speed is the difference between capturing what the experts know and losing it. AI does the reading at scale; people and parity decide what’s true. It accelerates discovery; it does not make cutover safe — that is still earned by proving equivalence.

Avoid the false binary

Some COBOL should stay. A stable workload that rarely changes, faces no compliance or skills pressure, and runs cheaply is a legitimate candidate to leave exactly where it is — the platform is extraordinarily reliable. The talent cliff sharpens the priority, though: even for code you intend to keep, capturing the rules as specs while the experts are still here is cheap insurance against the day they aren’t. The thing to avoid is the false binary of “convert everything now” versus “do nothing.” The real choice is which slices to modernize, in what order, and how much rule-knowledge to capture before the calendar makes the decision for you.

Where this leads

This part established that COBOL is durable, the people are not, and safe retirement starts with capturing the rules. The next three parts walk the core systems in the order a program usually tackles them. Part 3, Policy Administration System Modernization, starts with the system of record — the one that holds the contract and every event in its life — and how to modernize it without losing the lifecycle rules baked into it.