Will my site go down during migration?

If you follow the order of operations correctly — clone first, verify on the temporary URL, switch DNS only after confirmation — downtime is zero. The site stays live on the old host until DNS has fully propagated to the new one. The mistake that causes downtime is canceling or modifying the old host account before DNS propagation is complete. Keep the old account active and untouched until you've confirmed the new host is serving traffic correctly, ideally 48-72 hours after the DNS switch.

How long does DNS propagation actually take?

The honest answer is 'it depends' — but the practical range is 15 minutes to 48 hours. Most of the world will see your new DNS within 2-6 hours. The 48-hour figure comes from very long TTL values or slow-updating DNS resolvers. You can check propagation status at whatsmydns.net — search your domain's A record and watch it update region by region. Don't assume propagation is complete just because it works on your laptop; check from different locations or use a VPN.

Should I tell my host I'm leaving?

You don't need to, and there's no benefit to doing so before the migration is complete. Some hosts will try to retain you with a discount offer — that's fine to consider, but make that decision before you start migrating, not in the middle of it. Cancel or let the old account expire only after you've confirmed everything is working on the new host. Most hosts don't prorate refunds, so check the cancellation terms before timing your move.

What about email — does my email move with my website?

Only if your email is hosted on the same account as your website, which it often is on shared hosting. If you're using Google Workspace, Microsoft 365, or Zoho Mail — services with their own MX records — your email is completely independent of your hosting and requires no migration. If your email runs through your hosting provider's mail server, you'll need to either migrate it to the new host or move it to a dedicated email service. I generally recommend moving to a dedicated email service during a hosting migration — it's a good opportunity to decouple the two, and mixing email and web hosting on the same account creates a single point of failure.

Can I migrate a WooCommerce store without losing orders?

Yes, but timing matters more than with a static site. WooCommerce stores need to handle the gap between when the database is cloned and when DNS fully propagates. Any order placed during that window on the old host won't appear in the new database. Options: do the migration during your lowest-traffic window (typically Tuesday-Wednesday, 2-5am for most stores), or put the store in maintenance mode briefly during the DNS switch to prevent new orders from being placed on the old host. For stores doing significant daily volume, a brief maintenance window is worth the peace of mind.

My new host offers free migration — should I use it?

Yes, with eyes open. Free migration services vary significantly in quality. The good ones (WP Engine, SiteGround) use automated tools that clone everything reliably and let you verify before DNS switches. Others do the migration manually, which can take longer and occasionally introduces human error. Before handing off: confirm they'll migrate to a staging/temporary URL first (not directly to your live domain), confirm they'll handle DNS only when you give the instruction, and confirm what's included (files + database + email, or just files + database). Ask specifically about any custom configurations — custom PHP settings, .htaccess rules, cron jobs — that aren't in the standard WordPress installation.

Jason Chen·Lead Reviewer & Founder

Testing hosting since 2009. 60+ accounts across major providers. Former web dev turned full-time reviewer.

𝕏 LinkedIn

How to Migrate Web Hosting Without Downtime

Migrating a website isn't technically difficult. What makes it go wrong — and it does go wrong, more often than it should — is usually not a technical failure. It's a sequencing failure. Someone switched DNS before verifying the new site. Someone cancelled the old account before propagation finished. Someone did the right things in the wrong order and spent a Sunday evening undoing it.

This guide is about the sequence. Follow it and you'll have zero downtime. Skip steps or reorder them and you're introducing unnecessary risk. The steps themselves aren't complicated — most of them are clicking buttons in a control panel — but the order they happen in is the whole point.

By Jason Chen·Mar 2026·13 min read

Before You Start: Three Things to Confirm

Don't touch anything on your current host until you've answered these three questions.

1. Do you have a working backup?

A fresh backup, taken today, of both your files and your database. Not last week's backup — today's. Migration is one of the higher-risk moments in a site's life; if something goes catastrophically wrong, you want a clean restore point that's current. Run a manual UpdraftPlus backup or download a cPanel backup before you do anything else. This takes five minutes and has saved me from having to explain to clients why their site lost a week of content.

2. Do you know where your DNS is managed?

DNS and hosting are often managed separately, and people mix them up. Check: did you register your domain through your hosting company, or through a separate registrar? Is Cloudflare proxying your DNS? Log into your domain registrar right now and find the DNS settings for your domain — specifically the A record that points to your current host's IP address. You'll need to change this in Step 5. If you can't find where your DNS is managed, figure it out before starting the migration, not during it.

