How to Migrate WordPress Without Downtime

A collage featuring geese pulling the WordPress logo

WordPress migration is the process of moving your site to a new environment by transferring two core components: the file system (themes, plugins, media and core files) and the database (content, settings and users).

Most migrations don’t start as planned projects. They’re triggered by friction such as sites slowing down under traffic, recurring downtime or teams outgrowing the limits of their current host. In other cases, the need is structural – better development workflows, cleaner deployments or environments that separate Dev, Test and Live.

The anxiety around migration usually centers on downtime. But it’s rarely caused by moving files or importing a database. The real risk sits in the DNS propagation window, when traffic shifts between servers. That’s where things can break and where sequencing matters.

This guide follows that sequence from start to finish: choosing the right approach, preparing properly, executing the move, switching DNS safely, verifying everything works and fixing issues if they don’t.

Which migration method fits your site

Here are three practical paths to migrate your WordPress website.

1. Plugin-based migration

Plugin-based migration is the fastest and simplest option. It works best for straightforward WordPress sites where the chosen plugin supports your site’s size, structure and host limits. It’s also suitable for teams without deep technical experience. 

Most plugins handle export, transfer and import in one flow, but total migration time can vary significantly depending on site size, server speed and network conditions. 

The tradeoff shows up at scale. Limits are often caused by hosting constraints (like upload size, PHP timeouts or memory), not just the plugin itself. Edge cases like multisite or complex hosting setups also aren’t consistently supported and may require paid versions or specialized tools.

2. Manual migration

Manual migration (using tools like SFTP/rsync, phpMyAdmin or mysqldump and sometimes WP-CLI or Git) gives you full control. It’s the right fit when you need more control, when preserving Git history matters or when working with complex environments. 

Expect to spend anywhere from 1–3 hours for small sites to significantly longer for larger or more complex ones. You’ll handle file transfers, database export/import and only update wp-config.php if database credentials or environment settings change. 

The approach is reliable, but only if you’re comfortable working with databases and server access and understand how to safely handle WordPress-specific data like serialized values (e.g., using WP-CLI for search/replace instead of raw SQL edits).

3. Managed or professional services

Managed or professional services are built for complexity. Multisite networks, very large sites (especially with large databases, media libraries or millions of files), Composer-based builds or environments where downtime has a direct revenue impact all fall into this category. 

This is where teams move from DIY to risk management, using services like Pantheon Professional Services or other host/agency migration specialists to handle sequencing, validation and cutover. This is especially important when coordinated deployment, minimal downtime, or platform-specific workflows (like Composer-based setups) are required.

Preparing your site for a zero-downtime migration

Zero downtime is achieved by how you prepare for the migration. The order of steps here matters, especially the first one:

  1. Lower your DNS TTL (time to live) to 300 seconds at least 24–48 hours before the move. This tells the internet to check for updates more frequently, so when you switch servers later, most traffic shifts faster – though some users may still see the old site temporarily due to caching. You can’t apply this retroactively, so it has to come first.
  2. Take a full backup of both files and the database and don’t just store it – verify you can restore it successfully in a test environment. This is your safety net if anything goes wrong. If you’re on Pantheon, you can take on-demand backups and restore code, database and files together, which makes rollback planning much easier during a migration.
  3. Update WordPress core, themes and plugins in a staging or test environment first and confirm compatibility with the destination PHP version before moving anything. Outdated or incompatible code running on a newer PHP version is one of the most common causes of broken sites after migration.
  4. Temporarily clear caches and review caching/security plugin settings, disabling only features that may interfere (such as firewalls, file-change protection or aggressive caching). These tools can block file transfers or interfere with how migration plugins package your site.
  5. For WooCommerce, prevent split orders by using a short order freeze, checkout pause, maintenance mode or final delta sync during cutover. Also, make sure to test payment gateways, webhooks, emails, taxes, shipping and scheduled actions before and after launch.
  6. Keep your old host active for 7–14 days after launch. However, plan how you’ll handle any new data (orders, users, form entries) created after launch before attempting a rollback.
  7. Before switching DNS, confirm SSL is active, CDN/cache settings are correct, redirects work and transactional email and cron jobs are functioning properly.

Running the migration step by step

At this point, preparation is done. Now you’re moving the site itself. Here we’ll cover how to do that either manually or using a plugin.

Migrating with a plugin

Here’s a blueprint for migrating your WordPress site using a plugin:

  1. Choose a reliable migration plugin: Popular options include All-in-One WP Migration and Duplicator. Install and activate the plugin on your existing WordPress site (the “source” site). Once activated, you’ll typically find a new menu option in your dashboard. Use the plugin’s export option to package your site, then download the migration file or archive it generates. If you’re migrating specifically to Pantheon, you can also use the Pantheon Migrations plugin, which lets you move your site by entering your Pantheon SFTP credentials and running the migration with minimal manual setup.
  2. Prepare your new hosting environment (the “destination” site): Install a fresh WordPress instance on your new server or domain. Then install the same migration plugin on this new site.
  3. Import your site: Open the plugin on the destination site and choose the “Import” option. Upload the file you downloaded earlier. The plugin will overwrite the new site’s content with your old site’s data. This includes settings, posts and media – essentially cloning your original site. Once the import is complete, you’ll usually be prompted to log in again using your original site credentials. At this point, your site should look identical to the old one.

Migrating manually with SFTP and phpMyAdmin

