How to move a website to a new host without downtime

A website move goes smoothly when the new server is ready and tested before visitors are sent to it. This guide gives you the order of work, from the inventory and DNS preparation to the switch and the clean-up, plus the details that usually cause trouble: databases, SSL and email.

Before you start

You need:

• SSH or control-panel access to the old host and the new server, with the software your site needs installed on the new one (web server, PHP or another runtime, database server).
• Access to the place where your DNS is managed, which may be your registrar, your old host or a DNS provider.
• A maintenance window for the final sync, ideally at a quiet hour.

Make an inventory of everything the old host does for you:

• Website files, including uploads and anything outside the web root that the site reads.
• Databases, with the user names and passwords the site uses.
• Email: mailboxes, forwarders and the MX records that route mail to them.
• DNS records: A and AAAA, CNAME, MX and TXT records such as SPF, DKIM, DMARC and site verifications.
• Scheduled tasks (cron jobs), background workers and the software versions the site needs, such as the PHP version and its extensions.
• SSL certificates, redirects and rewrite rules.

If the domain uses the old host's nameservers, every record must be recreated at the new DNS host before you switch.

The timeline

Step 1: Lower the TTL

Resolvers cache each record for as long as its TTL allows. Check the current TTL; it is the number after the name:

dig +noall +answer example.com A

At your DNS host, lower the TTL of the A, AAAA (and, if email moves, MX) records to 300 seconds. Do this at least one old TTL before the move, so resolvers forget the long value in time.

Verify: after the old TTL has passed, the dig command shows 300 or less.

Step 2: Copy the files

From the new server, pull the files over SSH with rsync. Replace the address and paths with yours:

rsync -avz -e ssh olduser@198.51.100.20:/var/www/example.com/ /var/www/example.com/

The trailing slashes copy the contents of the folder. rsync only transfers what changed, so the final sync later is quick. Make sure the files belong to the user your web server or PHP runs as on the new server.

Step 3: Copy the databases

On the old server, export each database. --single-transaction takes a consistent copy of InnoDB tables without locking the site:

mysqldump --single-transaction --routines --triggers -u dbuser -p dbname > dbname.sql

mariadb-dump --single-transaction --routines --triggers -u dbuser -p dbname > dbname.sql

Copy the file to the new server (for example with scp or rsync), create the database and its user there, then import:

mysql -u dbuser -p dbname < dbname.sql

mariadb -u dbuser -p dbname < dbname.sql

Update the database host, name, user and password in the site's configuration file if any of them changed.

Step 4: Test without touching DNS

Point only your own computer at the new server by adding a line to your hosts file:

203.0.113.10 example.com www.example.com

The file is /etc/hosts on Linux and macOS and C:\Windows\System32\drivers\etc\hosts on Windows (edit it as administrator). Clear your computer's DNS cache so the change takes effect:

ipconfig /flushdns

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo resolvectl flush-caches

Now check pages, forms, logins, the checkout and outgoing email. Verify: the web server's access log on the new server shows your requests. Remove the hosts line when you are done.

Step 5: Prepare SSL

Visitors should never see a certificate warning. Free Let's Encrypt certificates are usually validated over HTTP, which needs the domain to point to the new server, so they are issued right after the switch. If you need the certificate before switching, use DNS validation, which works wherever the domain points, or copy the existing certificate and its private key to the new server for the first days. See install an SSL certificate.

Step 6: Freeze, sync and switch

1. Pause content changes, orders and sign-ups, for example with a maintenance mode.
2. Run the rsync command from Step 2 again, then export and import the databases once more.
3. Change the A record (and the AAAA record if you use IPv6) to the new server's address, or change the nameservers if the whole DNS zone moves. See point a domain to your server.
4. Lift the freeze on the new server.

Verify: dig +short example.com A returns the new address, and the old server's access log goes quiet as cached answers expire.

Step 7: Move email (if it moves)

Create the mailboxes on the new server before you change the MX records, then copy the existing messages with an IMAP migration tool. Keep the old mailboxes for a few days after the switch, because some senders still deliver to the old server until their DNS caches expire. Recreate the SPF, DKIM and DMARC records for the new mail server, or outgoing mail may be rejected. See email deliverability.

Moving a WordPress site

WordPress stores its address in the database, including inside serialized settings. When the domain stays the same, a straight copy of files and database is enough. If the address changes, replace it with WP-CLI, which understands serialized data. Try a dry run first:

wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid

Update the database details in wp-config.php and clear every cache layer after the move: plugin caches, the web server cache and any CDN.

Step 8: Retire the old host

When the old server receives no more traffic or mail, usually after about a week, take a final backup and cancel it. Raise the TTL of your records again, for example to 3600 seconds.

Troubleshooting

Some visitors still reach the old server. Their resolver cached the old record. Wait for the old TTL to pass; keep the old server running until then.

The site shows a database connection error. The database name, user, password or host in the configuration file does not match the new server. Test the login with mysql -u dbuser -p dbname.

Pages work, but images or styles are missing. File permissions or ownership on the new server, or absolute URLs that still point to the old address.

Mail goes missing after the switch. Check that the MX records point to the new mail server and that the old mailboxes are still being checked for a few days.

Next steps

• Understand the records you are changing: DNS basics for a new domain.
• Secure the new server: secure a new Linux server.
• Moving to HyperDC? Contact us and tell us what you run.