How to Migrate Your WordPress Site to a New Host Without Downtime

Most site owners treat a hosting migration like a heart transplant: necessary, risky, and guaranteed to stop the machine for a while. That reputation is deserved only because most migrations are planned badly. You can Migrate Your WordPress Site to a completely different server without a single visitor seeing an error page, and without losing a comment, an order, or a single point of search visibility.

The trick is sequencing. Files and databases can be copied as many times as you like, so the only moment that truly matters is the DNS switch, and that window can be reduced to a few seconds if the destination is already warm and tested.

Choosing a host that gives you staging space, SSH access, and a proper control panel makes all of this far easier, which is why most teams start by comparing Limitless Hosting’s Plus plans against whatever they run today. This guide walks through the full process, from the checklist you should complete before touching anything to the post-migration checks almost everyone forgets.

Why Downtime Costs More Than Most Site Owners Realize

Downtime is rarely the “few minutes” people budget for. Search engines crawl on their own schedule, and repeated connection errors during a crawl can push a URL into a slower re-indexing queue that takes weeks to recover from. Payment gateways retry failed checkouts, but customers do not. Email sent to a broken form is gone permanently, and the sender usually assumes you ignored them.

There is also a less obvious cost: cached DNS. Even a perfect cutover propagates at the speed of the slowest resolver in the chain, and some corporate networks and mobile carriers hold records far longer than their advertised TTL. Every hour you plan for should assume at least one resolver somewhere is serving the old record.

A trained approach treats the migration as a parallel operation rather than a replacement. You build a full working copy elsewhere, prove it works, then redirect traffic to it. Nothing is ever dismantled until the new environment is verified.

The Pre-Migration Checklist to Migrate Your WordPress Site

An hour of preparation saves a weekend of debugging. Work through this list before copying a single file:

• Inventory the stack. Note the PHP version, MySQL or MariaDB version, web server (Apache, Nginx, LiteSpeed), and every required PHP extension. A migration to a server missing imagick or intl will produce broken images or fatal errors that look like data loss.
• Map every dependency. Cron jobs, SMTP credentials, external APIs, IP allowlists, server-side scheduled tasks, and any hard-coded absolute paths in theme files or plugins.
• Audit disk usage and database size. Migrations fail when a destination plan cannot hold the site plus its backups plus the staging copy. If you are unsure how big your install actually is, this breakdown of how much storage a WordPress website needs gives realistic numbers by plugin count, media library size, and backup strategy.
• Take a full backup you control. Not the host’s automatic snapshot, which disappears with the account. Download a database dump and a files archive to your own machine.
• Lower your DNS TTL to 300 seconds. Do this at least 48 hours before the cutover so the old, long TTL has time to expire everywhere.
• Set a change freeze. No plugin updates, no theme edits, no content publishing during the cutover window. Every change you allow becomes a delta you have to reconcile twice.

How a WordPress Migration Actually Works

WordPress is two things pretending to be one: a file tree and a relational database. Understanding that split is the entire basis of a clean migration.

The file tree holds core files, themes, plugins, and everything in wp-content/uploads. It is static between deployments, which makes it safe to copy early and often. A first pass takes the bulk of the data, and later passes only need to move what changed.

The database holds posts, pages, settings, users, options, and the serialized data inside widgets and page builders. It is the moving target. Every new comment, order, or page view increments counters and writes rows, so the database is what forces the final sync to be quick.

The third element is DNS, and it is the only one your visitors actually experience. Until the A record or CNAME points at the new server, nobody reaches it, no matter how perfectly it is configured. That is why migration plans are built around shrinking the gap between “final database sync” and “DNS live”.

Why serialized data breaks naive migrations

If you dump a database, run a find-and-replace for the old domain, and import it, you will corrupt serialized strings. Their length prefixes are stored as integers, so changing example.com to example.co.uk shifts every string length after it and WordPress silently drops the value.

Always use a search-replace tool that recalculates serialized lengths, such as WP-CLI’s search-replace with --recurse-objects and --all-tables, or a migration plugin built for the job.

The Zero-Downtime Migration, Step by Step

This sequence assumes you already have credentials for the new server and that your domain is registered somewhere you can edit records. Total elapsed time is usually two to three days, with about twenty minutes of active cutover work.

Step 1: Prepare the destination