3. What's your current TTL value?

TTL (Time to Live) is the number that tells DNS resolvers how long to cache your DNS records. A high TTL (86400 = 24 hours) means a DNS change takes up to 24 hours to propagate globally. A low TTL (300 = 5 minutes) means changes propagate in minutes. Check your current TTL in your DNS settings. If it's 86400 or 43200, you'll want to lower it to 300-600 a few hours before Step 5. This is Step 4 — but knowing your current TTL now tells you how much lead time you need.

Set Up the New Host and Get a Temporary URL

Most hosts give you a temporary URL to access a new site before your domain is connected — something like server123.newhost.com/~yourdomain or a dedicated staging subdomain. This is where your migrated site will live during the verification phase. If you can't find the temporary URL, ask support — every competent host has one.

Some hosts skip the temporary URL and want to add your domain first. Push back on this. You want to verify the migrated site is working correctly before any DNS change happens. A host that won't let you do this is creating unnecessary risk.

While you're setting up: note the new host's nameservers and the IP address of your new server. You'll need these in Step 5.

Clone Your Site to the New Host

Three options here, covered in more detail in the migration methods section below. The short version:

→Plugin (Duplicator or All-in-One WP Migration) — easiest, works for most sites under 500MB.
→Manual (cPanel backup + import) — more reliable for large sites, requires more steps.
→Host-assisted migration — let the new host do it. Works well when both hosts cooperate.

Whatever method you use, you're moving two things: the files (everything in wp-content — themes, plugins, uploads) and the database (all your posts, pages, settings, user accounts). Miss either one and the migration is incomplete.

After the clone completes, update the WordPress site URL in the database to match the temporary URL on the new host. Most migration plugins handle this automatically. If doing it manually, use a tool like Search Replace DB or WP-CLI: wp search-replace 'https://yoursite.com' 'https://temp.newhost.com'. This lets WordPress function correctly on the temporary URL without breaking anything on the live site.

Verify Everything on the Temporary URL

This is the step people rush. Don't. Once you switch DNS, you're committed — any problems you find become live problems.

Go through this checklist on the temporary URL before touching anything else:

☐Frontend loads correctly — homepage, a few posts or pages, any custom post types

☐Images display correctly (missing images usually mean an incorrect URL in the database)

☐Navigation menus work as expected

☐Contact forms submit and send correctly (test this — form submissions often break on new servers due to PHP mail configuration)

☐Login to wp-admin works, all settings are present

☐Active plugins are all visible and no conflict warnings

☐Any e-commerce functionality: add to cart, checkout flow, payment gateway connection

☐SSL certificate is installed and HTTPS works on the temporary URL

☐Page speed — run a quick GTmetrix check, make sure caching and optimization are configured on the new host

If something doesn't work on the temporary URL, fix it now. This is exactly the purpose of the temporary URL — a safe environment to catch problems before they affect your live site.

Lower Your TTL

Do this step several hours before you plan to switch DNS. Don't do it at the same time.

