Moving a site to a new host doesn't have to involve a maintenance page. Downtime during a move nearly always comes from doing things in the wrong order: changing DNS before the new server is proven, shutting the old one down too early, or discovering a missing certificate or mail record after visitors arrive. Run both servers side by side, test the new one privately, and make the DNS change the last and least dramatic step.
Before copying a single file, record what the domain currently points where. Export the full DNS zone from your current provider if it allows it, and check the records one by one with our DNS lookup tool. Pay attention to:
www. Forgetting the AAAA is a classic cause of "it works for me but not for them".shop., api., mail. or cdn. that point elsewhere.Also note what the server does that isn't in DNS: cron jobs, redirect rules in .htaccess or the web server config, environment variables, and the PHP, Node or database versions the site expects.
The TTL on your current records controls how long resolvers will keep sending visitors to the old server after you switch. Lower it to 300 seconds on the records you'll change, then wait at least one full old TTL before moving anything. If the current TTL is a day, do this at least a day ahead. The reasoning and the traps are in DNS TTL explained.
Set up the new host to match the old environment, then copy the files. rsync is ideal because you can rerun it later to pick up only what changed:
rsync -avz [email protected]:/var/www/example/ /var/www/example/The trailing slashes matter: they copy the directory's contents rather than creating a nested folder.
For a MySQL or MariaDB database, a consistent dump without locking InnoDB tables looks like this:
mysqldump --single-transaction --routines --triggers -u dbuser -p exampledb > exampledb.sql
mysql -u dbuser -p exampledb < exampledb.sqlRun the dump on the old server and the import on the new one. Then update the site's configuration with the new database credentials and hostnames.
This is the step that removes the risk. You can make your own computer visit the new server under the real domain name without changing public DNS.
With the hosts file. Add a line mapping the domain to the new server's IP (here 203.0.113.10):
203.0.113.10 example.com www.example.comThe file is /etc/hosts on macOS and Linux and C:\Windows\System32\drivers\etc\hosts on Windows. Browse the site normally, log in, submit a form, check images and admin pages. Remove the line when you're done, or you'll be confused later.
With curl. For quick checks without editing anything, --resolve pins a name to an address for one request:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/Look for a 200 (or your expected redirect) and the right headers. Test the www version and a few deep URLs too.
If the new server has no valid certificate when visitors arrive, they get a browser warning, which counts as downtime. There's a chicken-and-egg problem here: Let's Encrypt's default HTTP-01 challenge fetches a file from your domain on port 80, so it only succeeds once the domain points at the new server.
Three ways round it:
_acme-challenge.example.com, which works regardless of where the A record points. Most ACME clients support it through your DNS provider's API./.well-known/acme-challenge/ requests to the new one.Once installed, check it through the hosts-file trick, then after the move confirm it with our SSL checker, which shows the chain and expiry date.
For a static site you can switch whenever you like. For anything with a database (a shop, a CMS with comments, a membership site) you need a short content freeze, or orders placed on the old server will be lost.
rsync and take a fresh database dump and import. This final sync is fast because only changes move.If you're also changing DNS provider (moving name servers, not just records), do that as a separate step, days before or after. Recreate the entire zone at the new provider first and compare it record by record. If DNSSEC is enabled, the DS record at your registrar must match the new provider's keys, or validating resolvers will fail to resolve the domain at all. The safe route is to remove the DS record, wait for it to expire, move, and then re-enable DNSSEC at the new provider.
Some resolvers ignore low TTLs, and some visitors will reach the old server for a while. Leave it running for a few days at least. A useful trick is to have the old server proxy or redirect traffic to the new one, so anyone still arriving there lands on current content.
Before cancelling, check the old server's access logs. When real traffic has dwindled to bots, and email is confirmed working on the new setup, you're done. Our post on DNS propagation covers why a straggler resolver or two is normal.
The work itself can be a few hours. The waiting sets the schedule: lower the TTL at least one full old TTL beforehand, and keep the old server around for a few days after. Plan for about a week from start to finish.
A clean move with the same URLs and content, and no period of errors, is a change search engines handle routinely. Rankings suffer when pages return errors, URLs change without redirects, or the site is unreachable during the switch.
No. The registrar, the DNS provider and the web host are three separate roles, even when one company sells all three. You can move the site and leave the domain registration exactly where it is.
Point the records back at the old server. Because you kept the TTL low and the old server running, a rollback takes effect as quickly as the original change.
0 comments
No comments yet. Be the first.