Rebuilding a 12-year-old claims platform while claims kept flowing

The challenge

The client's core platform ran claims intake, correspondence, payments and pharmacy contracts. It had been in use for more than 12 years. Built in PHP on a Firebird database, it had become hard to change, hard to hire for and hard to connect to anything new.

Three risks made a rebuild feel dangerous:

• Claims could not stop. Any downtime meant delayed payments and unhappy customers.
• Years of business rules lived only in the code. Nobody wanted to find out which ones mattered by breaking them.
• The data had to move intact. Every claim, payment and contract had to arrive in SQL Server without loss.

How we rebuilt it

We planned the work so the business never had to bet on a single big switch-over.

1. 1Requirements firstWe worked from a detailed requirements specification, screen by screen and rule by rule.
2. 2Three streamsScreens and forms, background jobs and business rules, and data migration ran as separate streams, each tested on its own.
3. 3Sprints with the client's teamTwo-week sprints. The client owned product decisions and joined our code reviews. Our QA automation engineers tested every sprint.
4. 4Testing in layersAcceptance testing on each part of the system, then a full month of end-to-end testing.
5. 5A month of parallel runningOld and new systems ran side by side so the team could compare results before cutover.
6. 6Cutover and roll-out supportTwo months of support after go-live, with contingency built into the plan.

The results

Claims now move in minutes, and the platform runs on a supported .NET and SQL Server stack the team can change, instead of an aging PHP and Firebird system.

• 2 to 5 min to ingest claims, down from about 1.5 hours
• 30 min to allocate, down from about a week
• 3+ years with the same team, and counting

Drag to compare. Illustration with sample data; no client screens are shown.

The rebuild was only the start

The client kept the same team after launch. Since then we have:

1. Phase 2Added new modules over 8.5 monthsA collections work queue, accounts-payable and liability calculations, bulk pharmacy-contract processing and automated document intake.
2. DataStandardized response codesReplacing vague “Other” notes with codes that make reporting reliable.
3. PaymentsAutomated payment matchingFor a pharmacy benefit manager that sends electronic payment files (835s), replacing manual work for that payer.
4. .NET 10Upgraded from .NET 7 to .NET 10In phases, with a monitoring window after each environment.
5. AIBuilt AI document processing into the platformPiloted on 212 real documents (820 pages) before the full build.

Read more about intelligent document processing and the .NET upgrade.