Migrating Your Site with Zero Downtime: A Safe DNS Cutover
Zero-downtime migration is about order, not speed: prepare the new server, test with the hosts file, lower TTL ahead of time, switch DNS, and keep the old server running until it propagates. We detail each step and the high-TTL trap.
Migrating your site with zero downtime is entirely possible, and the secret is not speed but order: copy everything to the new server, test it before anyone sees it, lower TTL in advance, then switch the DNS record and keep the old server running until the change propagates. The most common mistake is switching DNS first and moving data second, which drops the site into a gap between an old server people stopped updating and a new one that is not ready. The correct order is the reverse. First, fully prepare the new server and move the files and database to it. Second, test it by editing the hosts file on your machine so the domain points to the new IP, letting you browse the site as if it were live without changing anything for visitors. Third, a day or two before the move, lower the TTL on the records (say to 300 seconds) so the switch propagates quickly at execution time. Fourth, change the A record to the new IP. Fifth, monitor until you confirm all visitors reached the new server, keeping the old one running throughout DNS propagation. A high TTL is the biggest trap, since a record at 86400 seconds means some visitors stay on the old server for a full day. At Cloud, activation is automatic within seconds and servers are Saudi with a response time around 8ms, which makes preparing the new destination fast. The rest of this article details each step.
Why Order Makes the Difference
DNS is not an instant switch, it is a distributed cache. When you change an A record, the world does not see the change at the same moment, it rolls over as cached copies expire at internet providers and browsers. That duration is governed by TTL. So you cannot rely on everyone moving instantly, since some visitors stay on the old address for minutes or hours. The fix is to keep the old address alive during the transition, serving the same content until propagation finishes.
Anyone who switches DNS then immediately shuts down the old server creates downtime for visitors who have not yet received the new address. The safe order keeps both servers alive together through the transition window, so no visitor sees a broken page.
Step One: Copy and Prepare the New Destination
Before touching any DNS record, move everything to the new server: site files, database, certificates, server settings. Match the environment to the old one (PHP version, extensions, environment variables). If the database is large and constantly changing, plan a short final sync right before the switch so you do not lose data entered during preparation. The goal is a complete, ready-to-run copy on the new server before any visitor is directed to it.
Review your destination options between a full server under your control on the cloud server or managed cPanel hosting on cloud hosting, and pick what fits your app.
Step Two: Test Through the Hosts File
This is the most important step many skip. Edit the hosts file on your machine to bind your domain to the new IP, so your machine alone sees the new server while the rest of the world stays on the old one. Browse the whole site: pages, forms, login, payment, admin panel. Confirm everything actually works on the new destination before any real visitor reaches it. If an error appears, you fix it calmly with no one affected, because the change is confined to your machine.
Once you confirm everything is sound, restore the hosts file to its original state. This gate turns the migration from a gamble into a measured operation.
Step Three: Lower TTL in Advance
TTL tells caches how long to keep the record before asking again. If it is high, many visitors stay on the old address long after the switch. A day or two before the move, lower the TTL on the relevant records to a small value like 300 seconds. Wait for that low value itself to propagate (at least by the old TTL), so the whole world now queries your record every five minutes. Then the actual switch propagates almost instantly. The table below shows TTL's effect on transition speed:
| TTL value | Max time stuck on the old address | Fit |
|---|---|---|
| 86400 seconds (a day) | Up to 24 hours | Stable, bad during migration |
| 3600 seconds (an hour) | Up to an hour | Middle ground |
| 300 seconds (5 minutes) | Up to 5 minutes | Ideal during migration |
A few days after the transition settles, raise the TTL back to a higher value to ease the load on DNS servers.
Steps Four and Five: Switch, Then Monitor
Now change the A record (and the AAAA record if you have IPv6) to the new IP. Keep the old server running and able to serve visitors throughout propagation, do not shut it off at the moment of the switch. Monitor both sides: the new server's logs should show rising traffic, and the old one's logs should decline gradually toward zero. When traffic stops reaching the old server entirely over a period well beyond the old TTL, you are safe to shut it down. Check mail records too (MX, SPF, DKIM) if the domain sends email, since forgetting them sends your messages away from the inbox.
Do not forget the certificate: confirm the SSL certificate on the new server is valid before the switch so visitors see no warning. Review plan details on the pricing page.
Common Migration Mistakes and How to Avoid Them
The first repeated mistake is forgetting the final data sync. If you prepared the new server on Monday and switched DNS on Wednesday without syncing what came in between, you may lose orders and accounts created on the old server during that window. The fix is to freeze writes briefly before the switch, or run a final delta sync right before diverting traffic, so the new server starts from a state identical to the old one at the moment of transition.
The second mistake is neglecting the edge or proxy layer. If your domain sits behind an edge service, changing the A record at the domain provider alone may not be enough, since the edge is what actually routes visitors, so update the origin in the edge panel, not just root DNS. Anyone watching the origin instead of the edge may think the migration is done while visitors are still routed to the old server without it showing in their check.
The third mistake is assuming propagation is instant and shutting the old server down minutes after the switch. Propagation is governed by TTL and intermediate caches that may ignore your values, so keep the old server running for a multiple of the old TTL before considering shutdown. The fourth is forgetting to test integrations: the payment gateway, third-party services, and scheduled jobs may point to an old address written in a fixed config, so review them all after the switch, not just the front end, since a silently broken integration may only surface days later.
A Practical Step-by-Step Summary
A safe migration is six ordered steps: fully prepare the new server, test it through the hosts file, lower TTL one to two days ahead, switch the DNS record, keep the old server running until propagation ends, then shut it down after confirming all visitors reached the new one. Never switch DNS first, never shut down the old server quickly, and never leave TTL high during the move. Follow this order and your site migrates without a single visitor noticing.
