How to Point a Domain to a New Host Without Downtime

To point a domain to a new host without downtime, you change the authoritative DNS records before you move the actual files, then let the old and new hosts run in parallel until propagation settles. The key is that DNS is a distributed cache, not a switch, so you must plan for the time it takes for recursive resolvers to expire old records and fetch new ones.

How to point a domain to a new host without downtime: the core sequence

The process is deceptively simple: you update the A (and optionally AAAA) records at your current DNS provider to the new host’s IP address, wait for the TTL to expire everywhere, and only then move the website files and database. You never touch the domain registrar’s nameserver settings unless you are also changing DNS providers. If you are changing DNS providers, the same rule applies: add the new zone to the new provider, verify it, then change the NS records at the registrar. The critical mistake is moving files first and changing DNS second, because that creates a window where some visitors hit the old server and some hit the new one, and the old server is gone.

Start by checking the current TTL on your A record. Lower it to 300 seconds (5 minutes) at least 24 hours before the move, so that when you finally change the IP, the old cached value expires quickly. Run this from your terminal to see the current TTL:

dig example.com A +noall +answer
;; ANSWER SECTION:
example.com. 3600 IN A 203.0.113.10

The number before IN is the TTL in seconds. If it shows 3600, that is one hour. Change it to 300 in your DNS control panel, then wait at least that full hour before proceeding. Do not skip this step, because a high TTL means your new IP will not be picked up by some resolvers for up to a day, and those visitors will get a connection refused if you have already shut down the old host.

Stage the new host and copy the data

While the TTL is low, provision the new server with the same web server software, PHP version, and database engine as the old one. Copy the entire document root with rsync, preserving permissions and ownership. For a typical web app, run:

rsync -avz --delete /var/www/old-site/ user@new-host:/var/www/new-site/

Use --delete only if you are sure the destination is empty or a mirror. For the database, dump it and import it. For MySQL or MariaDB, do this:

mysqldump -u root -p old_database > db-backup.sql
mysql -u root -p -h new-host new_database < db-backup.sql

Do not switch anything yet. The old host is still live, and the new host is a silent copy. Test the new host by editing your local /etc/hosts file to point the domain to the new IP, then load the site in a browser. This verifies that the new server serves the correct content, that file paths are right, and that the database connection works. When you are satisfied, remove that line from /etc/hosts.

Change the A record and wait for propagation

Now change the A record at your DNS provider to the new host’s IP. Do not touch MX records unless you are also moving email. Email is a separate system, and if you move the mail server at the same time, you risk losing messages. Keep the old mail server running until all mailboxes are migrated, and only then update MX to a lower priority or a new hostname. For the web, after you save the new A record, the old host is still up, so any resolver that has not yet refreshed will still get the old IP and work fine. The new IP will gradually replace the old one as TTLs expire.

Monitor propagation with dig from multiple locations. Query a public resolver directly to see what it returns:

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

Both should eventually show the new IP. The time this takes is bounded by the TTL you set earlier. If you set 300 seconds, then within 5 minutes of the change, every resolver that queried before the change will have expired the old record and will fetch the new one. You do not need to wait for all of them, because the old host is still serving traffic. The important thing is that the old host stays up for at least 24 hours after the DNS change, to catch any resolver that had a stale cache from before you lowered the TTL.

Handle the edge cases: glue records and email

If your domain uses a custom nameserver, like ns1.example.com, you have a glue record problem. The NS records at the registrar point to hostnames that resolve via the domain itself. If you change the A record for ns1.example.com to a new IP, you are also changing the nameserver address, which can break resolution for anyone who has not yet cached the new glue. The safe path is to keep the old nameserver IPs as glue records until the zone transfer is complete, then update them in a second step. Most registrars let you edit glue records separately from the zone file. Do that only after you have confirmed the new nameserver is answering queries correctly for the zone.

For email, check your MX record and the SPF record. If your mail server is on the same IP as the web server, and you change the A record, you might break mail delivery because the mail client resolves the MX hostname to an IP that no longer has a mail listener. A clean approach is to keep the mail server on the old IP for a week, copy mailboxes to the new host, then update the MX record to point to a new hostname that resolves to the new IP. Do not change MX and A at the same time unless you are absolutely sure the new host has a fully configured mail stack. Test sending a message to an external account and receiving a reply before you retire the old server.

Verify the cutover and clean up

After you have changed the A record, wait for the TTL to expire, then check the response headers from the new host to confirm you are hitting the right server. Run:

curl -I http://example.com

Look at the Server header and the X-Powered-By header if present. They should match the new host’s configuration. Also check the response time; a sudden jump might indicate a misconfigured cache or a missing PHP module. If you use a CDN, remember that the CDN has its own TTL, so you may need to purge the cache after the DNS change. The CDN will fetch from the new origin IP, but only after its own cache expires.

Keep the old host running for at least 48 hours after the DNS change. Do not cancel the old server or delete its files. You might need to fall back if the new host has a hidden bug. After two full days, check your server access logs on the new host to confirm that traffic is coming in. If you see zero requests, something is wrong; check that the domain resolves correctly from a device that is not using your local DNS cache. Once you are confident, you can shut down the old host. If you moved email, keep the old mail server for a week to catch any queued messages that were in transit during the switch.

Finally, do not forget to update any hardcoded IPs in your application code, cron jobs, or third-party services that talk to your server. A common mistake is a database hostname that still points to the old IP, or an API callback URL that uses the old address. Grep your codebase for the old IP and replace it with the new one. Then run a final dig to confirm the A record is stable, and you are done.