Switching web hosts sounds straightforward until you’re staring at a blank screen where your website used to be. Host migrations are one of the most common sources of real, costly downtime — and almost all of it is preventable. The sites that go dark during a migration do so because of skipped steps, misunderstood DNS timing, or a simple failure to test before cutting over. None of these are inevitable.

This guide is a complete playbook for migrating your website to a new host with zero downtime. It covers every step from the initial backup through post-migration verification, with special attention to the DNS phase — the part most people get wrong. Whether you’re on WordPress or running a custom site, moving a small blog or a high-traffic store, the process is the same. Follow it in order and your visitors will never know the switch happened.

1. Why Migrations Go Wrong

Understanding the failure points makes the solution obvious. The vast majority of migration downtime comes from one of four mistakes:

Changing DNS Before the New Site Is Ready

DNS is the system that tells the internet where your website lives. When you change it, traffic starts flowing to the new host. If your site isn’t fully set up and verified on the new host yet, visitors arrive at an empty server or an error page. This is the single most common migration mistake, and it’s entirely avoidable — the correct sequence is to always finish setting up the new host first, verify everything works, and only then change DNS.

Not Accounting for DNS Propagation Time

DNS changes don’t take effect instantly. After you update your nameservers or DNS records, the change can take anywhere from a few minutes to 48 hours to propagate globally — meaning different visitors around the world may be hitting your old host or your new host during that window. Migrations that don’t account for this window risk serving inconsistent content or losing data entered on the old host during propagation.

Incomplete Backups or Transfers

Files copy with missing images. Database exports miss a table. Permissions are wrong. A plugin references a hardcoded path that breaks on the new server. These are all common transfer problems that only surface after the switch — when fixing them means real visitors are seeing errors. The cure is thorough testing on the new host before DNS is touched.

Forgetting Email

Many site owners migrate their website and forget they also have email hosted on the same server. Changing nameservers without first migrating email records causes email to stop working. Incoming mail bounces. It can take hours to diagnose and fix, and messages sent during that window may be lost permanently.

2. The Zero-Downtime Strategy Explained

The zero-downtime approach works by keeping both the old and new hosting environments live simultaneously throughout the migration. Here’s the high-level flow before we get into the step-by-step detail:

The key insight: at no point during this process is your site unavailable. The old host stays live and fully functional until the new host has been tested, DNS has propagated, and you’ve verified everything is working. The transition happens gradually through DNS propagation, not through a hard cutoff.

3. Before You Start: Pre-Migration Checklist

Doing this groundwork before touching anything prevents the majority of migration problems. Don’t skip it.

Document Your Current Setup

Before you change anything, make a complete record of your current hosting configuration. You want to be able to recreate it exactly if anything goes wrong:

• Your current host’s nameservers (found in your domain registrar’s DNS settings)
• All DNS records: A, CNAME, MX, TXT, and any others — export the full zone file if your registrar allows it
• Your PHP version and any custom PHP settings (php.ini or .htaccess rules)
• Any cron jobs configured in cPanel
• Email accounts: addresses, passwords, forwarding rules, and any autoresponders
• Database names, usernames, and any custom database settings
• SSL certificate details — though most hosts provision free Let’s Encrypt certificates, so this usually takes care of itself

Take a Complete Backup

A complete backup means two things: all your website files and your database. For WordPress sites, this is the entire public_html folder (or wherever your site lives) plus a full database export. Take this backup the day you plan to begin the migration — not last week’s automated backup — so it’s current.

Store the backup in at least two places: your local computer and a cloud storage service (Google Drive, Dropbox, S3). Never rely on a backup stored only with the host you’re leaving.

Audit Your Site’s Dependencies

Some sites have components that need special attention during a migration:

• Custom fonts or scripts loaded from absolute file paths that may break if server paths change
• Hardcoded URLs in the database pointing to the old host’s IP or temporary domain
• Third-party integrations (payment gateways, CRMs, APIs) that may need IP whitelisting updated to the new server
• CDN configurations pointing to the old host’s origin
• SSL certificates tied to specific domains or IPs
• Caching plugins that may need to be cleared and reconfigured

Choose Your Migration Window

