Moving Claims Logic Off the Mainframe Without Losing What It Knows

In a claims system that has been running for decades, the code is the specification. Not a representation of it, not a derivative of it — the thing itself. Every requirements document ever written for it describes an intended change at a moment in time. The code describes the accumulated result of thousands of those changes, including all the interactions between them that nobody documented because nobody anticipated them.

That single fact determines which modernization approaches can work and which cannot. It is also the fact most often skipped, because acknowledging it makes the estimate larger.

Why rewriting from requirements fails

The plan sounds responsible: gather the requirements, write a clean implementation, retire the old system. The problem is that you are not reimplementing a specification. You are reimplementing your reading of a specification that was never assembled, from documents that each describe a delta against a system state that no longer exists.

What gets lost is never the main path. The main path is well understood and easy to rebuild. What gets lost is the accumulated periphery:

Effective-dated policy branches going back decades, because a claim with old dates of service must still be adjudicated under the rules that applied then.
Jurisdiction- and provider-specific handling that exists because the real world is not uniform.
Sequence dependencies between edits, where edit B is only correct because edit A already fired and changed the claim.
Deliberate workarounds encoding a real operational exception, indistinguishable in the source from a bug.

In a system adjudicating claims at national volume, a reimplementation that is right 99% of the time is not a success with a rounding error. It is a system that mis-adjudicates an enormous number of claims belonging to real people. The edge cases are the asset.

The four approaches, honestly

Rehost. Move the workload, keep the logic byte-for-byte. Preserves behavior perfectly because it is the same logic. Buys infrastructure economics and nothing else — no agility, no reduction in the scarce-skills problem. A legitimate first step that is frequently oversold as a last one.
Automated transpilation. Machine-translate COBOL or PL/I into a modern language. Structure survives; so does every idiom that made sense only in the source language. The result is COBOL written in Java, which nobody wants to own. The problem moves rather than resolving.
Rewrite from requirements. Highest ceiling, and the failure mode described above.
Encapsulate and strangle. Put a stable interface in front of the legacy engine. Route new capability to new services. Migrate one slice at a time, running old and new in parallel until the new one is proven. Looks the slowest. It is the only one of the four with a safe rollback available at every single step.

The technique that makes any of it safe

Whichever path you pick, the thing that converts hope into evidence is behavioral equivalence testing at production scale. Replay historical claims through both the incumbent and the replacement, and diff the results.

Not just the paid amount. Every edit that fired, every status and location transition, every reason code, every intermediate value that a downstream consumer might depend on. Two systems that agree on the payment amount and disagree on which edits fired are not equivalent; they have agreed by coincidence and will diverge on the next claim.

The population matters as much as the comparison. A test suite exercises the cases someone thought of. A replay of millions of real historical claims exercises the cases the last thirty years actually produced — including the ones no living engineer knows about. Every difference the replay surfaces is either a bug in the new implementation or a requirement nobody had written down. Both are findings, and the second kind is the reason to do this at all.

This also gives you a defensible definition of done, which rewrite projects otherwise lack. Done is not “the tests pass.” Done is “we replayed this population and the outputs match, and every difference is explained.”

The part nobody budgets for

Behavioral replay tells you what the system does. It cannot tell you why. For that you need the people who were in the room, and that population is shrinking on a schedule set by human careers rather than project plans.

An engineer who can say “that edit exists because of a specific policy change in the nineties, and here is the case it was protecting against” is providing information that exists nowhere else. Not in the code, which shows the mechanism and not the motive. Not in the documents, which describe the change and not the reasoning behind the shape of it. Capturing that is a migration activity with a real deadline, and it belongs in the plan as a line item rather than as an assumption.

What to preserve deliberately

Effective dating, including the ability to adjudicate under superseded rules indefinitely.
Determinism. The same claim with the same inputs must produce the same output every time, and the same output it would have produced years ago.
The audit trail. Not merely what was decided, but which rules participated in deciding it.

Those three are what make a claims system trustworthy, and they are easy to lose in a rewrite because none of them show up in a feature list.

The goal is not to escape what the mainframe knows. It is to move that knowledge somewhere it can be read, tested, and changed — without pretending, on the way, that it was never there.