Large replacement programmes fail in a recognisable way: eighteen months of work, one cutover date, and a discovery during the final month that the old system did something important nobody had documented.
Migrate around the edges first
Put a routing layer in front of the legacy system and move functionality behind it one capability at a time. Each move is independently valuable, independently reversible, and independently tested against live traffic. The old system shrinks until switching it off is uneventful.
The undocumented behaviour is the requirement
Systems that have run a business for fifteen years contain rules nobody remembers writing and everybody depends on. Incremental migration surfaces them at a survivable scale — one capability at a time, with the old system still running as the reference.
You cannot specify your way to the behaviour of a system nobody fully understands. You can only replace it in pieces small enough to check.
Sequence by risk, not by ease
- Start with something real enough to prove the approach, but contained enough to reverse.
- Move the highest-risk capability while the team still has budget and attention for it.
- Leave the genuinely trivial parts until last — they are the ones that can be rushed safely.
Transformation is a people programme
New software changes how people work, and a rollout that ignores that produces expensive shelfware. Training, documentation and a route for feedback are part of the delivery, not a phase after it.