Pick a low-traffic window for the DNS cutover — ideally a weekday evening or early morning when your analytics show the fewest concurrent visitors. Even with zero-downtime migration, the DNS propagation window is a period of transition, and doing it during low traffic minimizes exposure. Check your analytics for your quietest hours and plan around them.

4. Step-by-Step: The Full Migration Process

Here is the complete process in order. Every step matters — resist the urge to skip ahead to the DNS change before the preceding steps are fully complete.

Step 1: Sign Up With the New Host (Keep the Old One Active)

Create your account with the new hosting provider. Do not cancel your old host — that account needs to stay active throughout the entire migration. Most hosts prorate billing, so the overlap cost for a week or two is minimal. Think of it as migration insurance.

During signup, choose a plan that matches or exceeds your current resource usage. Migrating to a plan with less storage or a lower PHP memory limit than your current site needs is a recipe for post-migration errors.

Step 2: Set Up Your Domain in the New Hosting Account

Add your domain to the new hosting account’s cPanel or dashboard — but do not change your DNS yet. On most hosts this is done under “Addon Domains” or “Domains.” The new host will provision space for your site and assign it a server IP address. Make note of this IP address — you’ll need it for testing later.

Step 3: Transfer Your Files

Upload all your website files to the new host. The cleanest method depends on your site type (covered in detail in Sections 5 and 6), but the general approach is:

• Download a complete copy of your site files from the old host via FTP/SFTP or cPanel’s File Manager
• Upload them to the equivalent directory on the new host
• Verify the file count and sizes match — most FTP clients show total file counts you can compare

Step 4: Transfer and Import Your Database

If your site uses a database (WordPress, Joomla, Magento, most CMS platforms do), you need to export it from the old host and import it to the new one:

1. Log into phpMyAdmin on the old host, select your database, and use Export → Quick → SQL format
2. Create a new database on the new host in cPanel’s MySQL Databases section
3. Create a database user, assign it to the database with all privileges
4. Import the SQL file into the new database via phpMyAdmin
5. Update your site’s configuration file with the new database name, username, and password

For WordPress, the configuration file is wp-config.php in the root of your site. Update the DB_NAME, DB_USER, and DB_PASSWORD values to match the new database credentials you just created.

Step 5: Configure SSL on the New Host

Most modern hosts provide free SSL certificates via Let’s Encrypt, provisionable with a single click in cPanel’s SSL/TLS section. Do this before testing — you want to verify the site works over HTTPS on the new host, not just HTTP.

Step 6: Recreate Email Accounts

If you have email hosted on your current provider, set up those same email accounts on the new host now — before the DNS change. This preparation means that when DNS switches, email can start flowing to the new host immediately without an interruption. (See Section 10 for full email migration details.)

5. Migrating WordPress Sites

WordPress is by far the most commonly migrated platform, and it has excellent tooling to make the process reliable. Here are the best approaches, from simplest to most manual:

Option A: Migration Plugin (Recommended for Most Users)

Plugins handle the entire migration — files, database, and URL rewriting — in one process. The two most trusted options are:

• Duplicator Pro — Creates a complete package (files + database) with an installer script. You upload the package to the new host and run the installer via browser. Handles search-and-replace for URL changes automatically. Excellent for sites up to a few GB.
• All-in-One WP Migration — Extremely simple one-click export and import. The free version has a 512MB import limit (sufficient for most small to medium sites); the paid version removes that limit. Ideal for beginners.

General plugin migration workflow:

1. Install the migration plugin on the old WordPress site
2. Run the export — the plugin packages everything into a single file
3. Install a fresh WordPress on the new host
4. Install the same migration plugin on the new WordPress install
5. Import the package file — the plugin restores files, database, and rewrites URLs for the new environment
6. Test thoroughly before touching DNS

Option B: Manual Migration

Manual migration gives you more control and is useful when the site is large, the migration plugin hits file size limits, or you want to understand exactly what’s being moved:

1. Use FTP/SFTP or cPanel to download the full wp-content folder and all WordPress core files
2. Export the database from phpMyAdmin as a .sql file
3. Install a fresh WordPress on the new host using the same version
4. Upload your wp-content folder to the new install, replacing the default one
5. Import the database via phpMyAdmin on the new host
6. Update wp-config.php with the new database credentials
7. Run a search-and-replace on the database to update URLs from old host to new (use the WP-CLI command wp search-replace or the Better Search Replace plugin)

