The strangler-fig migration is the only one that survives benefits-system politics

Every state benefits agency we have worked with has the same scar tissue. Somewhere in the building's history is a project that promised to replace the legacy eligibility engine on a date certain, missed the date by 18 months, blew through the appropriation, and either limped to a half-functional production state or was quietly canceled. The vendor moved on. The agency carries the bill.

The pattern is not specific to one agency or one vendor. It is the pattern of the flag-day cutover.

Why the flag-day cutover keeps failing

Three reasons, in escalating order of severity.

Eligibility logic is encoded in case-law-shaped exceptions, not in the policy manual. The policy manual describes what the program should do. Twenty years of caseworker behavior, court decisions, and bureau guidance describe what the program actually does. A rewrite that codes from the manual produces an engine that fails fast in production because tens of thousands of unwritten rules are missing.

Renewal cycles are unforgiving. A state Medicaid agency processes millions of renewals per year on a rolling cadence. Any week the new engine is wrong is a week of legitimate enrollees being mistakenly dropped. The political tolerance for that is approximately zero, and the legal exposure is asymmetric.

The legacy system contains the only operational source of truth. The historical claim record, the verification artifacts, the eligibility audit trail — they all live in the legacy. You cannot turn the legacy off until the new system can answer questions about decisions the legacy made. That alone is a multi-quarter project.

The flag-day cutover assumes you can do all three at once. You can't.

Strangler-fig, applied to eligibility

The pattern, originally named by Martin Fowler in 2004 and applied to a hundred enterprise replatformings since: a new system grows alongside the legacy, intercepting and replacing functionality slice by slice, until the legacy can be cleanly retired. The metaphor is the fig tree that grows around a host and eventually replaces it.

For a state benefits engine, the slices we recommend, in order:

Slice one — reads-only. Stand up a read-only API in front of the legacy that returns case state. Every caller — caseworker terminals, the public portal, the data warehouse — moves to the API. The legacy is now insulated by a contract you control. This takes weeks, not months.

Slice two — renewal-letter generation. Move only the letter-generation step out of the legacy. The legacy still computes the decision. The new system generates the notice, with versioned templates bound to policy text, in a form that satisfies due-process review. This is also the slice where adverse-action quality improves measurably. We have written separately about the disproportionate value of legible adverse-action notices — this slice is where that value is unlocked.

Slice three — re-determination workflow. Migrate the renewal-cycle workflow — the scheduling, the verification requests, the case-worker queue — to the new system. The new system still calls the legacy for the actual eligibility computation. Caseworkers see a modern UI; the engine is untouched.

Slice four — eligibility engine, MAGI population only. Implement the eligibility engine for the simplest population (typically MAGI Medicaid for non-elderly adults) in the new system. Run it in parallel against the legacy for several full renewal cycles, with reconciliation reports surfaced to program-integrity staff. The new engine takes traffic for that population when reconciliation is clean.

Slice five through N — remaining populations. One population per release. Aged, blind, and disabled. Waivers. SSI-linked. Each population brings its own caseworker scar tissue and its own court history. Each gets the same parallel-run reconciliation treatment.

Final slice — read-only legacy. When all populations have moved, the legacy retains only its archival role. The new system reads historical state through the same read-only API that started the project.

Costs and durations the procurement office will not want to hear

A strangler-fig migration of a state Medicaid eligibility engine takes 24 to 48 months. The flag-day cutover that the RFP describes is supposed to take 18 months. The strangler-fig migration finishes; the flag-day migration usually does not.

The strangler-fig migration also produces continuous value. After slice two, the agency has measurably better adverse-action notices. After slice three, caseworkers are working in a modern system. After slice four, the agency has high confidence the new engine can handle the broader population. Each slice is independently defensible to the legislature.

The flag-day cutover produces value only at the end. The procurement office and the program office have to defend a 24-month period of pure spend with no visible improvement. That is the political reality that ends most cutovers.

What we look for in the procurement language

When we review a state RFP for an eligibility-engine replacement, the first thing we read for is the cutover assumption. If the RFP describes a flag-day, we recommend the agency add a phased-migration clause and a parallel-run requirement before issuing. The Vardr Procurement Language Library includes both as standard inserts.

The second thing we read for is whether the RFP requires the vendor to expose the legacy through a read-only API as the first deliverable. Without that, the agency is committing to whichever migration shape the vendor prefers — which is rarely the shape that minimizes risk to the agency.

What Vardr brings

The strangler-fig pattern is not proprietary, and we are not the only people who can run a migration this way. The piece that is specific to us is the operational depth on what makes a benefits-system migration different from an enterprise replatforming — the political constraints, the renewal-cycle pressure, the OIG audit trail, the due-process surface. We bring published methodology, principals through the engagement, and the procurement language to make this shape contract-defensible.

We do not write flag-day proposals. The fastest way to retire a mainframe is to retire it slowly.