1. Map what you actually run
Before choosing a target architecture, build an inventory of every workload, the systems it talks to, and who depends on it. The surprises that cause outages are almost always undocumented dependencies: a scheduled job on an old server, a hard-coded IP address, a licence tied to hardware. Capture traffic patterns and peak hours too, because they decide when you can cut over.
2. Pick a strategy per workload
Not everything deserves re-architecture. Stateless services usually move cleanly as a lift-and-shift. Databases and anything with heavy state need a replication plan. Legacy systems near end of life may be better retired or replaced than moved. Decide workload by workload, and write the decision down.
3. Replicate first, switch later
Zero downtime comes from running old and new side by side. Stand up the target environment, replicate data continuously, and keep the source as the system of record until the moment of cutover. For databases this means native replication or a managed migration service with ongoing change capture, not a one-off dump and restore.
4. Rehearse the cutover
Run the full cutover at least once against a copy of production. Time every step. Test the application against the new environment with real traffic patterns, and test the rollback as seriously as the cutover. A rollback plan nobody has practised is a hope, not a plan.
5. Cut over gradually
- Lower DNS TTLs a few days ahead so changes take effect in minutes.
- Shift traffic in stages using weighted routing or a load balancer, starting with a small percentage.
- Watch error rates and latency at each stage against a baseline you recorded beforehand.
- Keep the source warm until you have passed at least one full business cycle on the new platform.
6. Finish the job
Migration is not done at cutover. Decommission the old environment deliberately, confirm backups and monitoring cover the new one, and review the first month of cloud spend against the estimate. Right-sizing in the first 30 to 60 days is where most of the cost savings are found.
If you are planning a move and want a second opinion on the sequence, our cloud practice, Queclouds, runs migration assessments across AWS, Azure and Google Cloud.