Website Migration Checklist: Switch Hosting Without Downtime

Moving a website to a new host doesn’t have to involve downtime, lost email, or damaged rankings. The technique is simple: lower your DNS TTL a day early, build the site on the new server while the old one still serves visitors, test it before switching, and only then change the nameservers. Do it in that order and visitors never see a gap — because at every moment, one of the two servers has a working copy.

The mistakes that hurt are almost always about sequence, not skill: cancelling the old host too early, changing nameservers before testing, or forgetting that email propagates on its own slower schedule. This checklist is organised by phase, so you can work through it in order.

First: which migration are you actually doing?

This matters more than any single step, because “website migration” covers four very different projects with very different risks. Most checklists blur them together and make a simple host change sound terrifying.

If you’re only changing host — the most common case by far — you can relax about SEO. Google sees the same domain serving the same URLs; the server behind them is invisible to it. What you need to get right is the DNS sequence and the email, and that’s it. The heavy SEO work in most migration guides applies to the bottom two rows.

If your migration involves a new domain or new URLs, do that as a separate project, ideally weeks apart from the host change. Combining them means that when something breaks you won’t know which change caused it.

The one rule that prevents disasters

Phase 1: before you touch anything

Lower your DNS TTL. Do this first, 24 to 48 hours before the rest. Set the TTL on your A and CNAME records to 300 seconds. TTL is how long resolvers cache your records, so lowering it in advance means that when you do switch, the change propagates in minutes instead of hours. Our guide on DNS propagation explains the timings for each record type — and note that nameserver (NS) records are the slowest of all, which is why the parallel-server approach below matters.

Take a full backup, and store it twice. Files and database, in two separate places — your computer and cloud storage. Never a single copy. Then test that it restores; an untested backup is a hope, not a backup.

Inventory what you actually have. This is the step people skip and regret:

• Every DNS record on the current setup — A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), and any custom records. Screenshot the whole zone.
• Every email account, plus forwarders, autoresponders and aliases.
• Cron jobs and scheduled tasks.
• Subdomains and any addon domains.
• PHP version and any non-default extensions or settings the site depends on.
• SSL certificate details, and where it came from.
• Where the domain is registered — often a different company from the host, and this trips people up.

Not sure who runs what? Our hosting checker shows the registrar, DNS provider, web host and email provider of any domain in one lookup.

Know the three things that can move independently. Domain registration, DNS hosting (the nameservers), and web/email hosting are three separate services. You might be changing only one. Being clear about which prevents most of the confusion in migration.

Phase 2: build the new site in parallel

The old host keeps serving visitors throughout this phase. Nothing is at risk yet.

• Set up the account on the new host and note its IP address.
• Upload files and import the database. On WordPress, this also means updating the database credentials in wp-config.php — our guide on migrating WordPress to a new host covers the whole process, including the serialized-data trap if you’re also changing domain.
• Match the environment — same PHP version to start with, so you’re not debugging two changes at once.
• Recreate every DNS record from your inventory in the new host’s zone, before switching. Forgetting a TXT record here is how SPF breaks and email starts going to spam.
• Install the SSL certificate on the new server. Most hosts issue a free one; our guide on what an SSL certificate is covers the types.

Then test it privately — the step that makes zero downtime possible

You can view the site on the new server, before any DNS change, by overriding DNS locally on your own computer. Add a line to your hosts file pointing your domain at the new server’s IP:

Save, then flush your DNS cache and load the site. You’re now seeing the new server while the rest of the world still sees the old one.

Test properly while you’re there: internal pages, forms, login, checkout, search, images, and anything that talks to a third party. Then remove those lines when you’re done, or you’ll be looking at the new server forever and wondering why everyone else sees something different.

Phase 3: the cutover

Only when the new server passes testing:

1. Do it at a quiet hour for your audience — low traffic means fewer people affected if something needs a second attempt.
2. Change the nameservers at your domain registrar to the new host’s, or update the A record if you’re keeping the same DNS provider.
3. Don’t touch anything else for a few hours. If a problem appears now, you want to know it came from the switch.

Because both servers are running and serving the same site, visitors landing on either one get a working page during propagation. That’s the whole point of the parallel approach: propagation stops being downtime and becomes just a period where two identical servers answer. To follow the switch, run our DNS propagation checker with the new server’s IP: it shows which resolvers already return it and how long the others will keep the old one.

Phase 4: email — the part that actually breaks

Email is the most fragile part of any host migration, and the reason is timing. MX records keep their own TTL, and if you lowered it only on the A and CNAME records, senders can keep the old MX cached for hours after the website has moved. If the move also changes your nameservers, every record, MX included, can take up to 48 hours to reach everyone.

During that window, messages sent to you may be delivered to either server, depending on which cached MX record the sender’s mail system happened to have. Mail arrives split across two mailboxes, and if you’ve already shut the old one down, some of it simply bounces.

What to do:

• Create every mailbox on the new host before the cutover, with the same addresses. Our guide on creating email accounts in cPanel covers the process.
• Recreate forwarders, aliases and autoresponders — these are easy to overlook and nobody notices they’re missing until a form stops reaching anyone.
• Copy existing mail across if you need the history. Using IMAP on both accounts in a desktop client and dragging folders across works for a handful of mailboxes; larger migrations warrant asking your host. Our guide on email migration covers the methods and the two-pass sync that prevents lost messages.
• Keep both mailboxes reachable for at least a week, and check both. This is the concrete reason not to cancel the old host early.
• Re-add the SPF, DKIM and DMARC records on the new host. Miss these and your outgoing mail starts landing in spam — a problem that’s easy to fix and easy not to notice for weeks.

Phase 5: verify, then monitor

Once propagation settles:

• Confirm you’re actually on the new server — check the IP your domain resolves to, or look for a host-specific header. Don’t assume.
• Check HTTPS works and that the certificate is valid for both the bare domain and www. If you’re also enforcing HTTPS, our guide on redirecting HTTP to HTTPS covers doing it with a single clean redirect.
• Test email in both directions — send and receive, and check that a message from an outside address arrives.
• Walk the site as a visitor: forms, login, cart, search, and any integration.
• Watch for errors in the first days. A migration that “worked” can still surface a wrong PHP version or a missing extension under real traffic — and ERR_CONNECTION_TIMED_OUT or a 500 appearing right after a migration usually points at a configuration detail that didn’t come across.
• Check Search Console for a crawl-error spike. On a host-only migration there shouldn’t be one; if there is, something didn’t transfer.

If you’re also changing domain or URLs

This is where the real SEO work lives, and it’s a different project from moving hosts.

• Map every old URL to its new equivalent before you start. Not the homepage — the actual matching page.
• Use 301, never 302. Getting this wrong is the most common technical SEO mistake in a migration: a 302 tells search engines the move is temporary, so the new URL never inherits the authority of the old one. Our guides on HTTP 301 and 301 vs 302 cover the distinction.
• One hop per redirect. Chains dilute signals and slow everything down.
• Update internal links to point at the new URLs directly rather than relying on the redirects.
• Submit the new sitemap in Search Console and monitor indexing for at least a month.
• Keep the redirects in place indefinitely. They’re not temporary scaffolding.

The shortcut: let your host do it

Having read the list above, here’s the honest advice: for most sites, the best migration process is handing the credentials to your new host.

Free migration is standard at any decent provider, and they have two advantages you don’t. They do this constantly, so the steps that are unfamiliar to you are routine to them. And they control the destination server, so when something needs adjusting — a PHP version, a missing extension, a permissions problem — they fix it directly instead of describing it to support.

It’s worth doing yourself if you want to understand your stack, if the site is unusual enough that a generic process won’t fit, or if you simply prefer control. Otherwise, the checklist above is mostly useful as a way to verify the migration your host performed — which is the version of it you should actually run.

Frequently asked questions

How long does a website migration take?
The work itself is usually an hour or two for a typical site. DNS propagation is what adds time: A records typically settle within an hour or two if you lowered the TTL beforehand, while nameserver and MX changes can take 24 to 48 hours. The site stays reachable throughout if you keep both servers running.

Will migrating hosts hurt my SEO?
Not if you’re keeping the same domain and the same URLs. Search engines see identical addresses serving identical content, and the server behind them isn’t a ranking factor. SEO risk comes from changing the domain or URL structure, which needs a full 301 redirect map and should be treated as a separate project.

How do I migrate a website without downtime?
Lower your DNS TTL a day or two in advance, build the site on the new server while the old one still serves traffic, test the new server privately by editing your computer’s hosts file, then change the nameservers. Because both servers hold a working copy during propagation, visitors always reach a functioning site.

When should I cancel my old hosting?
At least a week after the switch, and two weeks is safer. The old account is your rollback if something goes wrong, and it also catches email delivered to the old server while MX records are still propagating. The cost of one extra month is trivial next to the cost of needing it and not having it.

What about my email during a migration?
Email is the most fragile part. Create every mailbox on the new host before the cutover, recreate forwarders and aliases, re-add your SPF, DKIM and DMARC records, and check both old and new mailboxes for at least a week — because during MX propagation messages can arrive at either server.

Do I need to transfer my domain to migrate hosting?
No. Domain registration, DNS and hosting are three separate services. To move hosts you only need to point your existing domain at the new server, usually by changing the nameservers at your current registrar. Transferring the domain itself is optional and best done separately.

Should I migrate my site myself or let the host do it?
For most sites, let the host do it — free migration is standard, and they do it routinely with full access to the destination server. Doing it yourself makes sense if you want to understand your setup or the site is unusual. Either way, run the verification steps yourself afterwards.

Conclusion

A host migration goes wrong for reasons of sequence, not difficulty. Lower the TTL before you need it, build the new server while the old one is still working, test privately with your hosts file, switch the nameservers, then give email a week to settle before you cancel anything. Done in that order, there’s never a moment when no server has a working copy of your site — which is what “zero downtime” actually means in practice. And if you’re only changing host, not domain or URLs, the SEO worry that dominates most migration guides doesn’t apply to you at all. Get the DNS timing and the email right, keep the old account as a parachute, and the rest is just checking.