How to Migrate a Website to a New Host Without Downtime

A website migration looks like one step, "point the domain at the new server," but downtime comes from the things around that step: DNS caches that still send visitors to the old server, a database that changed while you copied it, an SSL certificate that isn't ready, and mail records that quietly disappear. A migration without downtime is mostly preparation. This guide gives you the sequence we recommend, with commands, so the cutover itself is a non-event.

This guide covers moving between web hosts while keeping your DNS provider. If you are also changing DNS providers, do that separately, as described in change nameservers without downtime. Changing two things at once makes problems hard to diagnose.

The plan at a glance

1. Inventory everything the site and domain depend on.
2. Lower DNS TTLs, a day or two ahead.
3. Build the new environment and copy the site.
4. Test the new server using your computer's hosts file, before DNS changes.
5. Prepare SSL on the new server.
6. Freeze content, do a final sync, and cut over DNS.
7. Monitor, keep the old server running, and roll back if needed.
8. Clean up after the old DNS caches have expired.

Step 1: Inventory what you have

Write down every dependency before touching anything.

• Web files and databases. Where they live, and their sizes.
• Server configuration. PHP version and extensions, web server rewrite rules, cron jobs, environment variables.
• DNS records. Export or screenshot the entire zone. Include A, AAAA, CNAME, MX, TXT (SPF, DKIM, verification records) and any subdomains. Check with the DNS Checker and MX Lookup.
• Email. Where mail is hosted. If email runs on the old host, it needs its own migration plan.
• Third-party integrations. Payment gateways, APIs, and services that whitelist your server's IP address, which will change.
• SSL certificates. How they are issued and renewed.

Run the Website Hosting Checker to confirm which host and IP the site currently resolves to.

Step 2: Lower TTLs ahead of time

DNS resolvers cache your records for as long as the TTL says. If your A record has a TTL of 86400 (24 hours), some visitors will keep reaching the old server for up to a day after the change. Lower it first, and wait at least as long as the old TTL before cutting over.

# See the current TTL (second column)
dig +noall +answer example.com A
dig +noall +answer www.example.com CNAME

Set the TTL on the records you will change to something short, commonly 300 seconds (5 minutes), at least one full old-TTL period before the migration. After migration is stable, raise it again. For background see TTL explained and how long DNS propagation takes.

Step 3: Build and copy to the new host

Set up the new server with matching software versions where possible. Version differences, especially PHP, are a leading cause of post-migration errors.

Copy files, preserving permissions and timestamps:

rsync -avz --progress -e ssh user@old-server:/var/www/example.com/ /var/www/example.com/

Export and import the database. For InnoDB tables, --single-transaction produces a consistent dump without locking:

# On the old server
mysqldump --single-transaction --routines --triggers -u dbuser -p dbname | gzip > dbname.sql.gz

# Transfer, then on the new server
scp dbname.sql.gz newserver:/tmp/
gunzip < /tmp/dbname.sql.gz | mysql -u dbuser -p dbname

Update configuration on the new server, for example database credentials in wp-config.php, and re-create cron jobs. For WordPress sites, see WordPress WP-Cron explained.

Step 4: Test the new server with a hosts file

You can view the site on the new server before DNS points there by making only your computer resolve the domain to the new IP.

On macOS and Linux, edit /etc/hosts; on Windows, edit C:\Windows\System32\drivers\etc\hosts as administrator:

203.0.113.50  example.com www.example.com

Flush your browser or OS DNS cache if needed, then browse the site. Everyone else still sees the old server. Command-line testing needs no file edit:

curl -sI --resolve example.com:443:203.0.113.50 https://example.com/
curl -s  --resolve example.com:443:203.0.113.50 https://example.com/ | head

Test thoroughly: homepage, deep pages, logins, forms, search, checkout, media, redirects, and cron-triggered jobs. Check the PHP and web server error logs on the new host while you test. Also compare responses between old and new for key URLs with the HTTP Status Checker.

Step 5: Prepare SSL before cutover

Visitors who land on the new server must see a valid certificate from the first request.

