A Practical Guide to Migrating Hosts Without Downtime

What 'zero-downtime migration' actually means

Migrating hosts without downtime means moving your site's files, databases, and email to a new server while the live version keeps running for visitors the entire time. You build and test an exact copy on the new host before you redirect your domain — so nobody ever hits a blank page or a 500 error.

That's the whole idea. It's simpler than most site owners expect. The real risk isn't the file transfer itself — it's the gap between cutting over DNS and confirming everything actually works. Nail that window, and the migration is invisible to your audience.

A pattern we keep running into: migrations that go sideways almost always skip the staging-and-verify step. Someone flips the DNS switch before the new environment is confirmed clean, and suddenly they're troubleshooting a broken site under live traffic. That's exactly the scenario this checklist is built to prevent.

Worth mentioning: a host migration is also a natural moment to look at your broader infrastructure. If your current setup is already contributing to slow load times, switching hosts alone won't fix it — check out our piece on why a slow site costs you rankings and sales before you finalize your new host choice.

Everything you must do before touching a single file

Preparation is where migrations are won or lost. Rushing into a file transfer without this pre-flight list is how businesses end up with corrupted databases, broken contact forms, and panicked Monday-morning support tickets.

• Audit your current environment. Document your PHP version, database type and version, any server-side redirects in your .htaccess or nginx config, and every third-party integration that talks to your server — payment gateways, CRMs, API webhooks. Missing one of these is the most common cause of 'the site looks fine but nothing works' post-migration.
• Take a verified, restorable backup. Not just a cPanel snapshot. Actually download the files and database dump to local storage and confirm you can open them. A backup you can't restore isn't a backup.
• Set up the new hosting account and install your stack. Match the PHP version, database server, and any required extensions to your current setup exactly — unless you're intentionally upgrading.
• Add a temporary hosts file entry on your local machine. This lets your browser resolve the domain to the new server's IP so you can browse and test the new site as if it were live, without affecting a single real visitor.
• Lower your TTL. At least 24-48 hours before you plan to switch, drop your DNS TTL to the lowest your registrar allows (often 300 seconds). This makes the final DNS cutover propagate far faster when you're ready.
• Identify your cutover window. Pick your lowest-traffic period — typically a weekday night. Pull up your analytics, find the quietest two-hour stretch, and plan around that.

How long does DNS propagation really take?

This is one of the most-searched questions around host migrations. The honest answer: it depends on your TTL. DNS propagation isn't a single global event — it's thousands of resolvers around the world refreshing their cache at different times, based on the TTL value your old record carried.

If you lowered your TTL to 300 seconds (5 minutes) 48 hours before your cutover, most resolvers will pick up the new A record within 15-30 minutes of the switch. Forgot to lower it and your TTL was sitting at 86400 seconds (24 hours)? Some visitors could still be hitting the old server a full day after you've moved.

A few things that affect propagation speed in practice:

• Your ISP's resolver behavior — some override TTLs and cache longer than the record instructs.
• Geographic distance — international resolvers sometimes lag behind US-based ones.
• CDN layers — if you're running Cloudflare or a similar proxy, the DNS change often takes effect almost immediately since Cloudflare controls the resolution.

During propagation, both servers need to serve the same content. Keep the old host active and leave the files untouched until propagation is confirmed complete. Use a tool like whatsmydns.net to check resolution from multiple locations before you decommission anything.

The step-by-step migration checklist

Use this in order. Don't skip steps to save time — each one is a safety net for the next.

1. Back up files and database on the current host. Store copies in at least two locations.
2. Provision the new hosting environment with matching server config. See our managed hosting options if you want an environment pre-configured to your stack.
3. Transfer all site files via SFTP or your host's migration tool. Verify file counts match.
4. Import the database and update any hardcoded URLs if the temporary staging URL differs from your live domain. Use Search-Replace-DB or WP-CLI for WordPress sites.
5. Update your local hosts file to point your domain to the new server IP. Then browse every key page: homepage, product or service pages, checkout or contact flows, admin login.
6. Test all forms, payments, and integrations with real test submissions. Don't assume — verify.
7. Check SSL. Install and activate your certificate on the new host before DNS cutover. Confirm HTTPS loads without mixed-content warnings.
8. Update your DNS A record to the new server IP during your planned low-traffic window.
9. Monitor propagation using a multi-location DNS checker. Keep the old host live until propagation is complete worldwide.
10. Run a post-migration audit: crawl the live site with Screaming Frog or a similar tool, check Google Search Console for crawl errors within 48 hours, and confirm Core Web Vitals aren't degraded on the new server.
11. Decommission the old server only after at least 72 hours of clean operation on the new host.

What can go wrong — and how to catch it fast

Even with a solid checklist, certain failure modes show up often enough that they're worth calling out explicitly. Knowing what to look for cuts your recovery time dramatically.

Database connection errors are the most common post-migration issue. The files transferred fine, but the database credentials in your config file still point to the old server's hostname or socket. Check your wp-config.php (for WordPress), .env file, or equivalent config first — before anything else — after importing the database.

Email breaks silently. Migrating web hosting doesn't automatically migrate your MX records. If your email was on the old server and you don't update MX records separately — or you accidentally overwrite them during DNS changes — delivery stops with no obvious error on the website itself. Document your MX, SPF, DKIM, and DMARC records before you touch DNS. Every time.

Hardcoded internal URLs. Some CMS configurations and page builders store absolute URLs in the database. After migration, internal links or images may point back to the old host or a staging URL. A database search-and-replace before cutover prevents this entirely.

SSL not activated before cutover. If visitors land on the new server before HTTPS is configured, browsers throw a security warning and most users leave immediately. Install and test SSL on the new host against your local hosts file entry before you touch DNS.

Caching serving stale content. If your new host has server-level caching enabled, clear it immediately after migration and after any post-migration fixes. We've seen situations where a config fix looked like it didn't take simply because the cache was still serving the broken version. Clear cache before you conclude a fix failed — every time.