What to Check Before You Move Your Website to a New Host

Files are the easy part. What breaks when you move your website to a new host is mail that follows the MX record the instant DNS changes, a TTL nobody lowered a week in advance, a database dumped while orders were still being written to it, and a certificate that does not exist yet on the far end. All four are preventable, and all four only before cutover. Order matters more here than thoroughness does.

Two of the steps below have a lead time measured in days. A move planned on Monday and executed on Monday has already missed them. And if you have not settled that leaving is the right call, whether your site has outgrown shared hosting is the question sitting underneath this one.

What Is Actually Moving, and What Cannot Come With You

Inventory first. Write down what the old account actually holds: public files, the database or databases, mailboxes with every forwarder and alias attached, scheduled jobs, the DNS zone, the certificate, and possibly the domain registration, which may sit with a different company than your hosting.

Print the crontab and read it line by line. Half of it is dead, one entry is doing something load-bearing that nobody documented, and every path in it will be wrong on the new host.

Then the things that do not move at all:

• The server IP address. Anything that allowlists you by IP breaks at cutover: payment gateways, a partner API, a remote database, an office firewall rule. Several take a support ticket and a few business days, so find them first.
• The sending reputation attached to that IP. Receiving mail servers know the old address and have no opinion yet about the new one.
• Server software versions. Run php -m on both hosts and compare the output. A missing extension is a site that fails at import time rather than at launch time.
• Free automated certificates, which are reissued rather than copied.

Email Is the Trap

Read this section twice. Mailboxes are files on the old host's mail server, and changing the MX record does not move a single byte of them. It changes where new mail is delivered, instantly, for everybody. Old mail stays exactly where it was.

For anyone on IMAP the consequence is severe. Their mail lives on the server and the client is only a window onto it, so repoint that client at a new and empty mailbox and eleven years of archive appear to have been deleted. They have not been. But you will spend the afternoon explaining that.

Copy the mail with imapsync, which reads from one IMAP server and writes to another while preserving folders, flags, and dates. Run it twice: once several days ahead for the bulk, then again after cutover to catch the delta.

A sync copies messages and nothing else, so recreate the rest by hand before DNS moves:

1. Every mailbox, at the same address, with a password somebody actually has.
2. Forwarders and aliases, including the ones pointing at outside addresses.
3. The catch-all, if you use one, and any autoresponders that are supposed to be running.
4. Server-side filter rules, which are invisible until the day they stop filing anything.

Then the records that authenticate your mail. SPF has to name the new sending host or outbound mail starts failing at the receiver, and during the overlap a record authorizing both hosts is correct and normal. DKIM is signed by a private key on the sending server, so the new host generates its own pair and the public half in DNS has to be replaced. Read your DMARC record before cutover, not after it starts rejecting your invoices.

Verify by mailing an address you control somewhere else and reading the raw headers. Authentication-Results should show spf=pass and dkim=pass.

One thing not to do: migrate mail by having everybody re-download it into a desktop client. It feels simpler, and it leaves you with five divergent archives on five laptops and nothing to reconcile them against when a machine dies in November.

Lower the DNS TTL Days Before You Need It

A TTL is the number of seconds a resolver may keep serving a cached answer, and it is set by the record you published last, not the one you publish next. That is the whole problem. Lower it today and a resolver holding yesterday's record with a 24 hour TTL will keep handing out the old address for another 24 hours, cheerfully, no matter what your zone now says.

So the first action, before you copy one file, is to drop the TTL on your A, AAAA, and MX records and wait out the old value. Five minutes is a reasonable target.

dig +noall +answer example.com A

Run that against a public resolver and the TTL column counts down on each query until the cache expires and the number resets to whatever you published. Then that resolver is current.

Raise it back after a week of stability. The short value exists to buy you a fast rollback, and once you no longer need one it is just extra query volume against your nameservers.

If you are changing nameservers rather than editing records in a zone you keep, the delegation TTLs at the registry apply instead, and those are longer and not yours to set. Move records, not nameservers, unless you actually want the new host running your DNS.

The Order to Move a Website to a New Host

The first two steps are the ones that cannot be compressed into the day of the move, because both of them involve waiting on somebody else's cache or somebody else's ticket queue.