Create the hosting account, add the domain as an addon or primary domain, create a database and user with full privileges on that database, and install a clean copy of the same or newer WordPress version. Confirm the PHP version and extensions match your inventory. If you are moving onto shared infrastructure, check that the plan’s CPU and entry-process limits match your traffic rather than the traffic you had two years ago; a realistic starting point is a US shared hosting plan sized for your current concurrency, not your launch day.

Step 2: Copy the files

Use SSH and rsync if both servers allow it, because it resumes and only transfers differences:

rsync -avz --progress \
  /home/olduser/public_html/ \
  newuser@newserver:/home/newuser/public_html/

If SSH is unavailable, compress public_html into a single archive, download it, and upload it through the file manager. Exclude cache directories and any local backups sitting inside the web root, since those are the two biggest wastes of transfer time.

Step 3: Copy the database

Export with mysqldump or phpMyAdmin, then import into the new database. Once imported, update wp-config.php on the new server with the new database name, user, password, and host. Leave the old site untouched throughout this step; it is still serving live traffic.

Step 4: Neutralise the copy before testing

A staging copy that shares a database prefix and a live domain will happily send real emails, run real cron events, and process real payments. Before you open it in a browser, disable outgoing mail, pause scheduled events, and put a maintenance or password gate in front of the site. Then run the serialized-safe search-replace for the temporary hostname or preview URL.

Step 5: Test everything that can break

Open the preview site and work through a scripted list: homepage, a deep page, the login screen, a password reset, a form submission, a checkout or donation flow in test mode, image rendering, and permalink structure. Check the PHP error log, not just the browser. Fixing a missing extension or a permission issue now costs minutes; discovering it after the DNS switch costs customers.

Step 6: Freeze and final sync

Announce the freeze, then re-run rsync for files and re-import the database to capture everything that changed since step 3. Do the search-replace again on the fresh import. Take a note of the exact UTC time of the final import; you will use it to verify that nothing was written afterwards.

Step 7: Switch DNS

Change the A record to the new server’s IP, or the CNAME if the host provides one. Because you lowered the TTL two days earlier, most resolvers pick up the change within five minutes. If your host supports it, keep the old server running with a redirect for 48 hours to catch stragglers on slow resolvers.

Step 8: Verify propagation and behaviour

Query public resolvers directly and confirm they return the new IP, then load the site through a third-party checker from several regions. Log in, submit a test form, place a test order, and confirm SSL is valid on the new server. The old certificate does not travel with your files.

Comparing Migration Methods

Most site owners end up choosing a host based on how well it supports the migration method they can actually execute. That is why it pays to read side-by-side breakdowns such as this Limitless Hosting vs Hostinger comparison before committing, rather than discovering mid-move that SSH or staging is locked behind an upgrade.

What Actually Causes Downtime During a Move

In practice, migrations rarely fail because files did not copy. They fail because of the small, unglamorous things nobody checked.

• PHP memory and execution limits on the new server are lower than the old one, so imports and page builds fail with white screens.
• Missing SSL. The certificate stays with the old account. Install a new one before the switch, not after.
• Email DNS. Moving nameservers without copying MX, SPF, DKIM, and DMARC records silently kills your contact form and outbound mail.
• Unpatched code on a fresh IP. A newly exposed server is scanned within hours. An outdated plugin with a known remote code execution flaw, of the kind described in these notes on PHP2Shell RCE vulnerabilities, becomes far more dangerous the moment the site is discoverable at a new address.
• Cron duplication. Scheduled tasks running on both servers double-post, double-send, and double-charge.

Monitoring closes most of these gaps before visitors notice them. Watching SSL expiry, DNS record changes, and uptime from outside your own infrastructure turns a silent failure into an alert; Aepto exists specifically to centralise domain and certificate monitoring so a lapsed renewal or an unexpected DNS edit does not take the site down weeks after a migration looked successful.

Post-Migration Cleanup and Verification

Once traffic is on the new server, the migration is not finished. It is finished when the site behaves identically for a full week.

