Modernizing government legacy systems without a big-bang replacement

Why big-bang replacement is the wrong default

Legacy systems of record still run essential programs — benefits, licensing, permitting — while residents and staff expect services that work on a phone and meet accessibility law. A full replacement forces a choice between two bad options: freeze the program while the new system catches up, or run two systems in parallel and hope they agree. Neither is necessary as a default starting point.

What incremental modernization actually looks like

• Wrap or incrementally replace the aging system of record, sequenced so the program it runs keeps operating throughout — not a single cutover date.
• Integrate before replacing. Connecting the legacy system to newer platforms with documented, monitored interfaces often removes the pressure to replace it immediately, which is usually the cheaper sequence.
• Sequence around funding and procurement cycles, not against them — modernization work has to fit the same budget and documentation requirements the program already operates under.
• Plan the eventual handover from day one, so continuity doesn't depend on the team that built the replacement staying involved indefinitely.

The role of integration

A large share of what looks like a "replace the mainframe" problem is actually a data-silo problem: agencies hold overlapping records in systems that were never designed to exchange information, which makes reporting slow and manual. Systems integration — connecting the legacy system to a statewide or federal platform, or to other agency systems — often resolves the most urgent pain without touching the system of record itself.

Where to start

• Identify the single workflow that's most manual today (paper hand-offs, re-entry between systems) — automation there proves the approach before a larger program starts.
• Stand up integration between the system of record and the platform residents or staff actually interact with, rather than rebuilding both at once.
• If a previous vendor built the current platform with no documentation, start there — a runbook and architecture map is often the highest-leverage first step, independent of any replacement decision.

Accessibility and continuity along the way

None of this sequencing is an excuse to defer accessibility — Section 508 and WCAG 2.2 AA obligations apply to whatever's in front of a resident today, not just the eventual end state. Semantic markup, keyboard operability and assistive-technology testing are part of each incremental release, with findings tracked like any other defect, rather than saved for a final audit.

Next step

Describe the system, the program it runs, and the constraint you're planning around — funding cycle, procurement vehicle, an upcoming compliance deadline. We'll come back with what we'd sequence first and what we'd deliberately leave alone for now.