What Nobody Tells You About Migrating a Legacy Government System

There's a particular kind of quiet that happens right before a government system migration kicks off. Everyone's been briefed. The timeline is aggressive. The stakeholders are cautiously optimistic. And somewhere under all of that, you can feel the weight of every workaround, every undocumented process, and every user who has spent the last decade learning exactly which buttons to click in which order to make a broken system do what they need.

That quiet is where my work usually begins.

Over the past couple of years, I've been embedded in a migration that took a legacy HR case management platform — one that had been running on institutional memory as much as actual software — and moved it onto Salesforce. Nine months. Compressed timeline. Real users with real work to do who couldn't afford to lose productivity while we figured things out.

Here's what I actually learned.

The legacy system is not the problem. The legacy logic is.

When you first look at an old government system, it's easy to fixate on the interface. The tiny fonts. The 14-step workflows. The form fields that seem to exist for no reason. And yes, those things need to change. But the real work is understanding why everything is the way it is.

Almost every clunky pattern we found had a story behind it. A field that looked redundant was capturing a distinction that mattered legally. A workflow that seemed circular existed because two different teams had negotiated a handoff nobody documented. The system wasn't broken so much as it was encrusted — layers of adaptation built up over years by people trying to do their jobs.

Before we redesigned anything, we had to excavate. I spent time sitting with users just watching them work, asking the dumbest question I could: why do you do it that way? Those conversations were more valuable than any technical specification doc I was handed.

Baselining isn't optional. It's your entire argument.

One of the best decisions we made early was establishing usability baselines before a single pixel moved. We ran task-based tests against the old system — timing completions, logging errors, capturing confusion points — not because we needed to prove the old system was bad (everyone already knew that), but because we needed a benchmark to measure against later.

That data became everything. When stakeholders pushed back on design decisions, we had receipts. When leadership wanted to know if the migration was actually delivering value, we could show them: case creation that used to take 12 minutes now takes 4. UI findability improved by more than half. Those numbers didn't come from nowhere — they came from the decision to do the boring, unglamorous work of measurement before the exciting work of redesign.

Users will protect a bad system if change feels threatening.

This one surprised me the first time, and then it kept surprising me. People who complained loudly about the old system were sometimes the most resistant to the new one. Not because they liked the old system — they didn't — but because they knew it. They had mastered its quirks. They had built shortcuts. And now we were asking them to become beginners again.

Change management and design are not separate disciplines in a migration like this. How you introduce new workflows matters as much as what those workflows are. We learned to frame changes in terms of the old system: "you used to click here, now it's here and here's why." We learned to involve skeptics early, because skeptics catch things optimists miss. And we learned to treat every complaint during UAT as a gift — not an obstacle, but a signal.

The handoff is never really over.

There's a myth in technology projects that you cross a go-live threshold and the work is done. In reality, go-live is just when the real feedback starts arriving at scale. Users encounter edge cases your testing didn't cover. Workarounds re-emerge. New institutional memory starts forming around the new system, for better or worse.

The projects I've found most satisfying are the ones where we built in a feedback loop that outlasted the launch. Not a formal post-mortem, but an ongoing relationship — a channel for users to surface issues, a rhythm of reviewing what's breaking, a commitment to iteration that doesn't require spinning up a whole new project to act on small improvements.

Legacy systems don't get replaced. They get transformed. And that transformation only sticks if someone is paying attention after the ribbon is cut.

I don't know that any of this is groundbreaking. But it's what I've actually lived, in a compressed timeline, on a real project, with real people depending on the outcome. The unglamorous truth about government tech modernization is that the design work is maybe 30% of the job. The rest is listening, translating, advocating, and building enough trust that people will follow you somewhere unfamiliar.

That's the work. And honestly? It's my favorite kind.