Refactoring a Legacy Government React Codebase Without a Rewrite

"Rewrite it" is the instinct every engineer has looking at an unfamiliar legacy codebase. On a government platform supporting live departmental workflows and public services, it's also not an option — there's no maintenance window long enough, and no appetite to re-litigate requirements that took years to settle the first time.

The actual constraint

Every departmental workflow module had to keep working, for every existing integration, on every day of the refactor. That ruled out any change that wasn't backward-compatible at the module boundary — the API a module exposed to the rest of the app had to hold steady even while its internals changed.

How the refactor actually happened

• Refactored one component tree at a time, verified against its existing consumers before moving to the next — never a big-bang change across the whole app.
• Kept the existing Redux architecture rather than introducing a second state-management pattern alongside it, which would have made the codebase harder to reason about mid-refactor, not easier.
• Used peer code review as a second set of eyes specifically for "does this still behave identically" — not just style, given how easy it is to introduce a subtle regression while refactoring code you didn't originally write.

The payoff

This is the same refactor that produced the 30% page load improvement — but the speed win was a side effect. The actual goal was a codebase later changes could move through safely, on a platform where "safely" isn't optional.