Zero-downtime DNS migration

DNS migration is the process of moving DNS records to new servers, or changing the configuration, without interrupting your website and services.

When you need a DNS migration

• Changing hosting provider
• Moving to new DNS servers
• Changing server IP addresses
• Moving to a new server
• Changing domain registrar
• Reorganising your infrastructure
• Moving to a managed DNS service (Cloudflare, Route 53)

Migration risks

A badly handled migration can lead to:

• Your website being unavailable (for hours or days)
• Lost incoming email
• Broken API integrations
• Problems with SSL certificates
• Lost traffic and sales
• Damage to your SEO ranking

Principles of zero-downtime migration

1. Run in parallel — the old and new servers work at the same time
2. Move gradually — DNS changes spread over time, not instantly
3. Low TTL — makes changes propagate faster
4. Check at every stage — test before you switch over
5. Be ready to roll back — keep the option of going back

Migration timeline

Preparing for the migration

Stage 1: Audit of the current configuration

Inventory of DNS records

1. Export all DNS records
2. Document each record and what it is for
3. Check the dependencies between records

Commands to export the zone:

# Using dig
dig example.com AXFR > zone_backup.txt

# Or dig ANY for all records
dig example.com ANY +noall +answer > dns_records.txt

# Detailed export with TTL
dig example.com ANY +noall +answer +nottlid > dns_full.txt

Creating an inventory table

Checking dependencies

What to check:

• SSL certificates and how they depend on DNS
• Email services (SMTP, IMAP, POP3)
• API endpoints
• CDN configuration
• Subdomains and how they are used
• Third-party services (payment gateways and so on)

Stage 2: Planning the migration

Choosing a strategy

Strategy 1: Parallel running (recommended)

• The new server is set up and tested
• DNS is switched to the new server
• The old server stays available
• Suits most scenarios

Strategy 2: Gradual migration

• Subdomains are moved one at a time
• Test subdomains first, then production
• Suits complex infrastructures

Strategy 3: Blue-green deployment

• Two identical environments
• Instant DNS switch
• Easy rollback
• Suits critical systems

Choosing when to migrate

Best times:

• Low traffic (nights, weekends)
• Outside your peak season
• Not just before important events
• Taking your audience’s time zones into account

Worst times:

• Black Friday, holidays
• The middle of the working day
• Just before deadlines
• During advertising campaigns

Stage 3: Preparing the new server

Setting up the environment

1. Install the web server, PHP and the database
2. Copy the website files
3. Import the databases
4. Configure everything
5. Install the SSL certificates

Testing with the hosts file

Test the new server WITHOUT changing DNS:

Windows (C:\Windows\System32\drivers\etc\hosts):

192.0.2.100  example.com
192.0.2.100  www.example.com

Linux/macOS (/etc/hosts):

192.0.2.100  example.com
192.0.2.100  www.example.com

Open the website in a browser and check that:

• The home page loads
• All features work
• Forms submit
• The database is reachable
• The SSL certificate is valid

Checklist for the new server

• Web server configured and running
• All files copied
• Database imported
• Configuration files updated
• SSL certificate installed
• Email set up
• Cron jobs moved
• Tested using the hosts file
• Backup made
• Rollback plan ready

Stage 4: Backups

What to save:

1. The full DNS zone export
2. Web server configuration
3. Databases
4. Website files
5. SSL certificates
6. Email data
7. Documentation of the current setup

# Back up DNS through Zone Editor
# or export through cPanel Backup

# Back up the files
tar -czf website_backup_$(date +%Y%m%d).tar.gz /home/username/public_html/

# Back up the database
mysqldump -u user -p database > db_backup_$(date +%Y%m%d).sql

Lowering the TTL

48–72 hours before the migration:

Why a low TTL matters

The TTL (Time To Live) determines how long a DNS record is cached.

• High TTL (14400 = 4 hours): changes spread slowly
• Low TTL (300 = 5 minutes): changes spread quickly

Lowering the TTL in cPanel

