Zero-Downtime DNS Cutover: A Playbook for Live Migrations
Learn how to migrate live websites with zero downtime using DNS TTL pre-lowering, split-horizon checks, and instant rollback triggers. A practical playbook for hosting resellers.
You need to move a live website to a new server without your visitors noticing. A single mistake in DNS cutover can cause hours of downtime, lost sales, and angry clients. This playbook shows you how to plan and execute a zero-downtime migration using TTL pre-lowering, split-horizon checks, and instant rollback triggers.
Why does DNS TTL matter for zero-downtime migrations?
DNS TTL (Time To Live) is the number of seconds that resolvers cache a DNS record. If your TTL is 86400 (24 hours), any change you make will take up to a day to propagate worldwide. That is too slow for a live cutover. By pre-lowering the TTL to a short value, you ensure that when you change the record, most resolvers pick up the new IP within minutes. This is the foundation of a zero-downtime migration.
Start by lowering the TTL for the A and AAAA records of the domain you plan to move. Do this at least two times the current TTL before the migration. For example, if your TTL is 3600 (1 hour), lower it to 300 (5 minutes) at least 2 hours before the cutover. This gives resolvers time to expire the old TTL and start using the new one.
How to lower TTL without causing issues
- Log in to your DNS provider and edit the TTL for the relevant records.
- Set TTL to 300 seconds (5 minutes) or even 60 seconds if your provider allows it.
- Wait for the old TTL to expire. You can check propagation using online tools or dig commands.
- Do not change the IP address yet. Only lower the TTL.
Once the TTL is low, you are ready to proceed with the migration steps.
How do you stage the new server for a live migration?
Before you touch DNS, you must have the new server fully configured and tested. This means replicating the website files, databases, email accounts, and any other services. Use a staging environment that mirrors the production setup as closely as possible.
If you are using a hosting automation platform like Teculiar, you can provision a new server and deploy your client's website with the same configuration. Teculiar is a platform that hosting resellers use to build, sell, and automate hosting, domains, and VPS services. You can create a staging copy and test it thoroughly.
Key steps for staging:
- Copy all website files from the old server to the new one.
- Export and import databases, ensuring data integrity.
- Set up email accounts and test sending/receiving.
- Configure SSL certificates on the new server.
- Test the website using a hosts file entry or a temporary URL to avoid DNS changes.
Use a split-horizon DNS check to verify that the new server responds correctly for different regions. Split-horizon DNS means that internal and external views of DNS may differ. You can simulate this by querying the new server's IP directly from multiple locations.
What is a split-horizon check and why is it important?
A split-horizon check ensures that the new server is reachable and serving the correct content from various network perspectives. For example, if your new server is behind a firewall or load balancer, internal and external DNS might resolve differently. You need to confirm that both internal and external clients will reach the new server after the cutover.
Perform these checks:
- Use
digornslookupagainst public resolvers (8.8.8.8, 1.1.1.1) to see what the world sees. - Check from different geographic locations using online tools.
- If you have internal DNS, ensure it points to the new server as well.
- Verify that the new server responds to HTTP/HTTPS requests with the correct content.
How to execute the DNS cutover with instant rollback triggers
Now comes the moment of truth: changing the DNS record to point to the new server. But you must have a rollback plan ready in case something goes wrong. Instant rollback triggers are conditions that, when met, automatically or manually revert the DNS change to the old server.
Define your rollback triggers before you start. Common triggers include:
- HTTP 5xx errors exceed a threshold (e.g., 1% of requests).
- Website response time increases significantly.
- Database connection errors appear.
- SSL certificate errors occur.
- Email delivery failures are detected.
Set up monitoring to watch these metrics in real-time. Tools like UptimeRobot, Pingdom, or your own scripts can alert you. If a trigger is hit, revert the DNS record to the old IP immediately. Since you lowered the TTL, the rollback will propagate quickly.
Step-by-step cutover process
- Ensure the new server is fully synced with the latest data. You may need to put the site in maintenance mode briefly to prevent new data from being written to the old server.
- Change the DNS A record to the new server's IP. If you have multiple A records, update all of them.
- Monitor traffic and error rates closely for the next 30–60 minutes.
- If all is well, keep the new server as primary. If not, rollback.
- After a successful cutover, you can gradually increase the TTL back to a normal value (e.g., 3600 or 86400).
Remember that DNS changes are not instantaneous everywhere. Some resolvers may still cache the old record until the TTL expires. This is why lowering TTL beforehand is critical.
What to do after a successful cutover
Once the new server is live and stable, you can decommission the old server. But don't rush: keep it running for a few days as a fallback. Monitor for any issues that might arise from residual DNS caching.
Update your documentation and inform your client about the successful migration. If you used a platform like Teculiar, you can automate future migrations and even offer them as a service to your clients.
What to do next
- Review your current DNS TTL settings and plan to lower them before your next migration.
- Set up monitoring and define rollback triggers for your critical websites.
- Test your migration process in a staging environment to ensure it works smoothly.
- Consider using a hosting automation platform to streamline future migrations. Check our pricing for options.
Start by auditing your DNS and preparing a checklist for your next live migration.