Insurance Legacy System Modernization: Strangler Fig, Data Migration and Parallel Running

What "legacy" means in insurance

Insurers keep systems longer than most industries because a life policy or a long-tail liability claim can stay open for decades, and the system that issued it has to keep servicing it. The usual estate looks like this:

Each needs a different first move, which is why we always start with an assessment rather than a rewrite proposal. Our legacy modernization services page covers the general method; this post is the insurance-specific version.

Why big-bang replacements fail

• In-force business cannot pause. Endorsements, renewals and claims on existing policies continue every day of the project.
• Business rules are undocumented. Twenty years of rating exceptions, state-specific notices and manual workarounds live in code and people's heads; nobody can list them all up front.
• Data is effective-dated and messy. Policies have many versions, some backdated, and historic data often breaks rules the new system enforces.
• One cut-over date concentrates every risk. If anything is wrong, the whole book is affected and rollback is rarely real.

The strangler fig approach

The strangler fig pattern (named by Martin Fowler) replaces a system gradually: put a facade in front of the old system, route one piece of functionality at a time to new code, and retire the old parts as they stop receiving traffic. In insurance the slices are usually chosen along one of three axes:

Renewal is a natural migration point: as each policy renews, it is rewritten on the new system, and after one policy term most of a personal lines book has moved without a bulk conversion. Long-tail lines and life business need a conversion instead, because policies may not renew for years.

The facade matters. We usually put an API layer in front of the legacy system first, even before any new functionality, so every new channel talks to one stable interface and the legacy system can be swapped out behind it later. Our API development and integration team builds these layers, including wrappers around batch files and database replicas when the old system has no API.

Data migration and reconciliation

Migration is where insurance modernisations actually slip. The work is less about moving rows and more about proving the numbers match.

1. Profile the source: count policies, versions, transactions and claims by status and year; find nulls, orphans and values outside the expected codes.
2. Map to the target model with every transformation written down, including the decisions about history (all versions, or current term only plus a read-only archive).
3. Build the migration as repeatable code, not a one-off script, so it can be run dozens of times against fresh extracts.
4. Reconcile on business totals: written premium by month and state, in-force counts, outstanding reserves, paid losses, unearned premium. Row counts are not enough.
5. Sample-check documents: regenerate declarations pages for a random sample on the new system and compare them with what was issued.
6. Rehearse the cut-over for each slice at least twice with timing, then run it for real.

Running old and new in parallel

For each slice there is a period where both systems run. Two patterns work:

Shadow mode is ideal for rating: run a quarter of quotes through both engines and investigate every difference above a cent. Sync services are needed when the business uses both systems at once, for example new business on the new platform and endorsements to old policies on the old one.

Testing a system nobody fully understands

Before changing a legacy rating or billing module, capture what it does today. Characterisation tests (sometimes called golden master tests) feed thousands of real historic inputs through the old code, record the outputs and turn them into the test suite for the new code. For a rating engine that means a sample of real quotes by state, product and effective date; for billing, a set of accounts with instalments, endorsements and cancellations replayed month by month. Every difference is either a bug in the new code or an undocumented rule in the old one, and both are worth knowing.

Keep these tests running after go-live. They become the regression suite that protects rate changes and new states, which is where most insurance defects appear. Our QA and testing team builds them as automated jobs in the deployment pipeline so a failed comparison blocks a release.

Governance that keeps a staged programme on track

• One owner per slice from the business side who signs off the reconciliation, not only the IT steering group.
• A published slice plan with dates, so underwriting, claims and finance know when their process moves.
• A decommissioning date for every legacy component that is replaced, or the old system never actually switches off and you pay to run both forever.
• Monthly cost reporting that shows legacy run cost going down as slices move, which keeps the programme funded.

Our relevant work (adjacent, not insurance)

We have no published insurance modernisation case study yet. The closest first-hand work is Paint Nite, a ticketed events platform in the US and Canada that we rebuilt in NestJS and Next.js beside the live legacy system. Dedicated sync services keep the new platform and the old one aligned so features migrate in slices; search indexes are versioned behind aliases with dual-write during rebuilds, so schema changes that previously needed production downtime now ship with none; and the work is tracked through 53 database migrations. Different industry, same problem: the business could not stop while the system was replaced. Our codebase takeover guide covers the first weeks on an unfamiliar system.

Cost and timeline

For a full custom replacement of a policy system, see our policy administration system cost post, where custom builds sit at $80k to $200k+. If you need people rather than a project, .NET developers and data engineers can join your team on a monthly basis. Start from the insurance industry hub for everything else we do for insurers.