1. Go to Zone Editor → Manage
2. For EVERY record you are going to change:
   1. Click Edit
   2. Change the TTL to 300 or 600
   3. Save
3. Wait for the OLD TTL (for example, 4 hours) before migrating

Which records to change:

• A records for the domain and subdomains
• AAAA records (if used)
• CNAME records
• MX records (if you are moving email)

Checking that the new TTL has propagated

# Check the current TTL
dig example.com | grep "IN.*A"

# It should show the new TTL (300 or 600)
# If it shows the old one, wait a little longer

The migration process

Migration strategy by record type

Scenario 1: Moving a website only

What changes:

• The domain’s A record
• The www A record

What stays the same:

• MX records (email stays where it is)
• Other subdomains

Sequence:

1. Make sure the new server is ready
2. Change the A record for the main domain:

example.com.  300  IN  A  192.0.2.100  ; new IP

1. Change the A record for www:

www.example.com.  300  IN  A  192.0.2.100  ; new IP

1. Check that the website is available
2. Monitor the logs on BOTH servers

Scenario 2: Moving a website and email

Recommended order:

Day 1: Move the website

1. Change the A records for the website
2. Check that the website works
3. Monitor for 24 hours

Day 2: Move email (if everything is OK)

1. Set up email on the new server
2. Create the email accounts
3. Move the messages (optional)
4. Change the MX records:

example.com.  300  IN  MX  0  mail.newserver.com.

1. Update the mail A record:

mail.example.com.  300  IN  A  192.0.2.100

Scenario 3: Full infrastructure migration

Phased approach:

Phase 1: Test subdomains

test.example.com.  300  IN  A  192.0.2.100
dev.example.com.   300  IN  A  192.0.2.100

Monitoring: 2–4 hours

Phase 2: Non-critical subdomains

blog.example.com.  300  IN  A  192.0.2.100
cdn.example.com.   300  IN  A  192.0.2.100

Monitoring: 24 hours

Phase 3: The main domain

example.com.       300  IN  A  192.0.2.100
www.example.com.   300  IN  A  192.0.2.100

Monitoring: 48 hours

Phase 4: Critical services

api.example.com.   300  IN  A  192.0.2.100
app.example.com.   300  IN  A  192.0.2.100

Monitoring: 72 hours

Phase 5: Email

example.com.       300  IN  MX  0  mail.example.com.
mail.example.com.  300  IN  A  192.0.2.100

Changing DNS records

In cPanel Zone Editor

1. Go to Zone Editor → Manage
2. For each A record:
   1. Click Edit
   2. Change the Address to the new IP
   3. Leave the TTL at 300/600
   4. Click Save
3. Repeat for all the records, following your plan

Checking the changes

Check straight after making the change:

# Check through different DNS servers
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @ns1.your-hosting.com example.com +short

# They should all return the NEW IP

Changing DNS servers (name servers)

If you are moving to different DNS servers:

Preparation

1. Create a full copy of the zone on the NEW DNS servers
2. Check that all the records are there
3. Double-check the critical records (A, MX, TXT)

Changing them at the registrar

1. Log in to your domain registrar’s control panel
2. Find the Nameservers / DNS section
3. Change to the new NS:

Before:

ns1.old-hosting.com
ns2.old-hosting.com

After:

ns1.new-hosting.com
ns2.new-hosting.com

1. Save the changes

The transition period

During those 24–48 hours:

• Some users see the old server
• Others see the new server
• Both servers must work in parallel
• Keep changes in sync on both

Monitoring the migration

Checking DNS propagation

Online tools

• WhatsMyDNS.net — global check
• DNS Checker — check by country
• MXToolbox — comprehensive check

Command line

# Monitor every 5 minutes
watch -n 300 'dig example.com +short'

# Check from different DNS servers
for ns in 8.8.8.8 1.1.1.1 208.67.222.222; do
  echo "DNS: $ns"
  dig @$ns example.com +short
done

# Check all record types
dig example.com ANY +noall +answer

Monitoring website availability

Checking the web server

# Check the HTTP response
curl -I https://example.com

# It should return 200 OK

