The instinct when facing a legacy system is to rebuild it properly. It is also the plan most likely to be cancelled at sixty percent completion, because it delivers nothing until it delivers everything.
Sequence over scope
A migration that returns value early survives budget scrutiny. One that asks for eighteen months of faith does not. The sequencing question is therefore not "what is the right architecture" but "what can move first and be visibly better".
A workable order
- Move the boring things. Static assets, backups, batch reporting. No behaviour change, immediate cost and reliability wins.
- Put a seam in front of the monolith. An API gateway or reverse proxy you control, so traffic can be redirected per-route later.
- Extract by pain, not by diagram. The module that pages someone at night goes first, regardless of how neat the boundary is.
- Move the data last, and once. Dual-write phases are where migrations go to die.
The seam is the whole trick
Once requests pass through something you control, migration becomes a routing decision rather than a release event. One route at a time, reversible, observable.
If you cannot move a single endpoint to the new system and back again within a day, you are not migrating — you are rewriting with extra steps.
What people consistently underestimate
- Scheduled jobs. Undocumented, business-critical, discovered when they stop.
- Integrations by IP allow-list. Every partner who whitelisted a fixed address must be coordinated with.
- Report parity. Finance will compare the new numbers to the old ones. They must match exactly, including the historical quirks.
Finish the job
The final ten percent — decommissioning, removing the seam, deleting the dual paths — is the part that gets deferred and never done. Budget for it explicitly, or you will run two systems forever and get the benefits of neither.
