Most insurance leaders no longer debate whether the legacy core has to change. The question that keeps the program from starting is a different one: how do we change it without stopping the business?
Insurance does not have quiet periods. Renewals arrive every day. Claims are reported at 2 a.m. on a Sunday. Brokers expect quotes while the reinsurance renewal season is in full swing, and finance still has to close the quarter. A modernization plan that needs a long freeze or a single “go-live weekend” is asking the business to accept a risk it has every reason to refuse.
The alternative is the strangler pattern: build the new capability around the old core, move work across one slice at a time, and retire the legacy pieces only when nothing depends on them anymore. The idea is well known. What tends to be missing is the operating detail that makes it work for an insurer. This post covers that detail.
Why “big bang” cutovers fail in insurance
Core replacements that try to switch everything at once tend to stumble on the same insurance-specific problems:
- Policies live for a term. An in-force policy written on the old system carries its rating, forms, and endorsement history with it. Converting it mid-term means re-creating every one of those decisions in a new system, exactly.
- Claims outlive policies. A liability or marine cargo claim can stay open for years. Its reserves, payments, recoveries, and correspondence have to stay intact and auditable through any migration.
- Money must reconcile to the cent. Premium, commission, reserves, and bordereaux feed statutory reporting and capacity-provider reporting. A cutover that leaves finance unable to reconcile is a failed cutover, however good the screens look.
- Many parties depend on the core. Brokers, TPAs, reinsurers, payment providers, and regulators all consume data from it, often through interfaces nobody has documented for years.
A zero-downtime approach accepts these constraints instead of fighting them.
Step 1: Put a routing layer in front of the core
The strangler pattern starts with a seam. Every request that today goes straight to the legacy core (a quote request, an endorsement, a claim lookup, a payment) is routed through a layer you control. At first that layer simply passes everything through to the old system. Nothing changes for users.
Once the seam exists, you can decide request by request where work should go. A new-business quote for one product in one state can go to the new platform while everything else continues to hit the legacy core. If something goes wrong, the route flips back.
This routing layer is not glamorous, but it is the single most important piece of the program. Without it, every migration step is a one-way door.
Step 2: Slice by business cohort, not by technical component
The tempting way to plan a migration is by system module: “rating first, then billing, then claims.” In practice, the safer slices are business cohorts, groups of work that can be moved end to end:
- New business before renewals. Writing new policies on the new platform avoids conversion entirely for that cohort.
- Renewals at the renewal date. Rather than converting in-force policies mid-term, migrate each policy when it renews. Over one policy cycle, most of the book moves across naturally.
- One product, one territory, or one distribution channel at a time. A single program or a single broker segment makes a contained first cohort.
- New claims on the new platform, open claims run off on the old one. Long-tail claims can stay where they are until they close, with read access from the new environment.
Each cohort should be small enough to roll back and large enough to prove something.
Step 3: Keep both systems in sync while they coexist
During coexistence, some data has to exist in both worlds. Party and policy reference data, payment status, and claim notes are the usual candidates. The goal is a clear system of record for each data domain at each point in time, with change events flowing to the other side.
Practical rules that help:
- Write once, publish everywhere. Each domain has exactly one system that accepts writes; others subscribe.
- Make sync idempotent. If a message is replayed, it must not create a duplicate endorsement or a second payment.
- Track lineage. Every migrated or synchronized record should carry where it came from and when, so auditors and claims handlers can trace it.
Step 4: Run in parallel and reconcile before you trust
Before a cohort’s work leaves the legacy core for good, run it through both systems for a defined period and compare outcomes:
- Do rated premiums match, or differ only where the new rating logic is supposed to differ?
- Do generated documents carry the right forms and wording?
- Do commission, tax, and fee calculations reconcile?
- Do reserve and payment postings produce the same ledger outcome?
Differences should be expected, explained, and signed off by the business owner, not quietly accepted. Shadow mode is where AI-assisted comparison earns its keep: models can review large volumes of paired outputs, cluster the differences, and point people to the handful of patterns that matter instead of thousands of individual mismatches.
Step 5: Design rollback as a normal operation
Every cutover step needs a rollback plan that has been tested, not just written down. That means:
- Routing can return a cohort to the legacy core in minutes.
- Transactions created on the new platform during the cohort’s window can be replayed into, or reconciled with, the old system.
- Someone has the authority to call a rollback, and the criteria for doing so are agreed before the cutover starts.
Teams that rehearse rollback tend to need it less, because the rehearsal itself exposes the weak points.
Step 6: Respect the insurance calendar
Zero downtime is also about timing. Avoid moving cohorts during quarter-end and year-end close, peak renewal dates for the affected book, major reinsurance renewal periods, or the height of catastrophe season for property lines. Agree a change calendar with finance, underwriting, and claims leadership, and treat those windows as fixed constraints.
Where AI fits in a zero-downtime program
AI is not a substitute for migration discipline, but it removes a lot of manual effort that usually slows these programs down:
- Interface discovery. Reading legacy batch files, copybooks, and integration logs to build an inventory of who consumes what from the core.
- Document and form mapping. Comparing legacy policy forms and endorsements with new templates to flag wording gaps.
- Data quality triage. Finding duplicate parties, inconsistent addresses, and incomplete histories before they are migrated.
- Reconciliation support. Explaining why paired outputs differ, with links to the underlying records, so business owners can sign off quickly.
Every one of those uses should keep a person accountable for the decision, with the evidence attached.
Illustrative example: a specialty carrier modernizing its marine book might start by writing new cargo business for a single broker segment on the new platform, renew existing cargo policies onto it as they come due, and leave open claims on the legacy system to run off. After one policy cycle, the legacy core handles only run-off claims for that line, and nobody outside the project team noticed the switch.
How to know it’s working
Track a small set of signals from the start:
- Unplanned downtime attributable to the program (target: none)
- Percentage of transactions routed to the new platform, by cohort
- Reconciliation breaks per cohort and time to resolve them
- Rollbacks executed and their causes
- Legacy interfaces retired against the inventory
- Broker and claimant complaints linked to the change
When these trend the right way, the program is building credibility with every cohort, and the final legacy decommissioning becomes an administrative step rather than a leap of faith.
The real promise of zero downtime
The strangler approach does not make modernization fast. It makes it safe, reversible, and continuous, which is what lets it start this quarter instead of after the next budget cycle. The business keeps writing, servicing, and paying claims. The core changes underneath it, one slice at a time.
Plan a modernization path your business can live through. Take the Aketud Insurance AI Readiness Assessment to map your core dependencies, pick a safe first cohort, and identify where AI can take manual effort out of migration and reconciliation.