# Check the response time
curl -o /dev/null -s -w '%{time_total}\n' https://example.com

# Check a specific page
curl -s https://example.com/test-page | grep "expected content"

Uptime monitoring

Use services such as:

• UptimeRobot (free)
• Pingdom
• StatusCake
• Site24x7

Set up alerts for:

• Downtime (HTTP 5xx)
• Slow responses (over 3 seconds)
• Content changes

Monitoring email

Checking MX records

# Check MX
dig example.com MX +short

# Check the mail server
dig mail.example.com A +short

# Test the SMTP connection
telnet mail.example.com 25
# or
nc -zv mail.example.com 25

Checking delivery

1. Send a test email to an address on your domain
2. Check that it arrives
3. Send an email from your domain
4. Check the delivery logs

Checking SPF/DKIM/DMARC

# SPF
dig example.com TXT +short | grep spf

# DKIM
dig default._domainkey.example.com TXT +short

# DMARC
dig _dmarc.example.com TXT +short

Analysing the logs

On the old server

Watch for traffic falling:

# Apache/Nginx access log
tail -f /var/log/apache2/access.log
tail -f /var/log/nginx/access.log

# Count requests
tail -1000 /var/log/apache2/access.log | wc -l

On the new server

Watch for traffic rising:

# Real-time monitoring
tail -f /var/log/apache2/access.log

# Check for errors
tail -f /var/log/apache2/error.log | grep -i error

Metrics to track

Troubleshooting during the migration

Problem: Some users see the old website

Cause: DNS cache, slow propagation

Solution:

1. This is normal in the first 24 hours
2. Both servers must keep working
3. Wait for propagation to complete
4. Users can clear their DNS cache:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

Problem: The website won’t open (502/504)

Causes:

• The web server isn’t running on the new server
• The firewall is blocking port 80/443
• PHP-FPM isn’t running
• The database is unavailable

Solution:

# Check the web server status
sudo systemctl status apache2
sudo systemctl status nginx

# Check the ports
sudo netstat -tulpn | grep :80
sudo netstat -tulpn | grep :443

# Check the logs
tail -50 /var/log/apache2/error.log
tail -50 /var/log/nginx/error.log

Problem: SSL errors

Causes:

• The certificate isn’t installed on the new server
• The certificate was issued for a different domain
• The certificate has expired

Solution:

1. Install SSL on the new server BEFORE the migration
2. Use Let’s Encrypt for automatic installation
3. Check the certificate:

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates

Problem: Email isn’t being delivered

Causes:

• The MX records haven’t updated yet
• The SMTP server isn’t configured
• The firewall is blocking port 25

Solution:

1. Check the MX records globally
2. Make sure both mail servers are working
3. Check the ports:

telnet mail.example.com 25
telnet mail.example.com 587
telnet mail.example.com 993

Problem: API integrations aren’t working

Causes:

• The api. subdomain hasn’t been updated
• The IP changed and partners haven’t updated their whitelists
• Incorrect CORS settings

Solution:

1. Tell ALL your partners about the new IP in advance
2. Keep the old IP in the whitelist for a while
3. Check the CORS headers on the new server

Rollback plan

When to roll back:

• Critical errors on >5% of requests
• Complete unavailability of the service
• Data loss
• Problems that can’t be fixed quickly

Rolling back DNS records

1. In cPanel Zone Editor
2. Put the OLD IP addresses back:

example.com.  300  IN  A  192.0.2.1  ; old IP
www.example.com.  300  IN  A  192.0.2.1  ; old IP

1. Propagation: 5–30 minutes (thanks to the low TTL)

Rolling back NS servers

If you changed the name servers:

1. Go back to the registrar’s control panel
2. Put the old NS servers back
3. Propagation: 24–48 hours

A temporary workaround

While DNS is rolling back:

1. Use the hosts file for yourself
2. Set up a local DNS server
3. Tell your users about the problems

After the migration

The first 24 hours

• Monitor every 2 hours
• Check metrics (uptime, response time)
• Check the error logs
• Test functionality
• Check email delivery
• Monitor DNS propagation

