Legacy System Modernization

Before You Modernize a Legacy System, Understand What You’re Replacing

It’s a pattern that repeats across government IT, almost regardless of agency: a platform built years ago on whatever CRM or low-code tool was standard at the time, carrying years of business rules, workflows, and tribal knowledge that live nowhere else — not in a document, not in a diagram, just in the system itself and the handful of people who’ve supported it the longest. Then a modernization effort kicks off, someone picks a shiny new stack, and the actual current-state behavior of the legacy system gets treated as a footnote instead of the specification it actually is.

Often, that’s not because anyone building the original system got it wrong — it’s success outrunning scope. A system designed for one internal audience and one workflow works well for exactly that. Then it works well enough that more people start relying on it: more programs, more user types, more use cases than it was ever built to carry, until a platform designed for a narrow internal purpose is being asked to serve a much broader set of users than it was ever architected for.

That’s our best read on part of what’s happened with SQUARES over time — built for VA caseworkers working internally, and stretched over the years to also serve an increasingly broad set of external grantee users and use cases it wasn’t originally scoped for.

VA’s effort to modernize SQUARES — its eligibility lookup platform supporting homelessness, suicide-prevention, and legal-services programs for Veterans — is a live example of exactly this challenge, and a useful case study for anyone facing a similar migration: retire a legacy Salesforce-based system, integrate cleanly with a modern platform, and put a genuinely usable interface in front of the people who rely on it, without losing anything that mattered in the old one.

We’ve been spending real time on that exact problem, and three things have stood out enough that we think they’re worth sharing broadly — not just with people working on this specific system.

Getting the legacy system right isn’t optional.

Every platform like this has years of accumulated business rules, workflows, and institutional knowledge baked into it — often undocumented anywhere else. Skipping straight to “let’s build something modern” without first understanding what the current system actually does is how migrations quietly lose functionality nobody notices until a user runs into it.

The right approach is to treat that legacy logic as a specification to extract and document, not an obstacle to route around. AI, used deliberately, is a genuinely good accelerant for that kind of extraction work, as long as a person reviews what comes out of it before it’s trusted.

Modern platforms reward teams that learn their actual integration patterns.

Whether it’s VA’s Lighthouse platform and its Benefits Discovery Service API, or any other agency’s equivalent developer platform, the teams that succeed are the ones who go build against the real API contract early — a mock service, a sandbox, anything that forces them to learn the actual shape of the data instead of assuming it.

And when AI shows up inside the running application itself, the bar should be the same one VA has set for its own systems: rules decide, AI explains the reasoning in plain language, and anything uncertain gets flagged for a person to check. That’s a good standard regardless of which agency you’re building for.

The interface is not the last 10% of the project.

For the person actually waiting on an answer — a caseworker at an intake desk, a family member trying to understand what’s available, someone under real pressure and short on time — the interface is the entire product.

If the answer doesn’t arrive in under a minute, in plain language, on whatever device they happen to have in hand, nothing else about the system matters. Mobile-first, accessible design has to be a first-class requirement from day one, not a polish pass at the end.

None of this is theoretical for our team. We’ve been building a working proof of concept around exactly this problem — extracting logic from a Salesforce-style system, standing up a mock recommendations API against a real API contract, and designing a mobile-first eligibility experience — because we’d rather learn the hard lessons on our own time than on a client’s.

We’ll keep sharing what we learn as this work continues. If modernizing a legacy benefits or eligibility system is a problem you’re wrestling with too, we’d welcome the conversation.