Why is insurance modernization considered harder than other legacy modernization?

Because the rules carry regulatory and financial weight that most software does not. A rating engine encodes how premium is calculated across dozens of states, each with its own filed rates and rules; a claims system encodes adjudication logic and reserving practice. These rules were edited by hundreds of hands over decades and were rarely documented anywhere but the code. Getting one wrong is not a defect — it can be a mispriced policy, a wrong reserve, or a filing that no longer matches what the system does.

Do we have to replace the whole policy administration system at once?

No, and that is usually the worst way to do it. Big-bang core replacements are how insurance modernization programs become multi-year write-offs. The safer path is to slice the system by business capability — a product, a line, a calculation — rebuild one slice at a time, prove it behaves identically to the legacy system on real traffic, and cut over gradually with rollback available at every step.

Does modernizing change our regulatory obligations?

No. Regulation mandates outcomes — accurate rating against filed rates, timely claims handling, statutory reporting, data protection — not a particular technology. Modernization does not change what you owe regulators; done carelessly it puts those obligations at risk, and done well it makes them easier to evidence because the rules become explicit, reviewable specs instead of behavior buried in COBOL.

Which insurance systems are usually the legacy ones?

Almost always the four core systems: policy administration, claims, billing, and rating/underwriting. In most carriers they run on a mainframe in COBOL against DB2 or VSAM data, with nightly batch doing the heavy lifting, or on a packaged policy-admin suite that is now years behind support. The tell is not the age of the hardware. It is that the systems still run the business reliably while the knowledge of how they work has thinned to a handful of people.

Is it safer to buy a modern policy administration suite than to rebuild the core?

It depends on how standard your products are. If your lines are close to market-standard and your differentiation is not in the rating logic, a configurable suite can be the right call. If your filed rates and decades of state-by-state accommodations are the business, they rarely map cleanly onto someone else's data model, and the gaps become heavy customizations that recreate the lock-in you were trying to escape. Either way you still have to recover the existing rules before you migrate, because a suite you cannot reconcile against the old behavior is just a different black box.

How long does insurance core modernization take?

There is no honest single number, and anyone who quotes one before reading your code is guessing. A single well-scoped slice, one product or one calculation, can ship in weeks. A full core program typically runs across quarters into years, because the work is paced by how many products, lines, and state variations the rules cover, not by raw code volume. The point of the incremental approach is that value and risk reduction arrive per slice along the way, rather than all at the end, so the timeline stops being a single go-live you either hit or miss.

Insurance Legacy System Modernization: The Guide

ModernLift ·June 25, 2026 ·13 min read

Part 1 of 9

Insurance legacy system modernization is the work of moving core insurance systems — policy administration, claims, billing, and rating/underwriting — off decades-old mainframe, COBOL, and aging policy-admin platforms onto a modern stack. The defining difficulty is that the business rules (underwriting, rating, and state-by-state regulatory variation) are the most undocumented tribal knowledge in the enterprise, and a big-bang replacement rediscovers them by failing in production. The approach that works is incremental: recover the rating and underwriting rules as living specs first, then rebuild slice by slice with behavior proven against the running system before each cutover.

Behind almost every insurer is a system of record that predates most of the people running the company. It issues the policies, adjudicates the claims, calculates the premium, and produces the statutory numbers — and it has done so, line by line, for thirty or forty years. Everyone calls it “the core.” Almost no one fully understands it. This series is about modernizing that core without turning the program into the multi-year write-off that insurance modernization is famous for.

This first part maps the territory: what insurers actually run, why the business rules are the hardest part, why the obvious fix — replace it all at once — is the one that fails most reliably, and what a disciplined alternative looks like. The parts that follow go deep on each core system in turn — policy administration, underwriting and rating, claims — then on the build-versus-buy decision, compliance, the validation that makes cutover safe, and the cost.

What “the core” actually is

Insurance runs on four tightly coupled systems, and modernization eventually has to touch all of them:

Policy administration (PAS) — the system of record for the policy lifecycle: quote, bind, issue, endorse, renew, cancel. It holds the contract and everything that has happened to it.
Rating and underwriting — the logic that decides whether to write a risk and what to charge. This is where the company’s actuarial judgment and its filed rates live, expressed as rules, tables, and rating algorithms.
Claims — the system that takes a loss from first notice through investigation, reserving, adjudication, and payment. It encodes adjudication rules, reserving practice, and the reporting that feeds the rest of the business.
Billing — the money: premium collection, installment plans, commissions, refunds, and the accounting that ties to the general ledger.

Many carriers run these on a mainframe, in COBOL, against DB2 or VSAM data, with nightly batch doing the heavy lifting — the same platform pattern covered in the mainframe modernization series. Others run packaged policy-admin suites that are themselves now decades into their life and several versions behind support. Either way, the defining trait is the same: the systems work, at a reliability the business depends on absolutely, and the knowledge of how they work has thinned to a handful of people.

