Insurance

The system
of record can't
afford to drift.

Policy administration and claims run on stacks built decades ago. We modernize them one slice at a time — with data integrity and behavior parity proven before any slice carries a live policy.

Data-integrity gate Audit trail by default Regulated & air-gapped supported
Typical legacy estate
COBOL
Policy admin
Often on the mainframe
RPG / AS-400
Claims
IBM i (System i)
DB2
Data store
Mainframe system of record
Parity gate Data integrity checked
The estate

The stacks insurance runs on.

Across the industry, policy administration and claims systems tend to share a lineage: COBOL on the mainframe, or RPG on AS/400 (IBM i), with the system of record sitting in mainframe DB2. These platforms have run reliably for decades — that is exactly why they are still there, and why replacing them wholesale is so dangerous. They encode rating logic, reserving rules, and claims workflows that were never fully documented anywhere else. What replaces them is not another packaged policy-admin suite. The rating and reserving logic, the claims workflows, and the system of record itself move onto a modern language and data platform where the rules are finally explicit and testable instead of buried in undocumented COBOL — deployable in whatever regulated or air-gapped environment a carrier's compliance posture demands.

The pressure

What makes insurance unforgiving.

The constraints here are not preferences — they are obligations. A modernization program has to honor all of them at once.

01
Audit and compliance continuity
Examiners expect the same answers before and after a change. A modernization that cannot show its work is a finding waiting to happen — traceability has to be built in, not bolted on.
02
Actuarial continuity
Reserving, rating, and reporting all depend on calculations that have to keep producing the same result. A silent drift in a rounding rule or a rate table is the kind of error that surfaces quarters later.
03
Data integrity above all
Policy and claims records are the system of record. A migration that loses, reorders, or subtly mutates data is worse than no migration at all.
04
Aging stacks, retiring specialists
The people who wrote the policy engine are retiring, and the next generation is not learning COBOL or RPG. The institutional knowledge walks out the door with them.
Why parity-first

Proof before promotion — especially on data.

A big-bang cutover asks an insurer to trust that a new system reproduces decades of policy and claims behavior exactly, all at once, on go-live night. That is a bet no carrier should take. Slice-by-slice is the alternative.

Shadow first
Under shadow traffic, every slice is run against the legacy until output, behavior, and the state-by-state corner cases all match. Nothing carries a live policy until it has been proven against the system it replaces.
Data-integrity gate
The parity gate includes an explicit data-integrity check — records are validated for completeness and correctness before a slice is promoted, because in insurance the data is the product.
Rollback ready
Traffic shifts gradually behind a strangler facade. If a slice diverges, it rolls back instantly and the legacy keeps serving. A failure is a ticket, never an outage.
In insurance the data is the product. A slice is promoted only when its data integrity is proven, not assumed.
— The data-integrity gate
The target

Built for ten more years.

The modern target is shaped around the carrier, not a vendor's roadmap. The rating, policy-admin, and claims services run on a modern language and a data platform built for the volume and auditability insurance demands, with observability by default so every underwriting and claims decision can be traced back to an explicit rule. The result is modular and testable, horizontally scalable, and built on a talent-friendly stack the next generation of engineers actually wants to work in. It deploys wherever compliance requires — public, private, hybrid, or air-gapped — so the modern system stays inside the carrier's regulatory boundary, every state included.

Where the advice stops
Slice-by-slice only works when a behavior can be isolated and proven against the system it replaces. A rating or underwriting engine whose rules vary state by state and were never written down — where there is no documented expected output to test a slice against, and actuarial continuity has to hold across every jurisdiction at once — is a harder fit, and we flag it in Discovery rather than once the work is underway. Naming the cases the method does not fit is part of the method. Read the full approach →