Rewrite or Refactor? How to Modernize a Legacy Application Without Stopping the Business

It's Thursday afternoon, and someone in the planning meeting says it: "We can't release on Friday. Nobody wants to touch that part of the system."

If you've heard that sentence at your company, you have a legacy system. Not because it's old, but because people are afraid of it.

That fear usually leads to one of two outcomes. Either nothing changes and the system slowly holds the business back, or someone proposes the big rewrite: two years, a new stack, everything fixed at once. I've seen both. The second one tends to hurt more.

Why the big rewrite usually fails

A full rewrite looks clean on a slide. In practice it runs into the same three problems.

The old system keeps changing. The business can't freeze for 18 months. Every new feature has to be built twice, once in the old system and once in the new one, or the new one falls behind before it launches.

The old system knows things nobody wrote down. Years of edge cases, tax rules and customer exceptions live in that code. You rediscover them one production incident at a time.

Nothing ships until everything ships. The business sees cost and no value for a very long time. Support for the project fades long before it's finished.

That doesn't mean a rewrite is never right. It means you need a better reason than "the code is ugly."

Rewrite, refactor or replace?

Use this as a starting point when deciding what to do with each part of the system.

Most real systems need a mix. The skill is deciding which part gets which treatment.

The strangler fig approach

The approach I use most is the strangler fig pattern, a name Martin Fowler borrowed from a vine that grows around a tree until it can stand on its own. You build new components alongside the old system, route traffic to them one feature at a time, and retire the old code as it goes quiet.

The key is a routing layer in front of everything, so you can move one path at a time and move it back if something breaks.

// A thin routing layer: send migrated paths to the new service and
// everything else to the legacy app. Turning the flag off rolls back.
const migrated = ['/invoices', '/customers/search'];
 
export function targetFor(path: string, flags: { useNewInvoices: boolean }) {
  const isMigrated = migrated.some((prefix) => path.startsWith(prefix));
  if (isMigrated && flags.useNewInvoices) return 'https://new-api.internal';
  return 'https://legacy.internal';
}

In production this usually lives in an API gateway or load balancer rather than in application code, but the idea is the same: small moves, each one reversible.

A five-step modernization plan

Step 1: Map what you actually have

Before touching anything, draw the system as it runs today. What talks to what, where the data lives, which parts change most often, and which parts cause the most incidents. The map usually surprises people, and it becomes the plan.

Step 2: Add a safety net

Legacy code rarely has good tests, and you don't need to fix that everywhere. Write characterization tests around the area you're about to change: tests that capture what the system does today, right or wrong, so you notice when behaviour shifts.

Step 3: Choose the first slice carefully

Pick something with real business value, clear boundaries and moderate risk. Not the scariest module, and not something so small nobody notices. The first slice proves the approach to everyone watching.

Step 4: Move it, run both, compare

Send a small share of traffic to the new component and compare its results with the old one. Increase gradually. Keep the rollback path open until you've gone a few weeks without surprises.

Step 5: Delete the old code

This is the step teams skip. If the old code stays "just in case," you're now maintaining two systems. Set a date, remove it, and celebrate it. Deleting code is progress.

How to know it's working

Modernization projects drift when nobody measures them. These are the numbers I'd put in front of leadership every month.

The first four are the DORA metrics. They're widely used because they connect engineering work to outcomes a CFO cares about.

Where to start on Monday

You don't need a two-year program to begin. Start with three things:

1. Ask your team which part of the system they're most afraid to change, and why.
2. Map that area and everything it depends on, on a single page.
3. Write the tests that would let you change it safely.

That alone often turns "we can't touch it" into "we can touch it carefully." From there, every step is smaller than it looked.

If you're weighing a rewrite right now, a second opinion before you commit is cheap insurance. Get in touch and tell me what you're working with.