The URL Search-and-Replace Problem

WordPress stores your site’s URL in the database. If you’re moving to a different temporary URL on the new host for testing, or if any file paths have changed, you need to update these references. Simply find-and-replace in the database won’t work cleanly because WordPress serializes some data — you need a tool that understands serialization. The Better Search Replace plugin (free) handles this correctly and is the recommended tool for this step.

6. Migrating Non-WordPress Sites

Static HTML/CSS Sites

The simplest migration of all. Download every file from the old host via FTP, upload them to the new host in the same directory structure. Verify the file count matches. No database, no configuration files, no URL rewriting needed. Test via the hosts file method (covered in the next section), then update DNS.

PHP Sites (Custom or Framework-Based)

Download all files, export the database if one is used, and import to the new host as described in Section 4. Pay careful attention to PHP version compatibility — if your code was written for PHP 7.4 and the new host defaults to PHP 8.2, you may hit deprecation errors. Check your PHP version on the old host and match it on the new host during migration; upgrade PHP as a separate step after the migration is stable.

Joomla

Joomla migrations follow the same files + database pattern as WordPress. The Akeeba Backup extension (free) is the Joomla equivalent of Duplicator — it creates a complete site package with a self-contained installer. It’s the recommended approach for any Joomla migration.

Magento and WooCommerce Stores

E-commerce migrations warrant extra caution because live orders and inventory can be written to the database during the migration window. Best practice for stores is to briefly enable maintenance mode during the database export step — not during the DNS propagation, but during the actual database export — to ensure you get a clean, complete snapshot. Re-enable the store immediately after the export is done. This window should take only a few minutes and can be scheduled for 2–3am.

7. The DNS Cutover: The Most Critical Step

This is where migrations succeed or fail. Get this right and the transition is invisible to your visitors. Rush it and you get downtime. Here’s exactly how to handle it.

Testing Before You Change DNS: The Hosts File Method

Before touching DNS, you need to preview your site on the new host as if DNS already pointed there. You do this by editing your computer’s hosts file — a local file that overrides DNS for your machine only. This lets you browse to your domain and see the new host’s version of the site, while everyone else in the world still sees the old host.

You’ll need the new host’s IP address (found in your hosting control panel, or via a ping to the temporary domain the host provides).

On Mac/Linux:

1. Open Terminal
2. Run: sudo nano /etc/hosts
3. Add a line: NEW.HOST.IP.ADDRESS yourdomain.com www.yourdomain.com
4. Save and exit (Ctrl+X, Y, Enter in nano)
5. Flush your DNS cache: sudo dscacheutil -flushcache (Mac) or sudo systemd-resolve --flush-caches (Linux)

On Windows:

1. Open Notepad as Administrator (right-click → Run as administrator)
2. Open the file: C:\Windows\System32\drivers\etc\hosts
3. Add a line: NEW.HOST.IP.ADDRESS yourdomain.com www.yourdomain.com
4. Save. Flush DNS: open Command Prompt and run ipconfig /flushdns

Now when you visit your domain in a browser, you’ll see the new host’s version. Test everything thoroughly. When you’re done, remove the hosts file entry and restore your DNS cache — you’ll see the old site again. Only proceed to the DNS change once you’re satisfied with what you see on the new host.

Lowering TTL Before the Switch

TTL (Time to Live) is the number of seconds that DNS resolvers around the world cache your DNS records before checking for updates. A typical TTL is 3600 seconds (1 hour) or higher. If your TTL is 3600 when you make the DNS change, it can take up to an hour — or more — for the change to propagate globally.

24–48 hours before your planned DNS change, log into your domain registrar and lower your DNS record TTLs to 300 seconds (5 minutes). After the TTL expires globally (wait the full 48 hours to be safe), when you make the change it will propagate in roughly 5 minutes rather than hours. This dramatically tightens the window during which different visitors see different hosts.

Making the DNS Change

There are two ways to point DNS to a new host:

• Change nameservers — Point your domain to the new host’s nameservers entirely. This transfers DNS management to the new host. Simpler, but all DNS records (including MX records for email) need to be recreated on the new host’s DNS first.
• Change the A record only — Update just the A record (and www CNAME) to point to the new host’s IP, leaving nameservers and MX records unchanged. More surgical — email is unaffected because MX records don’t change.

Changing the A record only is generally the safer approach for migrations where email is involved, as it isolates the change to the web server without risking email disruption.

8. Testing After the Switch

DNS has propagated and your domain is pointing to the new host. Now verify everything before you stand down and declare the migration complete.

The Post-Migration Test List

• Homepage loads correctly — check layout, images, fonts, and navigation
• SSL is active — URL shows https:// and browser displays the padlock; no mixed content warnings
• Internal links work — click through at least 10–15 pages to confirm no broken links or 404 errors
• Images and media load — look specifically for missing images, which often indicate an incomplete file transfer
• Contact forms submit correctly — submit a test form and verify you receive the email; SMTP configuration on a new host often needs separate setup
• Search functionality works (if applicable)
• User login and accounts function — log in as a test user and verify session handling works
• E-commerce checkout processes correctly — place a small test order through the full checkout flow, including payment
• Site speed — run the URL through Google PageSpeed Insights and compare to pre-migration baseline
• Google Search Console — check for any new crawl errors appearing after migration
• Analytics tracking is firing — verify your analytics platform is receiving data from the live site

Monitor for 48 Hours

After DNS propagation, keep a closer eye than usual on your uptime monitoring alerts and server error logs for the first 48 hours. This is when latent issues surface: a plugin that works locally but needs a PHP extension the new host doesn’t have, a database query that performs differently, a caching configuration that needs adjusting. Catching these quickly minimizes any real-world impact.

9. When to Use Free Host Migration Services

Many hosting providers offer free migration as part of their onboarding package. Before spending hours doing a manual migration, it’s worth understanding when to take them up on it — and when to do it yourself.

Use the Host’s Free Migration Service When:

• Your site is WordPress and the new host has a dedicated migration team or plugin (WP Engine, Kinsta, SiteGround, and Hostinger all do this well)
• Your site is large enough that manual file transfer would take hours
• You’re not technically confident in the manual process
• You don’t have time to babysit a migration
• The new host offers a money-back guarantee — if their migration breaks something, they fix it at no cost to you

DIY the Migration When:

• The new host’s free migration is limited to one site and you want to learn the process for future migrations
• Your site has complex custom configurations that need hands-on attention
• You have sensitive data and prefer to control the transfer entirely
• The host’s migration process involves a long queue and you need to move on a specific timeline

Always verify current migration offers directly with the host before signing up — policies change.

10. Migrating Email at the Same Time

Email migration is the most overlooked part of a host switch, and getting it wrong means bounced mail and lost messages. Here’s how to handle it cleanly.

Understand What You’re Moving

If your email is hosted on the same server as your website (common with shared hosting), changing your nameservers or MX records as part of the migration will affect email delivery. You need to either migrate your email to the new host, or preserve your existing MX records so email continues flowing to the old host’s mail server during and after the transition.

Option A: Keep Email Where It Is (Simplest)

If you’re changing nameservers to the new host’s nameservers, recreate your existing MX records on the new host’s DNS exactly as they were on the old host before making the switch. This keeps email flowing to the same mail server as before — your website moves to the new host, but email delivery is completely unaffected.

Option B: Move Email to Google Workspace or Microsoft 365

If you’re considering upgrading your email at the same time, a migration is the ideal moment to move to a dedicated email service like Google Workspace or Microsoft 365. These services are purpose-built for email reliability and are independent of your web hosting. Once set up, their MX records point to Google’s or Microsoft’s servers regardless of where your website is hosted — making future host migrations much simpler because email is completely decoupled from hosting.

Option C: Migrate Email to the New Host

If you want email on the new host’s mail server:

1. Create all email accounts on the new host with the same addresses and passwords
2. Export emails from the old host using IMAP (connect a desktop client like Thunderbird to both the old and new IMAP servers and drag messages across)
3. Update your email client settings to use the new host’s IMAP/SMTP servers after DNS propagation
4. Monitor for any missed messages during the transition window

