How to migrate web hosting
The honest switching-cost reality: copying the files is trivial; doing it without downtime, a broken SSL, or a dead inbox is the actual skill. Here's what breaks, why email is the trap that catches everyone, and the exact order that gets you onto a new host with zero outage.
The files are the easy part — DNS and email are where it goes wrong
Moving a website's files and database is a solved problem; most hosts and every managed provider will do it for you. The two things that actually take sites down during a migration aren't the files at all. The first is DNS: if you flip your records or delete the old site before the new one is built and verified, visitors hit nothing while the change propagates. The second is email — if your mailboxes live with your current host, changing MX records can silently kill your inbox and bounce messages you never see.
So the whole game is sequence. Build a complete, tested copy on the new host first. Lower your DNS TTL a day ahead so the cutover is fast. Sort email as its own job, not an afterthought. Re-issue the SSL certificate, re-create your redirects and cron jobs, and only then point DNS. Managed hosts like Kinsta and WP Engine offer free migration that handles the file-and-database copy, but you still own the testing, the email, and the DNS flip. Line the move up with what you chose in how to choose web hosting, and plan around the cutover, not the copy.
The five phases of a hosting migration
List everything that carries value and risk: where your domain is registered, your files and databases, every email mailbox and its MX records, your SSL certificate, your .htaccess or nginx redirects, cron jobs, the PHP version your site runs on, and any subdomains or apps. Finding out where email actually lives now is what saves you from the classic dead-inbox surprise later.
A day before cutover, drop your DNS TTL (to 300 seconds) so the switch propagates in minutes, not a day. Then copy files and the database to the new host and stand the site up there completely — still pointing your live domain at the old host. You now have a working duplicate to test before any visitor is affected.
Re-issue the SSL certificate on the new host (it doesn't travel), recreate your .htaccess or nginx redirect rules, set up cron jobs again, and match the PHP version — a version mismatch is a common cause of a site that copies fine but then throws errors. Config, not content, is where a hosting move quietly breaks.
If your email is hosted with the old provider, this is the step that loses people mail. Migrate mailboxes to the new host or a dedicated email service, keep both live with overlap, and plan the MX-record change alongside the site cutover — not before you've confirmed the new mailboxes receive. If email is on a separate service (Google Workspace, Microsoft 365), leave its MX records untouched and only change the site's A record.
Preview the new site by editing your local hosts file so only you see it live, and click through everything. When it's clean, flip the DNS at a low-traffic hour; with a low TTL it propagates fast. Keep the old host running for at least a week as your rollback, watch the new host handle real traffic and email, take a final full backup, then cancel before renewal.
The gotchas, named
It doesn’t have to, and avoiding downtime is the whole point of doing it in the right order. The trick is to build a complete working copy on the new host first, test it before you touch DNS, and lower your DNS TTL a day ahead so the cutover propagates in minutes instead of hours. If you delete the old site or flip DNS before the new one is verified, you get exactly the outage everyone fears. Migrate, verify, then switch.
Email. If your mailboxes are hosted with your current provider rather than a separate service, changing hosts and MX records can cut off your email and lose messages in transit. Email migration is a separate job from moving the website, and it’s the single most-missed step. Confirm where your email actually lives before you change a single DNS record, and migrate mailboxes deliberately with overlap so nothing bounces.
Usually not, and you shouldn’t in the same step. Your domain registration can stay where it is; you only repoint the DNS records (or nameservers) at the new host. Keeping the registrar separate from the host is actually good practice — it means switching hosts later is just a DNS change, not a domain transfer. If your domain is registered through the old host, consider moving it to an independent registrar as a separate, later task.
For a small static or brochure site, an evening plus DNS propagation. For a database-driven site with email, SSL, redirects and cron jobs, plan one to three days of work spread over a week to allow for TTL changes and propagation. Many managed hosts — Kinsta and WP Engine among them — offer free migration that compresses the hands-on part, but you still own testing, email and the DNS cutover.
Not until DNS has fully propagated, email is confirmed flowing on the new setup, and you’ve watched the new host handle real traffic for a few days. Keep the old account live for at least a week past the cutover — it’s your rollback if something surfaces. Take a full backup of files and database before you cancel, and confirm no stray services (email, cron, subdomains) still depend on the old host. Then cancel before the next renewal.
One email when the rankings move. The shortlist, the tradeoffs, the price changes. No filler.