Last spring I moved an entire production stack — database, object storage, app servers, mail — from one cloud region to another. Different continent, different provider, same users. The plan looked clean on paper. The execution? Less clean. If you've ever tried to physically relocate a running system, you know the feeling. Stuff that worked locally suddenly doesn't. DNS lies to you. Half your users hit the old server, half hit the new one, and the database that was supposed to be "caught up" is mysteriously 12 minutes behind. This post is about why naive cutovers fail and how to do one that actually works. The problem: "just point DNS at the new server" I've seen this approach proposed in a dozen migration docs. Spin up the new stack, dump and restore the database, change the DNS record, done. It almost never works that cleanly, and the reason is rarely a single thing — it's a pile of small things that all hit at once. Here's what actually goes wrong: DNS TTLs aren't honored.…