Manual migration gives you full visibility into each step – here’s an overview:

  1. Download all site files via SFTP (e.g., FileZilla) from your current host (typically from public_html). For large sites, it’s faster to SSH in and compress everything into a single archive before downloading.
  2. Export your database using phpMyAdmin. Select the correct database, choose Export → Quick → SQL and download the file. Large databases can time out during browser-based exports, so use SSH with WP-CLI or MySQL CLI instead when possible. For WP-CLI, use:

wp db export backup.sql

For MySQL CLI, use:

mysqldump -u DB_USER -p DB_NAME > backup.sql

Also, some hosts provide export/import tools in their control panels or will handle large imports for you on request.

  1. On the new host, create a fresh database and user, making sure the user has full privileges. Then import the .sql file using phpMyAdmin or via MySQL CLI for larger databases using the following command:

mysql -u DB_USER -p DB_NAME < backup.sql

  1. Upload your site files to the new server via SFTP, placing them in the correct root directory.
  2. Now update wp-config.php. This is the most common failure point. Carefully set:
    • DB_NAME
    • DB_USER
    • DB_PASSWORD
    • DB_HOST

Each value must match the new database exactly.

Testing your new site before switching DNS

Before you switch DNS, make sure the new site works exactly like your old one, but without the public seeing it yet.

First, you need a way to open the site on the new server. Many hosting providers give you a temporary preview URL, which is the easiest option, but it’s not always perfect. The more accurate method is editing your computer’s “hosts file.” This tells your computer to load your domain from the new server’s IP instead of the old one, so you see the site exactly as it will appear after the switch.

Once you can access the site, log in to your WordPress dashboard and go through it carefully: 

  • Open multiple pages and posts and make sure everything loads correctly. 
  • Pay close attention to images and media because missing files are a common migration issue. 
  • Try clicking menus, buttons and links to confirm they go to the right places. 
  • If your site has forms or login features, test those as well.

After that, check that your site is loading with HTTPS if it should be and that your design looks normal. Also, spend a few minutes just browsing like a real visitor. If something feels off – slow loading, broken layouts or error messages – it’s much easier to fix now than after DNS is switched. 

Once everything looks right, you can safely point your domain to the new server.

Cutting over DNS

Once you’ve tested the new environment privately, it’s time to go live. This is where your earlier preparation pays off.

Updating DNS and flushing permalinks

Start by updating the DNS records that control your website traffic (usually the A record for the root domain and the CNAME or A record for www and AAAA records if provided by your host) to point your domain to the new host’s IP address. Because you lowered TTL earlier, many visitors may switch within minutes, but DNS is not instant everywhere and some users may still see the old site for a while.

Before or immediately after going live, if you notice broken links or 404 errors, go into WordPress and flush permalinks (WordPress Dashboard → Settings → Permalinks → Save Changes). This refreshes WordPress rewrite rules and, on some hosts, may update .htaccess if supported. It’s one of the most commonly missed steps after migration.

Next, clear every layer of cache: server-side, CDN and any caching plugins. You can only clear your own browser cache, so test in an incognito/private window as well. If you’re using Pantheon, you get a Global CDN and managed HTTPS.

Keep your old host running for 7–14 days. However, avoid letting both sites accept new data (like orders, form submissions or user accounts), as this can split data between servers and make rollback difficult.

Protecting your search rankings

If your domain hasn’t changed, SEO impact is usually minimal, but mistakes still happen. Check that no noindex tags carried over from staging, confirm canonical URLs are correct and make sure your robots.txt allows crawling. Also check for noindex settings in plugins, headers or password protection that could block indexing.

If you’re changing domains, don’t run a raw SQL find-and-replace across the database. WordPress often stores URLs inside serialized data, such as widgets, theme options and plugin settings and naïve SQL replacement can break those records when the new URL has a different length. Use a serialization-safe tool such as WP-CLI search-replace or a trusted migration/search-replace plugin and run a backup and dry run first.

Additionally, SEO becomes part of the migration itself. You’ll need appropriate 301 redirects (a full map for complex changes or domain-level redirects for simple one-to-one moves), submit a “Change of Address” request in Google Search Console only if this is a supported domain/subdomain move and update your XML sitemap and resubmit it in Search Console.

Even with everything done correctly, expect some fluctuation – temporary ranking changes are normal and recovery time varies depending on site size and complexity (often a few weeks, but sometimes longer).

When to use a managed migration service

A manual or plugin-based migration is often enough for a simple WordPress site. But if your site is large, business-critical, highly customized or tied to revenue, a managed migration service can be the safer choice. The more your site depends on forms, memberships, WooCommerce orders, custom code, redirects, third-party integrations or strict uptime, the more valuable expert help becomes.

This is where Pantheon is a strong option. Pantheon offers self-guided migration resources as well as a Managed Migration Service through its Professional Services team, designed to help move existing sites to Pantheon with minimal disruption. Pantheon’s own WordPress migration guidance also recommends reviewing managed migration options before starting, especially for more complex cases. 

Not to mention, Pantheon is more than a place to host the finished site. Its WebOps platform gives teams built-in Dev, Test, Live environments, Multidev workflows, version control, caching, backups, performance tools and managed operational foundations. That means your team can test changes safely and push updates more predictably.

So if your migration feels risky, don’t treat hosting as an afterthought. Move to a platform built for safer launches and long-term site management. 

Ready to migrate with less stress? Leverage Pantheon’s Managed Migration Service today and get your WordPress site running on a WebOps platform designed for performance, reliability and confident launches!

WordPress