11. Common Migration Mistakes to Avoid

These are the mistakes that cause the majority of migration downtime and data loss. Read them before you start — recognizing them in advance is the best way to avoid them.

Cancelling the Old Host Too Early

The old host is your safety net. If anything goes wrong on the new host in the first few days — an obscure error surfaces, a plugin misbehaves, the server proves slower than expected — you can roll back by reverting DNS to the old host. This option disappears the moment you cancel. Keep the old host active for a minimum of one week after full DNS propagation, ideally two weeks. The cost of a few extra days of billing is negligible compared to the cost of having no rollback option.

Forgetting to Test Email on the New Host

Always send a test email to and from each migrated email address before declaring the migration complete. Email configuration on a new host involves SMTP settings that may differ from the old host, and issues only surface when you actually send mail.

Not Updating Hardcoded URLs in the Database

WordPress and many other CMS platforms store URLs in the database. If your temporary domain on the new host differs from your production domain — or if you changed anything about the domain structure — these stored URLs point to the wrong place. Always run a search-and-replace on the database after migration to update any references to the old host or temporary URL.

Forgetting to Flush Caches

After migration, clear every layer of caching: your WordPress or CMS cache, your caching plugin cache, your CDN cache (purge it entirely), and your browser cache. Stale cache serving old content from the old host can make the migration appear to have failed when it actually succeeded.

Ignoring File Permissions

File permissions matter on Linux servers, and they sometimes get scrambled during FTP transfers. WordPress requires directories to be set to 755 and files to 644 for normal operation. If pages return blank or show permission errors after migration, this is often the cause. Most FTP clients let you recursively set permissions across all files and folders.

Moving to a Lower PHP Version Without Testing

If the new host’s default PHP version is older than what your site was running — or newer in ways that break deprecated function calls — you’ll get PHP errors or white screens after migration. Check the PHP version on the old host (usually in cPanel → Software → PHP Version) and configure the new host to match it before migration. Then test a PHP upgrade separately once everything is stable.

Skipping the Hosts File Test

Skipping the hosts file preview is the single biggest avoidable risk in a migration. It’s the only way to verify the new host is working correctly before real visitors see it. No matter how pressed for time you are, do this step. Twenty minutes of local testing can prevent hours of live site debugging.

12. Your Migration Checklist

Print this out or keep it open in a separate tab. Work through it in order.

Before Migration Day

• Document all current DNS records (A, CNAME, MX, TXT) — screenshot or export the full list
• Record current PHP version, MySQL version, and any custom server settings
• Take a full backup: all files + database export, stored in two locations
• Sign up with the new host — do NOT cancel the old host
• Lower DNS TTL to 300 seconds on all records and wait 48 hours
• Set up the site on the new host: files, database, wp-config or config file updated
• Provision SSL certificate on the new host
• Create all email accounts on the new host with matching credentials
• Recreate all DNS records on the new host (if switching nameservers)

Pre-DNS Testing (Hosts File)

• Add the new host’s IP to your local hosts file for your domain
• Browse your site — check homepage, 10+ internal pages, images, and fonts
• Verify SSL is active (https:// padlock shows, no mixed content warnings)
• Submit at least one contact form and confirm receipt
• Test user login and any account functionality
• For e-commerce: complete a test checkout end-to-end
• Remove the hosts file entry when testing is complete

DNS Cutover

• Confirm it’s a low-traffic window (check analytics)
• Update A record (or nameservers) to point to new host
• Confirm MX records are intact and correct before saving changes
• Open whatsmydns.net to monitor propagation in real time
• Do not close the old hosting control panel during propagation

Post-Migration Verification

• Confirm your domain resolves to the new host’s IP (use whatsmydns.net)
• Repeat full browser test on the live site from the new host
• Send a test email to and from each migrated email address
• Flush all caches: CMS cache, caching plugin, CDN, and browser
• Check server error logs for any PHP or database errors
• Verify analytics and tracking scripts are firing correctly
• Check Google Search Console for new crawl errors over the next 48 hours
• Keep the old hosting account active for a minimum of 7 days
• Cancel the old host only after everything is fully confirmed stable