Skip to content
Leadership Expert 4 min

Migrations, Not Rewrites: The Only Change That Scales

A big-bang rewrite concentrates all risk into one cutover and freezes the business while you guess. Incremental migration spreads the risk and keeps shipping.

By Victor Robin •

The problem

The clean rewrite is the most seductive plan in engineering: build the right thing in parallel, then flip a switch. It concentrates every ounce of risk into a single cutover — the moment you understand least — and freezes the business while you guess. At any real scale, that trade loses.

I nearly made it. We had an eleven-year-old billing engine nobody fully understood, where every change took a week and a held breath. I costed a clean rewrite at four months and had the steering-committee slide ready, feature freeze and all. A senior engineer stopped me with one question: “What happens to the three contract changes Sales already promised next quarter?” The answer was that they wait — and so would everything queued behind them.

The model

Migrations are the only scalable way to manage change as systems and organisations grow. The point isn’t that rewrites are forbidden; it’s that change spread across many small, reversible steps outscales change that hoards risk for one heroic event — every time. A migration keeps the business running while you learn; a rewrite asks it to hold its breath while you guess. The same logic applies to people: an org change announced on a Monday is a big-bang cutover, all the disruption on one date with no way to roll back when reality disagrees.

What to do

  • Replace the rewrite with a strangler-fig migration. Put a proxy in front of the old system and move one capability at a time; let every request fall back to the original until the new path earns trust in production.
  • Start where it is safe to be wrong. Migrate read-only invoice retrieval before any money-moving path, building the pattern and the deployment muscle on low stakes.
  • Keep the feature tap open. Nothing freezes. Build new work against the new path where it exists and the old path where it doesn’t — which also surfaces the boundaries you drew wrong.
  • Migrate org change the same way. Moving to continuous deploy? Let one team adopt it, watch what breaks, write down the new defaults, and let the next team opt in. Process by adoption, not decree.

The results

The migration ran a little over five months — slightly longer than the rewrite estimate, which is the part people miss. The calendar was similar; the risk profile was not. We shipped continuously throughout and the business never went dark. We retired the old engine boundary by boundary (about a dozen capabilities) with no freeze; billing-area deploys went from “weekly, nervously” to several times a day, with a lower change-failure rate than the untouched legacy. The deploy-process change spread across most of the org within two quarters, with no mandated cutover.

The caveat: incremental is genuinely harder in one respect — running two systems behind a proxy means carrying both, plus the glue, for months. There were weeks the old engine’s quirks leaked into the new one and the clean break looked tempting. It wasn’t the better choice, but the temptation is real; a leader who pretends the migration path is painless loses the team the first time it bites.

Further reading