v2.0: Modernizing a Claims System Without a Single Day of Downtime

Two engineers, both approaching retirement, were the only people who fully understood how a commercial insurance carrier’s core claims system actually worked, and the carrier had no real plan for what would happen once they left.

Background

The carrier’s claims processing system had been built fifteen years earlier and patched continuously since, handling everything from initial claim intake through adjuster assignment, reserve calculation, and payment processing for a growing book of commercial policies. The original architects were long gone. Only two remaining engineers, both within a few years of retirement, could reliably trace how a change in one part of the system would ripple through the rest of it.

A structure that outgrew its own documentation

The system’s original design documentation described an architecture that, in practice, had been patched around so many times over fifteen years that the actual behavior and the documented behavior had meaningfully diverged. Business logic for edge cases, a specific state’s regulatory requirement, a particular claim type’s approval workflow, existed in the code but nowhere in writing, understood only by the two engineers who had personally added each patch over the years.

Documenting real behavior before changing anything

Before writing a line of new code, we spent six weeks working directly alongside the two remaining engineers, tracing the system’s actual behavior against real historical claims rather than its original design intent. Every piece of business logic slated for the new system got validated against the legacy system’s actual output on real claims data, which surfaced several pieces of undocumented logic, including one state-specific reserve calculation rule, that would have been silently lost in a less careful migration.

Running two systems in parallel until the hard problems surfaced

Rather than a single cutover date, we ran the new claims intake service alongside the legacy system for six weeks, routing a growing share of new claims to the new service while the legacy system remained the system of record, comparing outputs on every claim that passed through both. Discrepancies got investigated and resolved during this parallel period, which meant the actual transition, when it happened, was uneventful precisely because the difficult problems had already been found and fixed while the legacy system was still there as a safety net.

Results

All 40,000 active claims migrated to the new system with zero days of processing downtime, the legacy mainframe interface was fully decommissioned, and the carrier now has a claims system that new engineering hires can actually read and extend, not one that depends on two specific people’s institutional memory.