Most migration plans open with a target architecture and a cutover date. Both are useful. Neither is the thing that decides whether the migration goes well, because the failures almost never come from the new environment - they come from what was quietly true about the old one.
Inventory before architecture
Before deciding what the target looks like, write down what actually exists. Not what the architecture diagram says exists - what is running. In practice these lists always contain surprises: a cron job on a developer laptop, a service that only resolves because of a hosts-file entry, a report that reads directly from the production replica.
The inventory is tedious and it is the single highest-value week in the project. Every item you find now is an item that does not surface at 2am during cutover.
- Every running service, scheduled job and integration
- What talks to what, and in which direction
- Where credentials and secrets currently live
- Anything with a hardcoded hostname, IP or file path
Test the restore, not the backup
A backup that has never been restored is a belief, not a backup. Before anything moves, restore the database into a scratch environment and confirm the application actually runs against it. This regularly uncovers missing extensions, permissions that were granted by hand years ago, or a schema that only works because of a manual step nobody wrote down.
Move in dependency order, keep the old one warm
Big-bang cutovers fail badly because there is no intermediate state to fall back to. Moving service by service in dependency order, behind a routing layer, means each step is individually reversible. Keep the previous environment running until a full business cycle has passed on the new one - a month-end job that only runs once is exactly the thing that breaks after you decommission.
Right-size afterwards, not upfront
Sizing decisions made before migration are guesses dressed up as capacity planning. Move first on generous instances, gather two to four weeks of real usage, then tune. The savings from tuning against real data are usually larger than the savings from a careful upfront estimate, and they are based on something.
None of this is exotic. It is the ordinary discipline of knowing what you have before you move it - which is why it is so often the step that gets compressed when the timeline tightens, and so often the reason the timeline slips.