The rules are the asset, and they’re undocumented

The hardest thing in insurance modernization is not the code volume or the platform. It is that the business rules are the most undocumented tribal knowledge in the enterprise, and in insurance those rules carry regulatory and financial weight.

Consider what a rating engine actually contains: how base rates combine with territory, class, and exposure; how every credit and surcharge applies and in what order; how rounding and minimum-premium rules work; and how all of that varies state by state, because each state regulates its own filed rates and forms. That variation is not incidental — it is the product of decades of rate filings, regulatory negotiation, and one-off accommodations, almost none of which was written down anywhere except the code that executes it.

This is the same pattern the tribal-knowledge series describes across all legacy systems, intensified by regulation. The COBOL is the only complete, current statement of how the company prices and pays. Rebuild it from a specification someone writes today and you will silently drop the rules nobody remembered — and in insurance, a dropped rule is a mispriced policy or a reserve that’s wrong.

Why big-bang replacement is the classic write-off

Faced with an aging core, the instinct is to buy or build a replacement and cut over on a date. This is the approach that fails most reliably. Boston Consulting Group reported (September 2023) that up to 70% of digital transformations fail to deliver on their objectives, and core-system replacements in insurance are an archetype of the genre — multi-year programs that miss dates, blow budgets, and sometimes get abandoned after the spend.

The reasons are structural, not a matter of effort. The undocumented rating and underwriting rules are rediscovered only by getting them wrong in a parallel build. Scope grows faster than the team because every state and every product adds rules nobody had inventoried. And the cutover concentrates all the risk into a single irreversible moment, on a system the business cannot be wrong about. The why-modernization-projects-fail breakdown covers the mechanics; insurance simply raises the stakes.

The honest part: the appeal of a clean break is real, and the pressure to escape an unsupported platform is genuine. But the failure mode for a core insurance system is not a missed milestone — it is wrong premium, wrong reserves, or a filing that no longer matches the system.

The approach that works: rules first, slice by slice

The disciplined alternative treats the core the way the rest of this field treats legacy generally — incrementally, with the old system running the entire time — but it front-loads the thing insurance can least afford to lose: the rules.

Recover the rules as living specs first. Before any rebuild, the rating algorithms, underwriting rules, claims-adjudication logic, and their state-by-state variations are recovered from the code and written down as reviewable specifications the team owns — independent of who remembers them.
Slice by business capability. A slice is a coherent piece of behavior — a product, a line of business, a calculation — sized to ship in weeks, not a year. Not an arbitrary chunk of code.
Prove parity before cutover. Each rebuilt slice runs in the shadow of the legacy core against real inputs, and its outputs — premiums, decisions, reserves — are compared line by line against the legacy system’s. This is parity validation, and on a rating or claims engine it is non-negotiable.
Cut over gradually, with rollback. A facade in front of the legacy core shifts traffic to the modern slice incrementally, with rollback available at every step. The COBOL is retired only after the modern slice has earned live load.

This is the difference between migrating on evidence and migrating on hope. On the systems that price the book and pay the claims, that distinction is the whole program.

How the realistic options compare

Rules-first incremental is what we would recommend on a live core, but it is not the only path, and it helps to see the whole menu honestly. Four approaches show up in practice, and each fails in a different way.

Approach	What it means	The insurance-specific risk	When it actually fits
Big-bang replacement	Build or buy a new core, cut over on a date, retire the old system all at once.	Rediscovers the undocumented rating and claims rules by getting them wrong in production, on the system that prices the book. Highest chance of the multi-year write-off.	Rarely on a live core. Defensible only for a small, well-understood line you could re-underwrite by hand if it broke.
Rehost / replatform	Move the same COBOL off the mainframe to cheaper infrastructure, by emulation or recompile, without rewriting the logic.	Cuts the platform bill and the hardware risk but keeps every undocumented rule exactly as opaque as before. You still cannot file against logic no one can read.	When the pressure is cost or an unsupported platform, not agility, and you need breathing room before a real rebuild.
Buy a packaged suite	Replace the custom core with a configurable insurance platform and migrate onto its model.	Your filed rates and decades of state accommodations rarely map cleanly onto someone else’s data model. The gaps become customizations that recreate the lock-in you left, and migration still needs the old rules recovered first.	When your products are close to market-standard and your differentiation is not in the rating logic itself.
Rules-first incremental rebuild	Recover the rules as specs, rebuild slice by slice, prove parity, cut over gradually with rollback.	Slower to start because discovery comes first, and it demands the discipline to hold the line on parity gates when a deadline pushes back.	The default for a live core you cannot be wrong about. Lowest blast radius, with evidence at every step.