• Certificate already available? Copy or import it, if your CA and private key setup allow it.
• Let's Encrypt? HTTP-01 validation needs the domain to resolve to the new server, which hasn't happened yet. Use DNS-01 validation if your DNS provider has an API, or issue the certificate immediately after cutover and accept a short window, or use a certificate from your host's panel that supports pre-validation. Check your ACME client's documentation.
• Behind Cloudflare? Make sure the origin certificate is valid for Full (strict). See Cloudflare setup: DNS and SSL modes.

Verify after the switch with the SSL Checker. Renewal automation is covered in how to renew SSL certificates and automate it.

Step 6: Cut over

Minimize the window in which old and new differ.

1. Freeze content changes on the old site: put WordPress or your CMS into read-only mode, pause new orders, or schedule the cutover at a quiet hour. See website maintenance mode done right for how to do this without hurting SEO.
2. Do a final sync of files and database from old to new.
3. Update the DNS records. Change the A (and AAAA, if used) records for the apex and www to the new IP. Change only the web records.
4. Leave MX and mail-related TXT records alone, unless you are also moving email (see below).
5. Remove the hosts-file entry and test again from normal DNS.

Check propagation from multiple resolvers:

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8
dig +short example.com @9.9.9.9

The DNS Checker shows what different regions see. Expect some visitors on the old IP for the length of the TTL you set. To keep both servers consistent during that period, either keep the old site running as read-only, or proxy it to the new one.

Email records: the silent casualty

Websites move; email often should not. If mail is hosted elsewhere (Google Workspace, Microsoft 365, or a mail host), then:

• Keep MX records exactly as they are.
• Keep SPF, DKIM, and DMARC TXT records intact. See SPF, DKIM and DMARC complete guide.
• If the old host sent mail from the website (contact forms, order emails), update SPF to authorize the new server's IP or your mail service. See transactional email DNS checklist.
• mail.example.com style hostnames that pointed at the old server may need updating.

If email was hosted on the old web host, migrate mailboxes and keep the old account active until the MX change is complete and tested. Check final results with the MX Lookup and Email DNS Checker.

Step 7: Monitor and keep a rollback path

Rollback is simply pointing DNS back to the old IP, and it only works if the old server is still alive and current. So:

• Do not cancel the old hosting until traffic to it has stopped and you've been stable for a while. A week or more is a sensible margin.
• Watch the new server closely. Set up an uptime monitor before cutover, with alerts to your phone. Add a keyword check on a page that depends on the database so a broken connection is caught, not only a 200 status.
• Watch logs on both servers. Traffic arriving at the old server tells you who still has cached DNS.
• Check error rates in analytics and in the new server's logs for 404s, 500s, and slow requests.

If something critical breaks, revert the DNS records. With a short TTL, most visitors return to the old server within minutes. Be aware that if the new server accepted writes (orders, comments), you'll need to reconcile the data.

Step 8: Clean up

After a few days of stable operation:

• Raise TTLs to a normal value.
• Remove stale records and hosts-file entries.
• Confirm backups run on the new host and test a restore.
• Update monitoring, status pages, and any IP allowlists.
• Cancel the old hosting, after you've exported a final backup.

Next steps

• Review your DNS with the DNS Checker before and after.
• Set up the Uptime Monitor before cutover.
• Verify mail with the MX Lookup.
• Read change nameservers without downtime if DNS is moving too.
• Know what to expect from how long DNS propagation takes.

FAQ

How long should I lower the TTL before a migration?

At least as long as the existing TTL. If it is 24 hours, lower it at least a day before the cutover so resolvers have picked up the shorter value.

Will there be any downtime at all?

Done properly, visitors see either the old or the new server, both working. Brief inconsistencies can occur while caches expire, which is why you keep both servers live and freeze content during the switch.

Can I test the new server before changing DNS?

Yes. Add the new IP to your hosts file, or use curl --resolve, and browse the site as if DNS had changed. Only your machine is affected.

What if I use Cloudflare?

Change the origin IP in the proxied record. Changes take effect quickly since visitors resolve to Cloudflare, not your server, but still test the new origin first and confirm its certificate matches your SSL mode.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.