Migrating a WordPress site to a new host sounds scary. The fear is always the same: downtime, broken links, lost emails, or missing data.
Here is the good news. A properly executed migration involves zero visitor-facing downtime. Your site stays live and fully accessible at all times, and the switch to the new server is completely invisible to your visitors. The trick is not in the file copy, which is the easy part. It is in the handoff and understanding how to time it correctly.
In this guide, we will walk through exactly how to migrate a WordPress site to a new host without downtime, the one setting that prevents the gap, and the mistakes that cause most so-called “downtime.“
Signs It’s Time to Migrate to a New Host
Before the how, a quick word on the why. Most people migrate because their current host is holding them back in one of these ways:
Slow performance. If your site loads slowly no matter how much you optimize, and your host cannot give you more resources, the hosting itself is the bottleneck. (If you are not sure whether hosting or the site itself is the problem, our guide on what caching can and cannot fix explains the difference.)
Frequent downtime. If your site goes down regularly or your host has unreliable uptime, you are losing visitors and revenue every time it happens.
Poor or slow support. When something breaks and support takes days to respond (or cannot solve WordPress-specific issues), that is a sign you have outgrown your host.
Security problems. Repeated malware infections, no isolation from other sites, or a host that does not take security seriously are all reasons to move.
Overpaying for less. If you are paying premium prices for underpowered, unmanaged hosting, a modern managed WordPress host often delivers more for less.
If any of these sound familiar, migration is not just beneficial; it is worth doing sooner rather than later. The good news is that doing it right means no disruption to your visitors.
Why “Without Downtime” Is Actually Possible
The reason zero-downtime migration works comes down to a single principle: you keep both servers running at the same time.
Your old host stays live while you build a complete copy of your site on the new host. Visitors keep hitting the old server, seeing your site exactly as before, while you set everything up on the new one in the background. Only when the new site is fully built, tested, and confirmed working do you flip the switch that redirects traffic. And because of how DNS works, even that switch is gradual and seamless rather than a hard cutover.
Nothing goes offline because nothing is ever turned off until the replacement is already running. That is the entire secret.
Before You Start: Pre-Migration Checklist
Preparation is what separates a smooth migration from a stressful one. Before touching anything, get these in order.
Choose your new host. Make sure it actually solves the problem you are migrating away from, whether that is speed, reliability, security, or support. Confirm it has the resources your site needs. If you are weighing your options, our guide on shared vs managed WordPress hosting breaks down the differences.
Take a full backup. Back up your entire site (all files and the complete database) before you change anything. This is your safety net. If anything goes wrong, you can restore. Never migrate without a current, verified backup.
Gather your credentials. You will need access to both hosts: FTP or SFTP details, hosting control panel logins, and database credentials for the old and new environments.
Note your DNS provider. Know where your domain’s DNS is managed (your registrar or a service like Cloudflare), because you will need to update records at the end.
Lower your DNS TTL in advance. This is the step most tutorials skip, and it is the key to a fast, clean cutover. We will explain it in detail below, but do it a day or two before migrating.
The One Setting That Prevents Downtime: DNS TTL
This deserves its own section because it is the single most important technical detail in a zero-downtime migration.
TTL (Time To Live) is a DNS setting that tells the internet how long to cache your domain’s records before checking again. If your TTL is set to 24 hours, some visitors could keep hitting your old server for a full day after you change DNS, because their systems cached the old address.
The fix: lower your TTL to a low value (like 300 seconds, or 5 minutes) a day or two before you migrate. Once the lower value has propagated, any DNS change you make afterward takes effect within minutes instead of hours or days. This is what makes the final cutover feel instant.
After the migration is complete and stable, you can raise the TTL back to a normal value.
Step-by-Step: How to Migrate WordPress Without Downtime
Here is the complete process, in order.
Step 1: Set Up the New Server
On your new host, prepare a clean environment for your site. Depending on the host, this may mean creating a new hosting account, setting up the server, and creating an empty database ready to receive your data. Have your new database name, username, and password ready.
At this stage, your old site is still live and untouched. Nothing has changed for your visitors.
Step 2: Back Up and Copy Your Site
Create a complete copy of your existing site. You have two main approaches:
Plugin method (easier). Tools like Duplicator, All-in-One WP Migration, or UpdraftPlus package your entire site (files and database) into a movable archive. You install the same plugin on the new host and restore the package there. This is the simplest route for most sites.
Manual method (more control). Download all your files via FTP/SFTP, export your database through phpMyAdmin (Export tab, Quick method, download the SQL file), then upload the files and import the database on the new server. This gives you more control and is often more reliable for large or complex sites, but requires more technical comfort.
Either way, the goal is the same: a full, working copy of your site now exists on the new host, while the old one keeps serving visitors.
One important note: caching plugins can interfere with migration. If you are running a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache), disable it before you export your site. Cached files can carry over stale paths and cause confusing errors on the new server. You can re-enable and reconfigure caching once the migration is complete and stable.
Step 3: Rebuild and Configure on the New Server
Once your files and database are on the new server, connect them. Update your wp-config.php file with the new database name, username, password, and host so WordPress can talk to the migrated database.
While you are in wp-config.php, check the $table_prefix variable. It must match the prefix of the tables you imported into the new database (commonly wp_, but not always). If the old site used a custom prefix and the new config does not match it, WordPress will not find its own data, and you will see a database connection or setup error. Confirm the two match before moving on.
If your site paths differ, make sure those match too. At this point you have a complete copy of your site sitting on the new server, ready to test, but not yet receiving public traffic.
Step 4: Test Before Switching (Using Your Hosts File)
This is the step that guarantees no downtime, and it is the one most people do not know about.
Before you change any DNS, you can preview your migrated site on the new server privately, using your computer’s hosts file. The hosts file lets you tell only your own computer to load the domain from the new server’s IP address, while the rest of the world still sees the old server.
You will find the hosts file at /etc/hosts on Mac and Linux, or at C:\Windows\System32\drivers\etc\hosts on Windows. Open it as administrator, add a line with the new server’s IP address followed by your domain (for example, 123.45.67.89 yoursite.com), and save. Your computer will now load the site from the new server while everyone else still sees the old one.
This means you can browse your entire migrated site on the new host, click through pages, test forms, check the checkout, and confirm everything works, all before a single visitor is affected. If something is broken, you fix it while the live site is still safely running on the old host.
Only proceed to the next step once you have confirmed the new site works perfectly.
Step 5: Point Your Domain to the New Host (DNS Cutover)
Now the actual switch. Update your DNS records (the A record, or nameservers, depending on your setup) to point your domain to the new server’s IP address.
Because you lowered your TTL earlier, this change propagates quickly, often within minutes. Visitors are seamlessly and gradually routed to the new server as their DNS caches refresh: some immediately, others within minutes. Since both servers hold identical copies, nobody sees any difference, and there is no moment where the site is unreachable.
Step 6: Keep the Old Host Running During Propagation
This is the most important rule of downtime-free migration: do not turn off your old host too soon.
DNS propagation is not instant for everyone. While it usually completes within minutes with a low TTL, give it time, ideally 24 to 48 hours, to fully propagate worldwide. During this window, both servers serve identical copies, so every visitor sees a working site regardless of which server they land on.
A practical note on billing: keep the old hosting account active through the entire propagation period. If your billing cycle happens to end during the migration, paying for one extra month is cheap insurance against downtime. Do not let a billing date pressure you into shutting down the old host early.
Only cancel or shut down your old hosting once you are certain all traffic is hitting the new server, and everything is stable.
Post-Migration Checklist: What to Verify
Migration is not done when DNS switches. These verification steps catch the problems that cause real damage when skipped.
Test your site thoroughly. Click through key pages, submit forms, test the checkout if you have one, and check that images load correctly.
Check for mixed content and SSL. Confirm your SSL certificate is active on the new host and that the site loads over HTTPS without “mixed content” warnings. Migrations often surface HTTP resources that need updating.
Verify email still works. This is the step most tutorials forget, and it causes real damage. If you changed nameservers, your MX records may have moved too, which can break email. Send and receive a test message on every affected address, and mirror your MX records on the new host if email did not follow.
Check Google Search Console. Confirm search engines can still crawl your site. Make sure you are not accidentally blocking crawlers (Settings then Reading in WordPress, “Discourage search engines” should be unchecked), submit your sitemap, and monitor coverage for a week using Google Search Console.
Watch your rankings. A brief, small ranking fluctuation right after migration is normal. A sustained drop signals a problem worth investigating.
Common Migration Mistakes That Cause Downtime
Almost all migration “downtime” comes from a handful of avoidable mistakes.
Turning off the old host too early. The number one cause of downtime. If you cancel the old hosting before DNS fully propagates, visitors still routed to the old server hit nothing. Keep it running.
Changing DNS before testing. If you switch DNS before confirming the new site works, and something is broken, your visitors see the broken version live. Always test via your hosts file first.
Skipping the backup. Migrating without a verified backup means that if something goes wrong, you have no way back. Always back up first.
Not lowering the TTL. Skip this and your DNS change can take up to 24-48 hours to fully take effect, extending the window where things can go wrong.
Ignoring SSL and mixed content. Forgetting to set up SSL on the new host, or leaving hardcoded HTTP links, triggers browser security warnings that erode trust immediately.
Forgetting email. Changing nameservers without checking MX records can silently break your email while the website itself looks fine.
Corrupting serialized data during URL changes. If your domain or paths change during migration, using a plain find-and-replace on the database can corrupt WordPress’s serialized data. Use a proper migration tool or a serialization-safe search-and-replace script instead.
Special Cases: Large Sites, WooCommerce, and Multisite
Not every migration is a simple blog move. A few scenarios need extra care.
Large sites (over a few GB). Very large sites can hit timeout errors with standard migration plugins. Dedicated tools built for large migrations, or a manual transfer handled by someone experienced, are more reliable here. Some sites over 100GB simply cannot be moved with basic plugin exports.
WooCommerce stores with live orders. The risk with e-commerce is orders placed during the migration window. Because both servers run during propagation, an order could land on the old server after you have already switched. For stores, it is safest to migrate during your lowest-traffic period and reconcile any orders that came in on the old server before shutting it down. For busy stores, professional migration is strongly recommended.
WordPress Multisite. Migrating a single site out of a Multisite network, or moving an entire network, is more complex than a standard migration. It involves separating or preserving network tables and is best handled by someone who has done it before.
If your situation falls into one of these categories, the stakes of getting it wrong are higher, and professional help is usually worth it.
Have a Rollback Plan
Even with careful planning, it pays to know your way back. The beauty of the zero-downtime method is that your rollback plan is built in: because your old host stays live and untouched during the entire process, reverting is simple.
If something goes wrong after the DNS switch, you simply point your DNS back to the old server’s IP address. Since the old site is still running exactly as it was, traffic returns to a fully working site while you diagnose the issue on the new server. This is another reason never to shut down or cancel the old host until you are completely certain the new one is stable.
That safety net is exactly why the “keep both servers running” principle matters so much. It is not just about avoiding downtime during the switch. It is your insurance policy if anything unexpected happens.
Should You Migrate Yourself or Have It Done for You?
Migrating a simple site with a plugin is manageable for most people who are comfortable following technical steps carefully. The plugin route handles much of the complexity.
But migration gets riskier with complexity. Large sites, WooCommerce stores with live orders, sites with custom configurations, or business-critical sites where any hiccup means lost revenue are cases where a mistake is expensive. In those situations, having an experienced team handle the migration is worth it. The cost of professional migration is almost always less than the cost of a botched one.
Many quality hosts also offer free managed migration as part of onboarding, where their team handles the entire move for you, doing the cutover with you rather than leaving you to time DNS alone.
At Webueno, migration support is included when you move your site to our managed WordPress hosting. Our team handles the full transfer (files, database, and configuration) with no downtime, and your site lands on isolated, high-performance servers with caching, security, and daily backups configured from day one. If your current site has any underlying issues, like malware or performance problems, we catch and address them during the move rather than carrying them over.
Move With Confidence
Migrating your WordPress site to a new host does not have to mean downtime, broken links, or sleepless nights. The entire process comes down to one principle: keep both servers running, test privately before you switch, and only retire the old host once the new one is proven and stable.
Get the sequence right (backup, copy, test via hosts file, lower TTL, switch DNS, keep the old host live through propagation, then verify), and the move is completely invisible to your visitors.
If you would rather not handle the technical steps yourself, Webueno’s managed WordPress hosting includes hands-on migration support, so your site moves cleanly, safely, and without downtime, while you focus on your business.
Move your WordPress site to Webueno with zero downtime
Frequently Asked Questions
Can I really migrate WordPress with zero downtime?
Yes. Zero-downtime migration works by keeping both your old and new hosts running simultaneously. You build and test a full copy on the new host while the old one stays live, then switch DNS only after confirming everything works. Because both servers run identical copies during propagation, visitors never see the site go offline.
How long does a WordPress migration take?
The actual file and database transfer can often be completed in under an hour for a typical site. However, DNS propagation after the switch can take up to 24-48 hours to complete worldwide, which is why you keep the old host running during that window. The site stays live the whole time.
What is DNS TTL and why does it matter for migration?
TTL (Time To Live) controls how long the internet caches your domain’s DNS records. Lowering it to around 300 seconds a day or two before migrating means your final DNS switch takes effect within minutes instead of hours, making the cutover fast and clean.
Will migrating hurt my SEO or rankings?
Done properly, migration should not harm your SEO. A brief, minor ranking fluctuation immediately after migration is normal. To protect rankings, keep URLs identical where possible, ensure SSL works, avoid blocking crawlers, and submit your sitemap in Search Console after the move. A sustained ranking drop signals a problem to investigate.
Do I need a plugin to migrate WordPress?
No, but it makes things easier. Migration plugins like Duplicator, All-in-One WP Migration, or UpdraftPlus package and move your site automatically. The manual method (FTP plus phpMyAdmin) gives more control and can be more reliable for large or complex sites, but requires more technical comfort.
What is the most common cause of downtime during migration?
Turning off the old host too early. If you cancel your old hosting before DNS has fully propagated, any visitors still routed to the old server hit nothing. Always keep the old host running for 24-48 hours after switching DNS.
Will my email break when I migrate?
It can, if you change nameservers, because your MX records may move with them. Always test email after migration and mirror your MX records on the new host if email did not follow. This is one of the most commonly forgotten migration steps.
Can someone migrate my site for me?
Yes. Many managed hosts offer free migration as part of onboarding, where their team handles the entire move including the DNS cutover. This is the safest option for large, complex, or business-critical sites where downtime or errors would be costly.
What if something goes wrong after I switch?
Because your old host stays live and untouched during the process, you have a built-in rollback. If the new site has a problem after the DNS switch, simply point your DNS back to the old server’s IP address. Traffic returns to your fully working old site while you fix the issue. This is why you never shut down the old host until the new one is proven stable.
Should I disable caching plugins before migrating?
Yes. Caching plugins can carry over stale file paths and cause errors on the new server. Disable your caching plugin before exporting your site, then re-enable and reconfigure it once the migration is complete and stable.
How do I migrate a very large WordPress site?
Very large sites (several GB or more) can hit timeout errors with standard migration plugins. Use a migration tool built for large sites, or have an experienced team handle a manual transfer. Sites over 100GB in particular usually cannot be moved with basic plugin exports and need a specialized approach.
How long should I keep my old host after migrating?
Keep your old host running for at least 24-48 hours after switching DNS, and ideally up to 7 days to be safe. This ensures DNS has fully propagated worldwide and gives you a fallback if any issues surface. Only cancel once you are certain all traffic is hitting the new server and everything is stable.
