Why big-bang rewrites stall
Three forces compound. The old system keeps changing, because the business cannot freeze for eighteen months, so you are chasing a moving target. The undocumented behaviour turns out to be load-bearing — the odd rounding rule that a major customer depends on. And the project delivers no value until the very end, so the moment budgets tighten it becomes the obvious thing to cut, at 70% complete and 0% useful.
Strangler migration, concretely
Put a routing layer in front of the legacy system. Move one bounded capability at a time behind that facade — a single screen, a single API, a single batch job. Each move goes live independently, delivers value immediately, and is reversible by flipping a route. The legacy system shrinks until what remains is small enough to retire or leave alone.
Data is the hard part, not code
Two systems writing to overlapping data will diverge. Decide per entity which side owns writes during transition, propagate changes one way only, and run continuous reconciliation reporting that surfaces drift within a day rather than at year-end audit. Where dual-write is unavoidable, use an outbox pattern and accept eventual consistency explicitly rather than pretending it is synchronous.
Characterisation tests before you touch anything
Before changing legacy behaviour, capture it. Record real inputs and outputs in production, replay them against the new implementation, and treat every difference as a question rather than a bug — some differences are fixes, some are regressions, and only a domain expert can tell you which. This is the single highest-value activity in a modernisation programme and the one most often skipped.
Sequence by risk, not by ease
The temptation is to start with the simplest module to build momentum. We start with a slice that is genuinely representative — one that touches authentication, data access, integration and reporting — because that is what validates the pattern. A pilot that avoids all the hard parts proves nothing about the remaining eighteen months.
What good looks like at six months
Three or four capabilities running on the new platform in production. The routing layer stable. Reconciliation clean. A measured reduction in change lead time for migrated areas. And a team that has done the work often enough to estimate the rest with confidence. Compare that to a rewrite at six months: a large branch, no production traffic, and an estimate nobody believes.