1. Lower the TTLs. Wait out the old value.
2. Inventory everything, and open the tickets for IP allowlist changes.
3. Create the mailboxes, forwarders, aliases, and filters on the new host.
4. Copy the files, and run the first bulk imapsync pass.
5. Get the certificate sorted on the new host.
6. Freeze writes, take the database dump, import it, verify it.
7. Test the new host from your own machine while the world still sees the old one.
8. Change the DNS records. Watch both servers.
9. Run the second imapsync pass to collect the delta.
10. Leave the old account running.

If Anything Can Write During the Dump, the Dump Is Wrong

A dump taken from a live site produces a file where one table was read at 10:00 and another at 10:04. If a customer ordered in between, the order header exists and its line items do not, and you discover this weeks later when a report refuses to balance.

For InnoDB tables, mysqldump --single-transaction reads everything inside one consistent snapshot without locking the site. The flag does nothing for MyISAM. Check what you have first:

sql SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'yourdb';

Mixed engines mean the snapshot covers part of your data, which is worse than no snapshot at all, because it looks like it worked. Add --default-character-set=utf8mb4 to both the dump and the import, or apostrophes and accented names arrive as mojibake and you get to find each one by hand.

For a small site the honest answer is simpler. Maintenance mode for ten minutes, dump while nothing can write, import, done. Nobody buys anything at 3am on a Tuesday.

After the import, compare SELECT COUNT(*) on your three largest tables against the old database. Matching counts are not proof of a good migration. Differing counts are proof of a bad one.

How Do You Test a Site That DNS Does Not Point At?

You point your own machine at the new server while everybody else still reaches the old one. Add a line mapping the domain to the new IP address in the hosts file, C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on macOS and Linux. Your browser now resolves to the new host. Nobody else is affected. For a single request without editing anything, curl does the same job with --resolve:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Test what touches PHP and the database, not the front page. A cached homepage will render beautifully on an installation whose database credentials are wrong. Log in. Submit a form and confirm the mail arrives. Run a search, upload an image, and if you sell anything, put a real order through. Then open the error log and read it, because a page that renders can still be throwing warnings on every request.

Failures at this stage are almost always paths and credentials: an absolute filesystem path baked into a config file, a database host that was localhost on one server and is not on the other, a cron entry pointing at a directory that does not exist yet.

The Certificate Ordering Problem

Automated issuance over the HTTP challenge requires the new server to answer requests for the domain, which it cannot do until DNS points at it. The clean way out is the DNS-based challenge, which proves control with a TXT record and works before any traffic moves. Failing that, a purchased certificate can be installed at any point, because issuance does not depend on where the domain currently resolves. Issuing after cutover and living with the gap is only defensible on a site nobody is buying from.

If you are buying, SSL certificates are sold per domain, and the reference page on how they work covers the validation types.

One hard edge. A site that sends an HSTS header with a long max-age cannot be loaded over a missing or invalid certificate by any browser that has already seen that header, and there is no button to click through. Under HSTS, the certificate is a launch requirement.

Keep the Old Host Running Longer Than Feels Necessary

Thirty days, minimum. This is the cheapest insurance in the process: the moment that account is cancelled, everything you did not know you needed goes with it, backups included.

Stragglers keep arriving at the old address for longer than the TTL math suggests, mostly from networks that cache aggressively. Monthly jobs have not run yet either. A quarterly invoice run, or a report that fires on the first, has not proven itself on the new host.

Watch the old server's access log after cutover. When the only traffic left is crawlers and scanners, real users have finished migrating. That is the signal, not the calendar.

Before cancelling, pull the files, a database dump, and the mail store down to storage that belongs to neither host, because cancellation usually takes the backups out with the account. Check the renewal date while you are in there.

What You Cannot Undo

Moving the domain registration. Under the ICANN Transfer Policy, a domain is locked against transfer for 60 days after a registrar transfer, and a change to the registrant contact can trigger the same lock. Treat domain registration as its own project on its own calendar, and never let a transfer be in flight during cutover, because you may lose the ability to edit DNS while it is.

DNSSEC plus a nameserver change. If the zone is signed and you move nameservers without coordinating the DS record at the registry, validating resolvers do not serve stale answers. They refuse to resolve it at all. Disable DNSSEC before the move, re-enable it after.

Cancellation. The backups go out with the account.

Deleting old mailboxes before the second sync pass has run and somebody has confirmed their folders look right.

Start with the TTL today, even if you have not chosen the new host yet. It costs nothing, and it is the only step here with a waiting period you cannot compress. Whether a problem on cutover day takes five minutes to reverse or the rest of the afternoon gets decided a week earlier, by that one number.