Log into your DNS management panel (wherever you manage your domain's DNS — Cloudflare, Namecheap, GoDaddy DNS, your registrar). Find the A record for your domain (and the www subdomain if it has a separate record). Change the TTL value to 300 seconds (5 minutes).

Wait for the current TTL period to expire. If your TTL was 86400 (24 hours), you need to wait 24 hours after lowering it before propagation will be fast. If it was already 3600 (1 hour), wait an hour. After that waiting period, a DNS change will propagate globally in minutes rather than hours.

This step feels tedious. It's also the difference between a migration that takes 10 minutes to confirm and one that has you watching a propagation checker for six hours.

Switch DNS

Pick your moment carefully. Lowest traffic period for your site — usually a weekday night or early morning. Not Friday afternoon.

Go back to your DNS settings. Update the A record for your domain to point to the new host's IP address. Update the www A record if it's separate. If your new host asked you to change nameservers instead of just the A record, do that — but note that nameserver changes can take longer than A record changes to propagate, even with a low TTL.

Before saving the change: update the WordPress siteurl and home settings in the database from the temporary URL back to your real domain. You can do this in wp-admin under Settings → General, or via WP-CLI: wp search-replace 'https://temp.newhost.com' 'https://yoursite.com'. Do this before the DNS change takes effect — if traffic hits the new server with the temporary URL in the database, links will point to the wrong place.

Save the DNS change. The migration is now underway. Different visitors will start hitting the new host as their local DNS resolvers update.

Monitor and Confirm

Check whatsmydns.net and search your domain's A record. You'll see it updating region by region — the new IP address appearing in more and more locations as DNS caches expire and pull the new record. With a 300-second TTL, most regions update within 15-30 minutes. A few stragglers take longer.

While propagation is happening, your site is effectively in two places. Visitors using DNS resolvers that have already updated will see the new host. Others still see the old one. Both should show the correct site — your old host is still running, your new host is ready. This is why you can't have important data changing during migration: orders placed on the old host won't appear in the new host's database.

Confirm from multiple devices and ideally from a mobile network (which uses different DNS than your home internet). Check:

— The site loads and looks correct
— HTTPS works (SSL certificate on the new host is active)
— You can log into wp-admin
— Any forms or e-commerce functions work

When you're satisfied propagation is complete and everything works: set your TTL back up to 3600 or higher. A 300-second TTL means DNS resolvers are querying your nameservers very frequently, which adds unnecessary load. Raise it back once you've confirmed stability.

Clean Up — Not Before

Wait. Do not cancel your old hosting account until you have confirmed the new host is working correctly for at least 48-72 hours. The temptation is to cancel immediately — you're paying for two hosts and you want to stop. Resist it.

The scenarios that make you glad you waited: you find an issue three days later that requires restoring from the old host's files. A plugin behaves differently on the new server. An email configuration that worked before stopped working. You realize you forgot to migrate a subdomain. All of these are recoverable while the old host is still active. None of them are easily recoverable after you've cancelled it.

After 48-72 hours of confirmed stable operation:

— Cancel or let expire the old hosting account
— If your domain was registered through the old host, transfer it to a dedicated registrar (Cloudflare Registrar, Namecheap) before canceling
— Update any hardcoded references to the old host (FTP credentials saved in clients, SSH keys, deploy scripts)
— Run a fresh backup on the new host so you have a clean post-migration restore point

That's the complete migration. Seven steps, no downtime, no Sunday-evening disasters.

Migration Methods: Plugin vs Manual vs Host-Assisted

Step 2 has three paths. Here's when to use each.

Plugin Migration

Best for most people

Duplicator (free, up to 500MB) and All-in-One WP Migration (free up to 256MB, paid for larger) are the two most reliable options. Both create a complete package of your site — files and database — that you upload to the new host and run an installer. The process takes about 20-40 minutes for a typical site.

All-in-One WP Migration is simpler for beginners: install on old site, export, install on new site, import. Done. Duplicator gives you more control and handles larger sites better with its chunked upload approach.

Limitation: file size caps on free versions. Sites over 1GB need either a paid plugin license or a manual migration.

Manual Migration

Best for large or complex sites

Export the database via phpMyAdmin (or cPanel's backup tool). Download all files via SFTP — specifically the entire wp-content folder plus wp-config.php. Upload to the new host, import the database, update wp-config.php with the new database credentials.

More steps, more control. No file size limits. If anything goes wrong, you know exactly where and can fix it. I use manual migration for any site over 1GB or with custom server configurations.

Key step often missed: after importing the database, run a search-replace on the database to update URLs from the old host's temporary domain to the new one. Use Search Replace DB (interconnectit.com has a free version) or WP-CLI.

Host-Assisted Migration

Convenient but verify the process

Many hosts offer free migration as a sign-up incentive. Quality varies. WP Engine and SiteGround have automated tools that are genuinely reliable. Others assign a support agent who does it manually, which introduces human variability.

Before accepting a host-assisted migration, ask: will the migrated site be available on a temporary URL for me to verify before you touch my DNS? If yes — proceed. If the host wants to migrate directly to your live domain, either push back or do it yourself. You want to see the result before it's live.

One advantage: if something goes wrong, it's their problem to fix, not yours. For non-technical site owners, this trade-off is often worth it.

Frequently Asked Questions

Jason Chen·Lead Reviewer & Founder

Testing hosting since 2009. 60+ accounts across major providers. Former web dev turned full-time reviewer.

𝕏 LinkedIn

Last updated: 2026-03-08

Share:Twitter Facebook LinkedIn