Three things move independently, and only one of them is the website
Most migration failures come from treating a website move as one operation. It is three, governed by different systems:
- The domain registration — which company holds the name on your behalf. Moving this is a registrar transfer and has nothing to do with where the site lives.
- The DNS zone — which nameservers answer questions about your domain, and what records they hold: the address of the web server, the mail routing, the verification records for various services, and anything else that has accumulated over the years.
- The hosting — the files and the database that produce the actual pages.
When somebody says "we're migrating the website," they nearly always mean only the third item. Almost every failure comes from the second. The files copy across fine; it is the records that get lost, overwritten, or replaced wholesale by a new provider's defaults.
So the first thing we do is not a copy. It is an inventory: every domain and subdomain, the DNS zone exported to a file, the mail routing records and which provider they point to, every email account, the certificates in use, the scheduled tasks, and any third party that has your current server's IP address written down. Nobody discovers those by accident on cutover night.
The second is confirming registrar access. If nobody at the business can log in to the registrar, the migration cannot be completed, and that is a day-one discovery rather than a two-in-the-morning one.
Email is the hard part, not the website
If you remember one thing from this page: the most damaging migration failure is losing email, and it is entirely preventable.
It happens the same way every time. Somebody changes the nameservers rather than a single record, because that is what the new host's setup guide says to do. The new host's default DNS zone arrives complete with its own mail routing record pointing at a mail service on the web server, and mail addressed to the business begins landing in a mailbox nobody knows exists. Nobody notices for a day or two, because outbound mail still works. By the time somebody says "we never got your quote," several days of incoming mail have gone somewhere unhelpful, and it cannot be retrieved from the old provider because it never went there.
The prevention is one sentence: copy the mail routing records before anything changes, and leave them pointing exactly where they already point. If the mail is on Google Workspace or Microsoft 365, it stays on Google Workspace or Microsoft 365. Moving hosting is not a reason to move mail. If mail genuinely needs to move, that is a separate project on a separate day with its own plan and its own rollback.
The wider principle: nameserver changes are a blunt instrument. They move every record at once, including the mail routing, and they propagate at the registry's timetable rather than yours. Changing a single address record at your existing DNS provider is almost always the safer cutover, because it changes exactly the one thing you meant to change.
Why lowering the DNS TTL a week ahead is the whole trick
Every DNS record carries a TTL (time to live) — the number of seconds a resolver is allowed to keep a cached copy before asking again. Until the old record's TTL expires everywhere, some visitors keep reaching the old server. With a 24-hour TTL that means up to a day of split traffic, and any form submission or order placed on the old server is effectively lost.
The fix is to lower the TTL before the move. Google's own documentation on changing hosting says it plainly:
Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move to refresh DNS caches faster.
The reason it says a week and not an hour is the counterintuitive part people miss: the act of lowering the TTL is itself subject to the old TTL. If the current value is 24 hours, a resolver that cached the record an hour ago will not learn the new lower value for another 23. You have to wait out one complete old-TTL period before the low TTL is in force everywhere. Only then is a cutover a five-minute event rather than a day-long overlap.
In practice we lower the TTL to 300 seconds, wait out the previous value, cut over, verify, then raise the TTLs back up. Google's guidance on moving hosts without changing URLs is short and worth reading if you are managing this yourself.
The order of operations
In this sequence, a brochure-site migration involves no downtime worth naming.
- Inventory everything and export the DNS zone to a file you keep.
- Confirm registrar access on day one, without exception.
- Lower DNS TTLs to 300 seconds and wait out the previous value.
- Copy files and database to the new host. Delete nothing on the old one, and keep the old account paid and running for at least thirty days after cutover — the cheapest insurance in the process.
- Fix configuration on the new host: database name, user and password; file permissions and ownership; PHP version matched to the old host for now; rewrite rules; and scheduled tasks recreated at server level, because WordPress's built-in scheduler is not a real cron job.
- Test on the new server before DNS moves using a hosts-file entry, which makes your own machine resolve the domain to the new server while the rest of the world sees the old one. Preview URLs are a poor substitute, because a system with its address hardcoded in the database misbehaves on them.
- Search and replace hardcoded URLs in the database with a tool that understands serialized data. A plain SQL replace corrupts serialized arrays, and the damage is silent.
- Issue the certificate on the new host before cutover, using DNS validation, so there is never a window where visitors meet a warning.
- Cut over DNS, changing the address record rather than the nameservers wherever possible, and leaving mail routing untouched.
- Watch both servers' logs for 48 hours. Traffic still arriving at the old server means somebody is still resolving to it.
- Raise TTLs back up, then decommission the old account after thirty days — not the next morning.
What actually breaks
The list below is not hypothetical. It is what we find when we take over a site that somebody else moved.
- Hardcoded URLs in the database. Post content, theme options and page-builder blocks still referencing the old address or the old protocol. Symptom: broken images and links pointing at a site you no longer control.
- Mixed content. The page loads over HTTPS but pulls an image, script or stylesheet over plain HTTP. Browsers block the active kind outright, so parts of the page do not appear and the padlock disappears. Almost always those same hardcoded URLs.
- Database credentials. The configuration file was copied verbatim and the new host's database name, user and password differ. Symptom: "Error establishing a database connection," on every page.
- Serialized data corruption from a naive find-and-replace. Symptom: sliders, page-builder rows and theme settings blank for no visible reason.
- PHP version mismatch. A plugin calling a function removed in a newer version stops the page dead. Symptom: a white screen. Match the version first and upgrade PHP afterward, as its own change.
- File permissions and ownership wrong after a copy performed as the wrong user. Symptom: uploads and updates fail while the site itself looks fine.
- Rewrite rules lost, or written for one web server and inherited by another. Symptom: the homepage works and every other URL 404s.
- Scheduled tasks not recreated. Backups stop, scheduled posts stop, subscription renewals stop — silently, for weeks, which makes it the worst item here.
- Third-party allowlists still naming the old server's IP address: payment gateway callbacks, a supplier integration, a firewall rule at a distributor.
- Search Console verification broken because it relied on a file or DNS record that did not survive the move.
What Google says about a host move that keeps the same URLs
Owners worry about search rankings during a migration, usually more than they worry about the mail, which is the wrong way round.
Changing hosts while keeping the same domain and the same URLs is not a site move in Google's sense. There is no Change of Address to submit, no reconsideration request, and no waiting period. The only housekeeping is making sure your Search Console verification survives, whether it was an HTML file, a meta tag or a DNS record.
Google also tells you what normal looks like afterward, which saves a panicked phone call:
It's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch, followed by a steady increase over the next few days.
On when it is safe to switch the old server off: monitor both, and once traffic to the old provider reaches zero, the old infrastructure can be shut down.
One exception. If the move also changes your URLs — a new domain, a restructured path scheme — that is a site move in Google's sense, it needs redirects mapped one to one, and a domain change needs the Change of Address tool. Do not bundle that into a hosting move.
When you should not move hosts at all
We are the ones being paid to do the migration, so read this section knowing that.
If the site is slow because of the site rather than the server, moving changes nothing. Measure before you decide. If the server begins answering in a couple of hundred milliseconds but the largest element on the page takes six seconds to appear, the problem is a five-megabyte hero image and thirty-four active plugins, and it will be exactly as slow on any host on earth. Fixing it where it currently sits is the honest work, and Google's own documentation on server response time gives you the threshold to measure against.
Do not migrate a seasonal business during its season. For a marina, a bait shop, a rental operation or a lakeside restaurant on Cedar Creek Lake, moving hosts in June is risking revenue for a change no customer will ever notice. October exists.
Do not move email because you are moving hosting. If the mail works, copy the records and leave it alone. Two changes on one day is two chances to lose the thing hardest to get back.
Do not migrate a site that is about to be rebuilt. Build the new one on the new host and cut over once.
And if your current host is competent and inexpensive and your site is fine, there is nothing here to sell you. A migration should be triggered by a named problem, not a sales call: repeated unexplained downtime, PHP versions years past support, backups you cannot restore yourself, a support desk that will not read a log, or a host that treats your domain as leverage. If none of those describe you, stay where you are.
Common questions
How long will my website be down during a migration?
Done properly, it is not down at all. The files and database are copied to the new server and tested there before anything changes publicly, using a hosts-file entry so we see the new server while everyone else still sees the old one. The switch itself is a single DNS record change, and if the TTL was lowered a week in advance it takes effect within minutes. During the overlap both servers are serving the same site, so a visitor reaching either one gets a working page.
Will I lose email during the move?
Not if the mail routing records are copied first and left pointing where they already point. Mail loss happens when someone changes nameservers instead of a single record, and the new provider's default configuration silently redirects mail to the web server. Our default is that mail does not move during a hosting migration at all — if your email is on Google Workspace or Microsoft 365 and it works, it stays there, and we simply reproduce the existing records exactly.
Do I need to tell Google that I changed hosts?
No. A host change that keeps the same domain and the same URLs is not a site move as Google defines it, so there is no Change of Address to file and no waiting period. The only housekeeping is confirming that your Search Console verification survived the copy. Google notes that a temporary dip in crawl rate right after a launch is normal and recovers over the following days, so a wobble in the crawl stats report is not a reason to worry.
Can I cancel my old hosting as soon as the new site is live?
Please do not. Keep the old account paid and running for about thirty days after cutover. It is the cheapest insurance in the whole process: it preserves a rollback if something surfaces a week later, it keeps a copy of anything that was not migrated, and it means any visitor still resolving to the old server sees a working site rather than nothing. Cancel it after a month, once both servers' logs show no traffic reaching the old one.