Every engineering leader inherits one: the platform that's hard to change, expensive to run, and risky to touch. And every one of them hears the same seductive pitch — rewrite it properly this time.

Big-bang rewrites fail for predictable reasons. The legacy system keeps changing while you rebuild it, so you're chasing a moving target. The rewrite team drains your best people from the product that pays the bills. And the business sees nothing for 12–18 months, so support evaporates right when the hard part starts. We've been called in more than once after exactly this movie.

The incremental method

We modernize systems the way we run our own: in slices that ship, behind interfaces that hold, measured by outcomes the business can see.

1. Assessment before commitment (2–4 weeks)

Not a 200-page audit — a working map: where the system actually hurts (performance traces, incident history, change-failure rate), what must not break, and a sequenced plan where every phase delivers something the business can feel. You keep the plan whether or not we continue.

2. Strangle, don't replace

New capabilities are built alongside the old system, behind stable interfaces — routes, events, or an API gateway — and traffic moves over gradually. The legacy system retires piece by piece, not on a terrifying cut-over weekend. At Apploi, we migrated a large class-based React codebase to a typed, hooks-driven design system this way: ~40% less boilerplate, with product teams shipping the whole time.

3. Tests as the safety rail

Legacy systems rarely come with tests, which is exactly why they're scary to touch. We write characterization tests around the behavior that exists before changing it. Boring, unglamorous, and the single biggest reducer of migration risk.

4. Reliability and cost as first-class outcomes

Modernization that only swaps frameworks is redecorating. The point is operational: faster changes, fewer incidents, lower run cost. After a payroll client's silent-drop incident, the re-architecture goal wasn't “newer stack” — it was “this class of failure becomes impossible, and we can prove it.”

What to demand from any modernization partner

* Increments the business can see — working software on a cadence, not a distant horizon

* A rollback story for every phase — if a slice can't be reversed, it's not a slice

* Test coverage that grows with the migration — not promised for “after”

* An honest risk log — what could break this week, and what we're doing about it

The uncomfortable truth

The rewrite instinct is usually an ownership problem wearing a technology costume: nobody understands the old system end to end, so replacing it feels safer than touching it. Incremental modernization forces the understanding back — which is why it produces teams that can keep evolving the platform after the engagement ends.

That's the platform modernization playbook: assessment in 2–4 weeks, programs in 3–9 months, no big bang — and all code, tests, and documentation yours at handover.