The COBOL Retirement Cliff: Your Biggest Legacy Risk Isn't Technical

There's a risk on your policy administration system that won't appear in any technical audit, because it isn't technical. It's demographic.

The people who understand your legacy core — the mainframe, the COBOL, the decades of undocumented business logic — are retiring. Not in ten years. Now. And when they go, they take with them knowledge that exists nowhere else: not in documentation, not in the code comments, only in their heads.

This is the quiet reason legacy modernisation is more urgent than the technology alone suggests.

The knowledge that's about to walk out

Your policy system doesn't just run code. It encodes forty years of decisions:

  • Why a particular rating factor is calculated the odd way it is (a regulator required it in 1998).
  • What the 2am batch job actually fixes (bad data from a specific upstream feed that nobody's allowed to change).
  • Which edge case in renewals only fires for one legacy product in one state.
  • The workaround for the bug that was never fixed because fixing it would break something downstream.

None of this is written down. It lives in the memory of a handful of people who've been there for decades. When they retire, it doesn't transfer — it evaporates. And you don't discover what evaporated until the system does something inexplicable and there's no one left who knows why.

Why this makes "do nothing" the risky option

The usual case for keeping the legacy core is "it works, don't touch it." That logic quietly inverts as the knowledge base ages.

A system nobody fully understands is fine while the people who understand it are still there to catch problems. The moment they're gone, that same system becomes a black box making financial decisions that no one can explain, modify, or safely fix. "It works, don't touch it" becomes "it works, and we pray, because we can no longer touch it."

Every year you defer, the migration gets harder — not because the technology ages, but because the human knowledge required to migrate it safely is leaving the building. You are in a race between modernisation and retirement, and retirement doesn't slip its deadline.

Migration is knowledge capture in disguise

Here's the reframe that changes the priority. A properly-run legacy migration isn't primarily a technology project. It's a knowledge-extraction project that happens to produce a modern system as its output.

Remember the reconciliation discipline: when your new system's calculations disagree with the legacy system's, every mismatch is an undocumented rule you just discovered. That process — running both systems in parallel, chasing every divergence to root cause — is the only reliable way to extract the tacit knowledge before it leaves. You're not just moving data. You're forcing the black box to reveal what it does, while the people who understand it are still around to confirm your findings.

Do the migration while your experts are still there, and they validate your reconstruction. Do it after they've gone, and you're reverse-engineering a black box with no one to ask — vastly harder and riskier.

What to do about it

1. Inventory the knowledge risk, not just the tech risk. Who understands each critical system, and when are they leaving? That's a more urgent chart than any architecture diagram.

2. Start extraction now, migration or not. Even if you're not ready to migrate, start capturing the tacit knowledge — pair the veterans with people documenting what they know, and use reconciliation-style analysis to make implicit rules explicit while you still can.

3. Sequence the migration by knowledge risk. Migrate the systems whose experts are closest to retirement first. Counterintuitive — you'd normally start with the easiest — but the constraint here is human, not technical.

4. Use the parallel run as the capture mechanism. Every reconciled difference is documented institutional knowledge that would otherwise have retired.

The point

The business case for legacy modernisation is usually made on cost, agility, and AI-readiness — all real. But the argument that should actually set the timeline is the one nobody puts in the deck: the people who understand your legacy systems are leaving, and their knowledge is the thing that makes safe modernisation possible at all.

You're not choosing whether to modernise. You're choosing whether to do it while you still have the people who can tell you what the old system actually does. That window is closing on its own schedule, and it doesn't reopen.

We run phased legacy migrations designed to capture institutional knowledge, not just move data — 200+ across the modern lakehouse. More at IntelliBooks.

Comments

Post a Comment

Popular posts from this blog

Why Insurance Fraud Rings Are a Graph Problem (And Your SQL Database Can't See Them)

Your fraud team is good at catching individuals. A claimant whose story shifts, a receipt that looks altered, someone who files a bit too often. That's what the rules were built for, and they work. They're nearly blind to organised fraud — and organised fraud is where the money goes. The reason isn't that your team lacks skill or your rules lack sophistication. It's that you're asking a question your database structurally cannot answer. What a fraud ring actually looks like A ring isn't one bad claimant. It's a network: a handful of claimants, a couple of "witnesses", a repair shop, a medical clinic, a few bank accounts, some phone numbers, and a device or two — recombined across dozens of claims over months. Take any single claim from that ring and it looks fine. The claimant has no history. The damage is plausible. The repair estimate is in range. Nothing trips a rule, because the rule is examining one claim in isolation, and in isolati...
Read more

Claims Leakage: The Quiet Loss AI Can Close

Claims leakage is the money your company pays out that it didn't have to. Not fraud — leakage. The extra amount on legitimate claims that got overpaid because someone missed something, applied the wrong rule, or lacked the information to know better. Industry estimates put it at 3–10% of claims spend. For a mid-size insurer that's a rounding error you could retire. And almost nobody manages it directly, because it's nearly invisible — every individual leaked rupee looks like a normal payment. Why leakage is so hard to see Fraud has a villain. Leakage doesn't. It's the accumulation of small, defensible, individually-reasonable decisions: An adjuster settled at the reserve figure because they were busy, and the reserve was set high. A repair was authorised at shop rates when a network rate applied. A subrogation opportunity was never flagged, so recovery never happened. A policy limit or deductible was applied wrongly because the coverage detail was buried...
Read more

The Subrogation Money Insurers Leave on the Table

Subrogation is the least glamorous word in insurance and one of the most profitable. It's the process of recovering money from the party actually responsible for a loss, after you've paid your customer. Done well, it flows straight to the bottom line — recovered money is nearly pure margin. Most insurers leave a lot of it on the table. Not because they don't try, but because the opportunities are identified too late, by the wrong people, from incomplete information. It's a data problem, and it's an unusually clear one. Why subrogation is a timing game you're losing Recovery potential decays fast. The evidence that establishes another party's liability — the scene, the witnesses, the vehicle, the maintenance records, the CCTV — degrades or disappears within days. The other party's insurer gets less cooperative once they've closed their own file. So the single biggest lever in subrogation is identifying the opportunity early , ideally at first ...
Read more