Notice that rehost and buy are not wrong answers, they are answers to different questions. Rehost buys time and cuts cost without touching the risk that matters. A packaged suite can be right when your products look like the market’s. Neither removes the need to understand the rules you already run, which is why every path that touches the core eventually comes back to recovering them.

Where AI changes the economics

The bottleneck in insurance modernization has always been understanding: reverse-engineering what the rating engine and adjudication logic actually do is slow, manual, and dependent on the few people who still read the code. AI-accelerated discovery changes that bottleneck. It deep-reads the COBOL, copybooks, rating tables, and data schemas together and drafts the rules — the algorithms, the state variations, the edge cases — as specs people can review. The claim worth stating precisely: this is an analysis-time gain, on the order of 10× faster than manual review, taking a discovery pass that ran twelve weeks down to about two. It does not make cutover safe — parity validation does that — but it removes the slowest, most knowledge-dependent step, and it captures what the retiring experts know before they leave.

The work is steered by senior engineers and, wherever possible, the remaining domain experts and actuaries. AI accelerates the reading and drafting; humans own the slicing decisions, the parity gates, and the judgment about which rules are sacred and which are fossils. Knowledge without rollout is a report; rollout without parity is a gamble.

Some systems are fine as they are

Not every legacy system in an insurer needs to move, and not on any timeline. A stable, low-change workload under no compliance pressure and cheap to run may be cheapest left where it is. The case for modernization is strongest where the pressures compound: an unsupported platform, scarce skills, a system blocking new products or channels, rating logic that’s grown too brittle to file against. And modernization does not change your regulatory obligations — regulation mandates outcomes, not architectures. We would rather tell you a workload doesn’t need to move than sell you a program you don’t need.

Where this leads

This part named the asset (the rules), the trap (big-bang replacement), and the only approach that reliably works on a core insurance system. The natural next question is what sits underneath all of it. Part 2, COBOL in Insurance & the Talent Cliff, looks at the language most insurance cores are still written in, the workforce that understands it, and why the migration off COBOL is a race against a retirement schedule — not just a technical upgrade.

Frequently asked questions

Why is insurance modernization considered harder than other legacy modernization?: Because the rules carry regulatory and financial weight that most software does not. A rating engine encodes how premium is calculated across dozens of states, each with its own filed rates and rules; a claims system encodes adjudication logic and reserving practice. These rules were edited by hundreds of hands over decades and were rarely documented anywhere but the code. Getting one wrong is not a defect — it can be a mispriced policy, a wrong reserve, or a filing that no longer matches what the system does.
Do we have to replace the whole policy administration system at once?: No, and that is usually the worst way to do it. Big-bang core replacements are how insurance modernization programs become multi-year write-offs. The safer path is to slice the system by business capability — a product, a line, a calculation — rebuild one slice at a time, prove it behaves identically to the legacy system on real traffic, and cut over gradually with rollback available at every step.
Does modernizing change our regulatory obligations?: No. Regulation mandates outcomes — accurate rating against filed rates, timely claims handling, statutory reporting, data protection — not a particular technology. Modernization does not change what you owe regulators; done carelessly it puts those obligations at risk, and done well it makes them easier to evidence because the rules become explicit, reviewable specs instead of behavior buried in COBOL.
Which insurance systems are usually the legacy ones?: Almost always the four core systems: policy administration, claims, billing, and rating/underwriting. In most carriers they run on a mainframe in COBOL against DB2 or VSAM data, with nightly batch doing the heavy lifting, or on a packaged policy-admin suite that is now years behind support. The tell is not the age of the hardware. It is that the systems still run the business reliably while the knowledge of how they work has thinned to a handful of people.
Is it safer to buy a modern policy administration suite than to rebuild the core?: It depends on how standard your products are. If your lines are close to market-standard and your differentiation is not in the rating logic, a configurable suite can be the right call. If your filed rates and decades of state-by-state accommodations are the business, they rarely map cleanly onto someone else's data model, and the gaps become heavy customizations that recreate the lock-in you were trying to escape. Either way you still have to recover the existing rules before you migrate, because a suite you cannot reconcile against the old behavior is just a different black box.
How long does insurance core modernization take?: There is no honest single number, and anyone who quotes one before reading your code is guessing. A single well-scoped slice, one product or one calculation, can ship in weeks. A full core program typically runs across quarters into years, because the work is paced by how many products, lines, and state variations the rules cover, not by raw code volume. The point of the incremental approach is that value and risk reduction arrive per slice along the way, rather than all at the end, so the timeline stops being a single go-live you either hit or miss.

All 9 parts of Insurance Legacy Modernization →