Most legacy government systems don't fail because the old code is bad. They fail because replacing them is treated as one enormous event — a multi-year program that ends in a single weekend cutover everyone dreads. That model is why so many public-sector modernization projects run over budget, slip their timelines, or get cancelled outright. There is a less dramatic way to do it.
Why legacy modernization stalls
A mainframe-era system that has run for twenty years has absorbed two decades of rules, exceptions, and undocumented edge cases. Nobody on staff remembers all of them, and the original authors are usually gone. A team that promises to rebuild the whole thing and flip a switch is promising something it cannot safely deliver: the moment the new system goes live, every undocumented rule it missed becomes a production incident affecting real constituents.
The other failure mode is the discovery phase that never ends. Agencies spend the first year producing requirements documents for a system whose behavior is already encoded in working software. By the time the documents are signed, the budget for building is gone.
Start with an audit, not a rewrite
The first deliverable should be a map of the system you actually have: its data flows, its integrations, its real sources of truth, and the corners that are riskiest to touch. This is reading the code and the data, not just the diagrams. The output is a written assessment of what is solid, what is fragile, and what to do in what order — specific enough that any senior engineer could execute it.
The strangler pattern: replace route by route
Instead of building a replacement in parallel and cutting over all at once, the strangler pattern wraps the legacy system and migrates one capability at a time. New functionality is built in the modern system; existing functionality is moved across route by route. The two systems run side by side, their outputs reconciled automatically, until the legacy system has nothing left to do and can be retired.
The payoff is that reporting never goes dark and risk is bounded. If a migrated capability misbehaves, the blast radius is one route, not the entire agency. Constituents keep getting served the whole time.
Accessibility and security are not phase two
Public-sector software has to be usable by everyone and defensible under audit. That means WCAG 2.1 AA targeted from the first sprint rather than retrofitted before launch, and security folded into delivery — TLS everywhere, encryption at rest, least-privilege access, and audit logs — not bolted on at the end. Treating either as a final-phase task is how projects end up with an accessibility remediation bill larger than the original build.
What this looks like in procurement
Incremental modernization fits procurement better than a monolithic program. It can start as a 6–12 week pilot on a single high-value capability, prove the approach with working software, and then expand under the same or a follow-on vehicle. Agencies can run it directly under their contracting authority, or have a small engineering team work as a subcontractor under a prime that holds the relevant vehicle.
Kevadia is a New Jersey-based LLC, certified by the State of New Jersey as both an SBE and an MBE and registered on SAM.gov, and works with agencies on exactly this kind of incremental modernization.