24–48 hours

• Daily monitoring
• Check analytics (has traffic dropped?)
• Check conversions
• Compare with the previous period

After 48–72 hours

Restoring the TTL:

1. If everything is running stably
2. Raise the TTL back to 14400 (4 hours) or 86400 (1 day)
3. This reduces the load on the DNS servers

After 7 days

Decommissioning the old server:

• Make sure traffic on the old server = 0
• Take a final backup
• Decommission the old server
• Or keep it as a standby

Migration checklist

7 days before

• Audit the DNS records
• Draw up a migration plan
• Back up everything
• Set up the new server
• Test using the hosts file

48–72 hours before

• Lower the TTL to 300–600 seconds
• Final testing of the new server
• Tell your team about the migration
• Prepare the rollback plan

Migration day

• Check the new server is ready
• Change the DNS records according to the plan
• Start monitoring
• Check availability from different locations
• Monitor the logs on both servers

After the migration

• Monitor for 24–48 hours
• Check all services
• Analyse the metrics
• Restore the TTL (after 48–72 hours)
• Decommission the old server (after 7 days)
• Document the new configuration
• Post-mortem analysis (if there were problems)

Special scenarios

Zero-downtime migration (enterprise)

Requirements:

• A budget for additional infrastructure
• A load balancer
• Several servers

Approach:

1. Set up a load balancer with both servers
2. Point DNS at the load balancer
3. Move traffic over gradually (10%, 25%, 50%, 100%)
4. If there are problems, switch back to the old server instantly

Migrating a large number of domains

Automating through the API:

#!/bin/bash
# Example script for bulk updates through the cPanel API

DOMAINS=("example1.com" "example2.com" "example3.com")
NEW_IP="192.0.2.100"

for domain in "${DOMAINS[@]}"; do
    # Update through UAPI
    uapi --user=username DNS edit_zone \
        zone="$domain" \
        line=1 \
        type=A \
        address="$NEW_IP"
    
    echo "Updated $domain"
    sleep 2
done

Migrating with a CDN (Cloudflare)

Advantages:

• Cloudflare caches your content
• Minimal downtime
• Easy rollback

Process:

1. Add the domain to Cloudflare
2. Cloudflare scans the DNS
3. Change the NS to Cloudflare’s
4. Once that has propagated, change the IP in Cloudflare
5. Instant update (no waiting for DNS)

Migration tools

DNS tools

• dig — DNS checks
• nslookup — simple check
• host — quick check
• WhatsMyDNS.net — global check
• MXToolbox — comprehensive check

Monitoring

• UptimeRobot — uptime monitoring
• Pingdom — performance monitoring
• New Relic — APM monitoring
• DataDog — infrastructure monitoring

Data migration

• rsync — file synchronisation
• mysqldump — database export
• wp-cli — WordPress migration
• cPanel Transfer Tool — automatic transfer

Best practices

1. Plan ahead — at least a week in advance
2. Test everything — never change DNS without testing
3. Lower the TTL — always 48–72 hours beforehand
4. Monitor actively — the first 48 hours are critical
5. Keep the old server — for at least a week after the migration
6. Document everything — write down every change
7. Prepare a rollback — always have a plan B
8. Tell your users — if problems are possible
9. Do it in stages — don’t change everything at once
10. Learn from mistakes — hold a post-mortem

Common mistakes

1. Not lowering the TTL in advance → slow propagation
2. Forgetting about subdomains → some services stop working
3. Not testing the new server → errors after the migration
4. Changing NS before the new zone is ready → complete downtime
5. Migrating email and the website at the same time → hard to diagnose
6. No rollback plan → panic when problems appear
7. Decommissioning the old server too early → no way to roll back
8. Not telling partners about an IP change → broken integrations

See also

• DNS records in detail
• Managing domains
• Creating backups
• Troubleshooting DNS

External links

• WhatsMyDNS - Global DNS Propagation Checker
• MXToolbox - DNS & Email Tools
• Cloudflare DNS Migration Guide
• AWS Route 53 Migration Guide