Modernizing a Legacy System Without Breaking It

Case study in the series behind How I Whiteboard Product Interviews Live. Method: The Live Whiteboard Method.

The setup, anonymized, was a federal defense modernization engagement. The system was a fifteen-to-twenty-year-old classified incident-management application: self-built, heavily customized, mission-critical, with competing stakeholder priorities and several required external integrations. The kind of system where "let's just rebuild it" is the most dangerous sentence in the room, because people depend on it working today, every day, while you change it.

Here is how I approached it on the board.

I opened against a recognized rubric, and scored myself honestly

Before any solutioning, I anchored to a shared vocabulary by opening against a recognized rubric: the SVPG product competencies, grouped as Product Knowledge, Process, and People. Then I self-scored against them, out loud, and did the thing most people will not: I tagged my weaker domain areas as "situational" instead of inflating them.

In a defense context, that honesty is the credibility move. Claiming deep classified-domain expertise I did not have would have cost trust instantly. Saying "here is where I am strong, here is where I would lean on your operators" signals that I know the canon and that I am safe to hand a mission-critical system to. The rubric also gives everyone in the room the same words, which is half the battle before you have solved anything.

I separated pains from reframes on a discovery board

The next board was problem discovery, and I kept two things visibly apart. On one side, the pains, in the operators' terms: slow queries, progress lost when users forget to save, a growing backlog of tickets. On the other side, the How-Might-We reframes those pains became: "how might we meet operators where they are actually working?"

Keeping pains and reframes in separate columns stops the classic failure where a complaint and a half-baked solution get tangled together. First name the hurt. Then, deliberately, turn it into an opening.

I triaged the system I inherited instead of tearing it down

You learn a lot about someone by how they treat a legacy system. The lazy instinct is to declare it all garbage and start over. So I triaged the existing application on the board, marking what works with a check and what is broken with an x. "Generate reports" got a green check, it works, keep it. "Progress lost when users forget to save" got a red x. Reading the system for what to keep, not only what to replace, is what protects the operators who rely on it and what earns you the right to change it at all.

I framed the big decision out loud

Then the fork that actually mattered, named explicitly on the board rather than buried in narration: build a separate new app, or surgically adjust the live one without disrupting day-to-day operations. Greenfield versus strangler. This is the decision the whole engagement turns on, and naming the tradeoff out loud is a higher-altitude move than picking any individual feature. In a mission-critical context the constraint "without disrupting day-to-day operations" is not a preference, it is the boundary the entire approach has to respect, and putting it on the board makes that non-negotiable visible to everyone.

I sequenced it as a five-phase process map

The plan took the shape of a process map with five phases, so a stakeholder could see the whole arc from discovery to delivery:

1. Scoping and goals: agree on what we are solving and what success means.
2. Research and discovery: event storm, journey maps, service blueprint, to understand the real workflow before redesigning it.
3. Solution framing and validation: design studio, lo-fi wireframes, design-and-dev pairing, a domain-driven re-architecture map, and an outcome-based roadmap.
4. Preparation and development: MVP scope, test-driven development, retros.
5. Release and adoption: go-to-market, feedback loops, and product instrumentation and observability so we know it is working in production.

That spine shows you are not going to disappear into a rewrite. You are going to discover, validate, build, and watch, in order, with the lights staying on the whole time.

The human close

The board ended the way I end most of them, with a sticky that is not a deliverable: "Celebrate. Keep going." Mission-critical modernization is a long grind, and naming the human reality of that, that you mark the wins and you do not stop, belongs on the board too.

What the board was really showing

No flashy redesign, just judgment someone could follow:

• Anchor to a shared rubric and score yourself honestly, including the gaps.
• Separate pains from reframes so complaints become openings, not tangled solutions.
• Triage what exists for what to keep, not only what to tear out.
• Name the big tradeoff out loud and make the real constraint non-negotiable.
• Sequence the whole arc from discovery to observability, with operations protected throughout.

In a mission-critical legacy context, judgment shows up as naming the tradeoff and protecting day-to-day operations, not as a flashy redesign. The board that respects the system already running is the one I would trust to change it.

If you want to see this live, bring me a real product problem and watch me whiteboard it end to end: that is the Watch Me Think offer. To practice the method yourself, the Whiteboard Prompt Translator scaffolds the six frames from any prompt.