Home/Case Studies/Case study
Case study · Insurance

Modernizing a claims-processing core: a phased migration

A 20-year-old claims engine, decomposed into services over five slices, with an agent handling first-pass document review by the final phase.

About this case study

This is an illustrative, composite engagement pattern reflecting how we structure claims-modernization work — not a named client account. Details have been generalized to protect confidentiality; the approach and figures are representative of engagements of this shape.

The starting point

The client, a regional property and casualty insurer, was running its core claims engine on a monolithic system built in the early 2000s. It worked — claims got processed — but every change carried risk that was out of proportion to its size, adjusters spent a large share of their day on manual document intake rather than judgment calls, and the system had no path to using AI without a full rewrite nobody wanted to greenlight.

Industry-wide, this is a familiar starting point: as recently as two years prior, most insurers had no meaningful AI in their claims workflow at all. Full-scale AI adoption in the sector has since moved from roughly 8% of insurers to over a third — but the insurers making that jump successfully were rarely doing a rewrite. They were extracting one workflow at a time.

Why not a full rewrite

The claims engine touched underwriting data, a document management system, three external adjuster tools, and a regulatory reporting pipeline. A full rewrite would have meant re-certifying all of it at once, with the business unable to process claims during any extended cutover. We proposed a strangler-pattern migration instead: a routing façade in front of the legacy system, with new services carved out one bounded workflow at a time.

The five slices

  1. Intake & triage. The first and lowest-risk slice — routing new claims to the right queue based on type and severity. Low consequence if something went wrong, high visibility if it went right.
  2. Document ingestion. Structured extraction from uploaded claim documents, replacing manual re-keying. This slice built the data pipeline the later AI work would depend on.
  3. Adjuster workspace. A rebuilt case view pulling from the new services rather than the legacy database directly — the point where adjusters started feeling the change.
  4. Payment & settlement routing. Higher-stakes, and deliberately sequenced fourth — by this point the façade and rollback process had been proven three times over.
  5. Agent-assisted first-pass review. An agent that reads incoming documents, flags missing information, and drafts a triage recommendation for adjuster approval — never issuing a determination on its own.

Where the agent fits — and where it doesn't

The fifth slice was deliberately last. Document review was the highest-leverage place for an agent to help, but also the one place where a confidently wrong output does real damage to a claimant. The agent's output is a recommendation with cited evidence, never a decision; every claim above a low-dollar threshold still gets adjuster sign-off before anything moves. That boundary was set in the design phase, not discovered after an incident.

What the agent does not do

It doesn't approve or deny claims, doesn't communicate directly with claimants, and doesn't touch payment amounts. Its job is to make the adjuster's first ten minutes on a claim take two.

Illustrative outcomes

Modernized claims workflows of this shape typically see first-pass review time drop sharply — agentic document review commonly cuts the manual review step by roughly two-thirds — with overall cycle-time improvements in the 50–70% range once the full workflow is live. For this engagement, adjusters regained a meaningful share of their day for judgment calls rather than data entry, and the legacy system's remaining footprint shrank to reporting and archival access ahead of a planned decommission.

The win wasn't a faster claims engine. It was adjusters spending their time on the calls that actually need a person.

What we'd tell a team starting this today

  • Sequence the agent-assisted slice last, after the routing façade and rollback process have already been proven on lower-stakes work.
  • Build the data pipeline (document ingestion) before the AI use case that depends on it — don't try to do both in the same slice.
  • Set the human-approval boundary in writing before the agent slice starts, not after the first edge case surfaces.

Looking at a similar claims or policy-administration system? See how we approach legacy modernization, or talk to us about where a first slice might be.

Have a claims or policy system like this one?

Let's talk through where a first slice would sit.

We'll be direct about what's realistic in the first quarter.