• Disable or delete the old hosting account only after seven days of clean logs. Keep your own backup of it for at least thirty days.
• Rebuild cron. Confirm WP-Cron or the system cron is running on the new server and that duplicate jobs are gone. Misfiring scheduled tasks are the most common post-migration complaint, and this guide to fixing scheduled posts that fail to publish on shared hosting covers the exact diagnostics.
• Clear every cache layer: page cache, object cache, CDN edge, and browser-side service workers if you run a PWA.
• Update external services that reference the old server IP: payment gateway webhooks, transactional email senders, uptime monitors, and any third-party integration with an allowlisted IP.
• Re-baseline performance. Run a Core Web Vitals check and compare against your pre-migration numbers. A faster host should show it in time to first byte, and if it does not, find out why before you settle in.
• Resubmit the sitemap in Search Console and confirm the property still validates after propagation.

When to Let Your Host Handle the Migration

Managed migration is not a compromise for beginners; it is often the better engineering decision. A host that performs migrations daily has already encountered the odd plugin, the 12GB uploads folder, and the multisite edge case. What matters is that you verify the handover rather than assume it: ask for a written list of what is migrated, confirm whether email accounts move, and check that DNS is switched at a time you choose rather than during your busiest hour.

Whichever route you take, the principle stays the same. Build in parallel, prove the copy works, shrink the switching window, and watch the site closely for a week afterwards. Done that way, a migration becomes an invisible infrastructure upgrade instead of an outage your customers remember.

Conclusion

Migrating WordPress without downtime comes down to preparation and sequencing rather than luck. Lower your TTL early, copy files as many times as you need, treat the database as the moving target it is, and never point DNS at a server you have not tested end to end. Handle serialized data with the right tool, carry your SSL and email DNS across deliberately, and keep the old environment alive until the new one has proven itself.

If you would rather spend your afternoon on content than on rsync flags, moving to a host built for WordPress makes the whole process shorter. Limitless Hosting provides staging space, SSH access, and migration support on plans designed for real traffic, so you can plan the switch on your schedule and let the infrastructure work quietly in the background.

Frequently Asked Questions

How long does a zero-downtime WordPress migration usually take?

Plan for two to three days of elapsed time, most of it waiting. The active work is typically two to four hours spread across preparation, staged copying, and testing, with roughly twenty minutes for the final database sync and DNS change. The waiting period exists so DNS TTL changes can propagate before the cutover.

Will my site go offline when I change the nameservers?

Not if the destination is fully configured and tested first. Visitors on resolvers that have already picked up the new records reach the new server, and visitors still on cached records reach the old one. Both must serve a working site during the overlap, which is why the old account stays live for at least 48 hours.

Do I lose SEO rankings when I move to a new host?

Rankings are usually unaffected when the domain, URL structure, and content stay the same. Risk comes from extended outages during a crawl, broken redirects, or accidentally changing permalinks. Keep the URL structure identical, verify SSL, submit the sitemap afterwards, and monitor Search Console for coverage errors in the following weeks.

Can I migrate a WordPress site without a plugin?

Yes. A manual migration with rsync for files, mysqldump for the database, and a serialized-safe search-replace is the most reliable method for large or unusual installs. It requires SSH access and comfort with the command line, but it gives you complete control over what moves and when.

What happens to my email during a hosting migration?

Email is separate from your website files and is often the part people forget. If you use the host’s mail service, create the mailboxes on the new server and migrate the messages before switching, or move to a dedicated email provider. If email runs elsewhere, copy the MX, SPF, DKIM, and DMARC records to the new DNS zone before propagation.

Should I keep the old hosting account after the move?

Keep it for at least seven days, and ideally thirty. It costs one billing cycle and gives you a rollback path if something surfaces late. Point it at a redirect to the new site if the host supports it, then cancel once logs are clean and search visibility holds steady.

How do I know the migration actually worked?

Check three things over the first week: uptime monitors reporting no errors, server logs showing no 500 responses, and Search Console showing no spike in crawl errors. Add a real transaction test, such as a form submission or a test order, performed from outside your network after propagation completes.

Latest post from our blog:

• How to Migrate Your WordPress Site to a New Host Without Downtime
• How to Fix DNS_PROBE_FINISHED_NXDOMAIN: Complete Website Owner’s Guide
• How to Fix a 403 Forbidden Error on Your Website (2026 Guide)
• Over 70% of the Internet Under Threat: Unauthenticated “PHP2Shell” RCE Vulnerabilities Exploded Online (CVE-2026-109618 & CVE-2026-109619)
• How Much Storage Does a WordPress Website Need?