Most migration horror stories share a root cause: the DNS was pointed at the new server before the new server was genuinely ready. Everything after that is damage control in public.
Build the destination completely first
The new VPS should be serving a working, fully tested copy of the site — correct PHP version, database imported, TLS certificate issued, caching configured — while the old host is still handling all live traffic. You verify by editing your local hosts file, not by moving DNS and hoping.
Lower TTL before you touch anything
Drop your DNS records’ TTL to 300 seconds at least 24 hours ahead of the cutover. Records are cached for their previous TTL, so a value you change on the day of the move has no effect on resolvers that already cached the old one. This single step is the difference between a five-minute propagation window and a two-day one.
Handle the write gap
Between the final database sync and the DNS cutover, any order, comment, or form submission that lands on the old server is a record you are about to lose. Two workable approaches:
- Put the old site into a brief read-only or maintenance state for the final sync, keeping the window to minutes.
- Sync a final delta immediately after the cutover, once writes are landing on the new server only.
Which one fits depends on how much write traffic the site actually takes. A brochure site can skip this entirely; a store cannot.
Keep the old host alive
Do not cancel the old hosting the moment the site loads. Leave it running for at least a week: some resolvers ignore TTLs, and you want a rollback path that does not depend on rebuilding anything.
What “no downtime” actually means
Done in this order, both servers serve the same working site throughout the transition. Visitors reach whichever one their resolver knows about, and neither answer is wrong. That is the whole trick — there is no moment where the correct destination does not exist.