How to migrate WordPress to a new server without downtime

TL;DR: Zero-Downtime WordPress Migration Plan

To migrate WordPress without downtime, keep the old server live while you prepare the new server. Lower DNS TTL before migration, copy WordPress files and database to the new server, configure wp-config.php, test the new server using a hosts-file entry, install SSL, run a final database and uploads sync, briefly freeze writes if the site accepts orders or user content, update DNS to the new server IP, clear cache/CDN, and monitor both servers. For WooCommerce, membership, LMS, and booking sites, true zero downtime is harder because new orders, users, and payments can be created during migration.

Can You Really Migrate WordPress With Zero Downtime?

Yes, for many blogs, business websites, portfolios, and brochure sites, you can migrate with no visible downtime. The old server stays online while you build and test the new server. Visitors continue using the old server until DNS points them to the new one.

For dynamic websites, “zero downtime” needs more care. WooCommerce stores, membership websites, LMS platforms, booking systems, forums, and sites with active form submissions can receive new database changes while you are copying the site. If you do not handle the final database sync properly, you can lose recent orders, users, comments, form entries, or bookings.

Simple rule:

• Static or mostly content sites: near-zero downtime is straightforward.
• Sites with user-generated data: use a short write freeze, maintenance window, or advanced live sync.
• WooCommerce stores: plan carefully because orders and payments can happen during the migration.

Before You Start: Migration Checklist

Do not start by changing DNS. DNS cutover should happen near the end, after the new server is fully tested.

Prepare these first:

• Old server login details.
• New server login details.
• Domain DNS access.
• SFTP/SSH access.
• Database access or WP-CLI access.
• Full files backup.
• Full database backup.
• SSL certificate plan for the new server.
• Cache/CDN access.
• Email/DNS records list.
• Rollback plan.
• Low-traffic migration window.

If you do not control DNS, ask the domain owner to be available during the cutover. A technically perfect migration can still fail if DNS access is delayed.

Step 1: Lower DNS TTL Before Migration

DNS TTL controls how long DNS resolvers may cache an old DNS record. If the TTL is high, some visitors may continue reaching the old server for longer after you change the A record.

Recommended timing:

• Lower TTL 24 to 48 hours before migration if possible.
• Use a short TTL such as 300 seconds where supported.
• Do not change nameservers during the same migration unless necessary.
• Keep MX, TXT, DKIM, SPF, and other email records unchanged unless email is also moving.

DNS records to check:

• A record for root domain.
• A or CNAME record for www.
• Any subdomains used by WordPress.
• CDN/proxy status.
• MX records for email.
• TXT records for SPF, DKIM, DMARC, verification, and services.

Do not move email records accidentally when migrating only the website. Website hosting and email hosting may be separate.

Step 2: Prepare the New Server

Set up the new server before copying the site. The goal is to make the new server ready enough that WordPress can run immediately after files and database are copied.

New server checklist:

• Install the correct web server: Nginx, Apache, LiteSpeed, or OpenLiteSpeed.
• Install a supported PHP version.
• Install required PHP extensions.
• Create a new database.
• Create a database user and password.
• Configure virtual host/server block for the domain.
• Set document root correctly.
• Configure file ownership and permissions.
• Prepare SSL certificate.
• Configure PHP memory, upload size, and execution time.
• Enable OPcache.
• Set up Redis/object cache if used.

Common PHP extensions WordPress may need:

• mysqli
• curl
• gd or imagick
• mbstring
• zip
• intl
• xml
• openssl

Match the old server’s PHP version first if compatibility is uncertain. After migration, you can test and upgrade PHP properly.

Step 3: Take a Full Backup of the Old Site

Before migration, back up both files and database. A files-only backup is not enough because WordPress content, users, plugin settings, WooCommerce orders, forms, and options live in the database.

Back up files:

tar -czf wordpress-files-backup.tar.gz /path/to/wordpress

Back up database with WP-CLI:

wp db export before-migration.sql

Back up database with mysqldump:

mysqldump -u database_user -p database_name > before-migration.sql

Backup safety checklist:

• Confirm the database export completed successfully.
• Store backup outside the public web root.
• Download a copy locally or to off-server storage.
• Do not leave SQL files publicly accessible.
• Keep the old server unchanged until the new server is verified.

Step 4: Copy WordPress Files to the New Server

Copy all WordPress files from the old server to the new server. This includes core files, themes, plugins, uploads, mu-plugins, custom files, verification files, and any special directories used by your site.

Common folders and files to copy:

• wp-admin/
• wp-includes/
• wp-content/
• wp-config.php
• .htaccess if using Apache/LiteSpeed
• Custom verification files
• Static files in the web root
• Any custom directories outside normal WordPress folders

Copy files with rsync:

rsync -avz --progress /path/to/wordpress/ user@new-server:/path/to/new/wordpress/

Copy only wp-content when WordPress core is already installed:

rsync -avz --progress /path/to/wordpress/wp-content/ user@new-server:/path/to/new/wordpress/wp-content/

For near-zero downtime, rsync is useful because you can run it once for the initial copy and again later for the final delta sync.

Step 5: Import the Database on the New Server

Create the database on the new server, then import the database backup.

Import with WP-CLI:

wp db import before-migration.sql

Import with MySQL:

mysql -u new_database_user -p new_database_name < before-migration.sql

After import:

• Confirm database tables exist.
• Confirm table prefix matches wp-config.php.
• Check database user permissions.
• Check character set and collation if relevant.
• Do not delete the old database yet.

Step 6: Update wp-config.php on the New Server

If the new server uses a different database name, username, password, or host, update wp-config.php.

Database settings:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_strong_password' );
define( 'DB_HOST', 'localhost' );

Check table prefix:

$table_prefix = 'wp_';

The prefix must match your imported database tables. If your tables are named abc_posts, the prefix should be abc_.

Optional temporary URL constants:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Use fixed URL constants carefully. They can help during migration, but they override database values while present. Remove them later if you want WordPress URL settings controlled from the database/dashboard.

FyrePress tool: Use the FyrePress wp-config.php Builder to generate reviewable configuration constants before editing a live file.

Step 7: Test the New Server Without Changing DNS

Do not switch DNS until the new server works. The safest method is to test the domain on the new server using your local hosts file. This lets only your device see the new server while everyone else still sees the old live site.

Hosts file entry example:

203.0.113.10 example.com
203.0.113.10 www.example.com

Hosts file locations:

• macOS/Linux: /etc/hosts
• Windows: C:\Windows\System32\drivers\etc\hosts

Test these areas:

• Homepage.
• Important posts and pages.
• Admin login.
• Media library.
• Forms.
• Search.
• Permalinks.
• WooCommerce product pages if used.
• Cart and checkout if used.
• Account/login pages.
• REST API endpoints.
• Sitemap.
• Robots.txt.

Remove the hosts-file entry after testing so your computer uses public DNS again.

Step 8: Fix Permalinks and Server Rewrite Rules

If pages or posts show 404 on the new server, check rewrite rules and permalinks.

Apache/LiteSpeed

Make sure .htaccess exists and contains WordPress rewrite rules. Then go to Settings → Permalinks and save.

Default WordPress .htaccess rules:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Nginx

Nginx does not use .htaccess. Your server block needs a WordPress-friendly try_files rule.

location / {
    try_files $uri $uri/ /index.php?$args;
}

WP-CLI rewrite flush:

wp rewrite flush --hard

Step 9: Install SSL on the New Server

SSL must work before you switch DNS or immediately after DNS points to the new server, depending on your certificate method. If the site uses HTTPS on the old server, it should use HTTPS on the new server too.

SSL checklist:

• Install SSL certificate for root domain.
• Install SSL certificate for www if used.
• Test HTTPS with hosts-file mapping where possible.
• Check mixed content warnings.
• Confirm HTTP to HTTPS redirects work.
• Check admin login over HTTPS.
• Check payment/checkout pages if WooCommerce is used.

wp-config.php force SSL admin:

define( 'FORCE_SSL_ADMIN', true );

If your SSL certificate depends on DNS validation or Let’s Encrypt HTTP validation, plan certificate timing carefully during cutover.

Step 10: Run Search-Replace Only If the Domain Changes

If you are moving to a new server but keeping the same domain, you usually do not need a domain search-replace. If you are changing from a temporary URL, staging URL, HTTP to HTTPS, or old domain to new domain, use a safe serialized-data-aware tool.

Dry run first:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run

Run actual replacement:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --skip-columns=guid

Export transformed SQL instead of changing database directly:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --export=updated.sql

Common replacements:

• http://example.com to https://example.com
• https://staging.example.com to https://example.com
• https://old-domain.com to https://new-domain.com

Avoid raw SQL search-replace for WordPress URLs because serialized data can break when string lengths change. WP-CLI search-replace is safer for WordPress databases.

Step 11: Final Sync Before DNS Cutover

After testing, run a final sync to capture changes made since the first copy. This is especially important for uploads, cache files, form uploads, and database changes.

Final files sync:

rsync -avz --progress /path/to/wordpress/wp-content/uploads/ user@new-server:/path/to/new/wordpress/wp-content/uploads/

Final database export/import for low-change sites:

# Old server
wp db export final-migration.sql

# New server
wp db import final-migration.sql

For dynamic sites:

• Pause new orders or put checkout in maintenance briefly.
• Pause comments, forms, booking, or membership registration if needed.
• Export and import the final database after writes are paused.
• Run final uploads sync.
• Switch DNS immediately after final sync.
• Re-enable writes on the new server.

For WooCommerce, do not run a final database import after new orders have already started on the new server unless you know exactly what you are doing.

Step 12: Update DNS to the New Server

Once the new server is tested and final sync is complete, update DNS records to point to the new server IP.

Common DNS changes:

example.com      A      NEW_SERVER_IP
www.example.com  A      NEW_SERVER_IP

If www uses a CNAME, confirm it points to the correct root domain or target.

After DNS update:

• Do not immediately delete the old server.
• Keep old server running for at least 24 to 72 hours.
• Monitor access logs on both servers.
• Check DNS propagation with multiple resolvers.
• Watch forms, checkout, and admin login.
• Clear CDN cache if used.

Some visitors may still reach the old server until DNS caches expire. That is why keeping the old server online matters.

Step 13: Clear Cache, CDN, and Object Cache

After DNS cutover, clear all relevant cache layers. Old cached pages can show outdated URLs, old assets, or content from the wrong server.

Clear these caches:

• WordPress cache plugin.
• Server cache.
• Object cache such as Redis or Memcached.
• CDN cache.
• Browser cache during testing.
• Page builder CSS cache if used.
• WooCommerce transients if needed.

WP-CLI cache commands:

wp cache flush
wp transient delete --expired
wp rewrite flush --hard

Step 14: Post-Migration Testing Checklist

After DNS starts pointing to the new server, test the site like a visitor, admin, customer, and search engine.

Frontend checks:

• Homepage loads.
• Internal pages load.
• Blog posts load.
• Images load.
• CSS and JavaScript load.
• Menus work.
• Search works.
• Forms submit.
• 404 page works.
• Redirects work.

Admin checks:

• Login works.
• Dashboard loads.
• Media library works.
• Plugin pages load.
• Permalinks work.
• Updates work.
• WP-Cron works.
• Error logs are clean.

SEO checks:

• Canonical URLs are correct.
• Sitemap loads.
• Robots.txt loads.
• No unexpected noindex tags.
• HTTP to HTTPS redirects work.
• www/non-www canonical redirect works.
• Important 301 redirects still work.
• Google Search Console property still verifies.

FyrePress tool: If you see 500 errors, PHP warnings, slow requests, or migration-related log entries, use the FyrePress Server Log Analyzer.

Special Case: WooCommerce Migration Without Downtime

WooCommerce migrations are harder because orders, carts, customers, stock, subscriptions, and payment callbacks can change at any time.

WooCommerce-specific risks:

• Orders placed on the old server after the database copy.
• Customer accounts created during DNS propagation.
• Payment webhooks hitting the wrong server.
• Stock changes not synced.
• Subscription renewals running during migration.
• Abandoned cart/session data split across servers.
• Emails sent from both old and new server.

Safer WooCommerce migration plan:

1. Lower DNS TTL in advance.
2. Copy and test the site on the new server.
3. Schedule migration during low order volume.
4. Temporarily pause checkout or put the store in maintenance mode for final sync.
5. Export/import the final database after checkout is paused.
6. Sync uploads.
7. Switch DNS.
8. Test checkout with a small real or sandbox transaction.
9. Update payment webhook URLs if needed.
10. Monitor orders, emails, and payment logs.

For high-volume stores, consider professional migration support, database replication, or a controlled maintenance window. Losing orders is worse than showing a short maintenance notice.

Special Case: Migrating to a New Domain

Moving to a new server with the same domain is simpler than moving to a new domain. If the domain changes, you need URL replacement, redirects, SEO checks, and possibly Search Console updates.

New domain checklist:

• Import files and database to the new server.
• Update home and siteurl.
• Run WP-CLI search-replace with --dry-run first.
• Set 301 redirects from old domain to new domain.
• Update canonical URLs.
• Update sitemap URL.
• Update robots.txt if needed.
• Update Google Search Console and analytics tools.
• Update hardcoded links in theme files if any.
• Update CDN, firewall, and third-party service domain settings.

Example search-replace:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid

If only the server changes and the domain stays the same, do not run unnecessary domain replacement.

Manual Migration vs Plugin Migration

You can migrate WordPress manually or with a migration plugin. Both can work, but they fit different situations.

For FyrePress-style developer tutorials, manual migration is worth learning because it gives you control over DNS, database, files, cache, SSL, and rollback.

Rollback Plan If Something Goes Wrong

A good migration plan includes rollback before the migration starts. Rollback means you can send traffic back to the old working server if the new server has a serious issue.

Rollback checklist:

• Keep old server running after DNS cutover.
• Do not delete old files or database.
• Keep old DNS record details saved.
• Keep old SSL active if possible.
• Do not cancel old hosting immediately.
• Keep backups from before migration.
• Document what changed during migration.

Rollback process:

1. Change DNS A record back to old server IP.
2. Clear CDN/proxy cache if used.
3. Check old server still serves the site.
4. Disable writes on the broken new server if necessary.
5. Investigate new server issues without losing old-site data.

Rollback is easiest when you kept TTL low and did not shut down the old server too early.

Common Migration Mistakes to Avoid

• Changing DNS before testing the new server.
• Forgetting to lower DNS TTL before migration.
• Copying files but not the database.
• Importing an old database after new orders already happened.
• Leaving old SQL backups in the public web root.
• Forgetting to update wp-config.php database credentials.
• Forgetting Nginx rewrite rules or Apache .htaccess.
• Skipping SSL testing.
• Not checking forms and checkout after migration.
• Forgetting to clear cache/CDN.
• Deleting the old server immediately after DNS change.
• Moving email DNS records accidentally.
• Running search-replace when the domain did not change.
• Using raw SQL replacement and breaking serialized data.

Best Migration Method by Website Type

For small blogs

Copy files and database, test with hosts file, switch DNS, and keep the old server online for a few days. Downtime risk is low if comments are paused during final sync.

For business websites

Test forms, analytics, redirects, SSL, and contact emails carefully. Run a final database sync after pausing form submissions briefly if leads are important.

For WooCommerce stores

Use a short maintenance window or checkout freeze for the final database sync. Test payment gateways, webhooks, order emails, stock, cart, checkout, and account pages before fully declaring migration complete.

For membership and LMS sites

Pause registration, payments, and course activity briefly during final sync. Test login, user roles, protected content, course progress, and payment access after cutover.

For agencies

Use a repeatable checklist: backup, TTL, file copy, database import, hosts-file test, final sync, DNS cutover, cache clear, QA, monitoring, and rollback.

For developers

Use WP-CLI, rsync, database exports, hosts-file testing, log monitoring, and scripted post-migration checks. For high-change sites, plan data synchronization more carefully than a simple file/database copy.

WordPress Migration Command Cheat Sheet

Export database:

wp db export before-migration.sql

Import database:

wp db import before-migration.sql

Copy files:

rsync -avz --progress /old/path/ user@new-server:/new/path/

Final uploads sync:

rsync -avz --progress /old/path/wp-content/uploads/ user@new-server:/new/path/wp-content/uploads/

Check site URLs:

wp option get home
wp option get siteurl

Update site URLs if needed:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Safe search-replace:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid

Flush cache and rewrites:

wp cache flush
wp rewrite flush --hard

Final Recommendation

The safest way to migrate WordPress to a new server without downtime is to keep the old server live until the new server is fully ready. Lower DNS TTL early, copy files and database, test the new server through a hosts-file entry, configure SSL, run a final sync, switch DNS, clear cache, and monitor both servers.

For simple sites, this process can feel almost seamless. For WooCommerce, membership, LMS, and booking websites, plan a short write freeze or controlled maintenance window so new orders, users, payments, and form entries are not lost.

Do not rush DNS. The migration is successful only when the new server is tested, the final data is synced, SSL works, redirects are correct, forms and checkout work, logs are clean, and rollback is still available.

Frequently Asked Questions

Can I migrate WordPress to a new server without downtime?

Yes, many WordPress sites can be migrated with no visible downtime by preparing the new server while the old server stays live, testing privately, running a final sync, and switching DNS only after the new server is ready.

What is the safest way to migrate WordPress?

The safest method is to take full backups, lower DNS TTL, copy files and database to the new server, test using a hosts-file entry, configure SSL, run a final sync, update DNS, clear cache, and keep rollback available.

How do I test a migrated WordPress site before changing DNS?

Add the new server IP and domain to your local hosts file. This makes only your computer load the domain from the new server while public visitors still use the old server.

Do I need to run search-replace when moving WordPress to a new server?

Not always. If the domain stays the same, search-replace is usually not needed. If the domain, protocol, or temporary URL changes, use WP-CLI search-replace with a dry run first.

How long should I keep the old server after migration?

Keep the old server running for at least 24 to 72 hours after DNS cutover. This protects visitors still reaching the old IP due to DNS caching and gives you rollback time.

How do I migrate WooCommerce without losing orders?

Schedule a low-traffic window, pause checkout or put the store in maintenance mode for the final database sync, import the latest database to the new server, switch DNS, then test checkout and payment webhooks immediately.

Can I use a plugin to migrate WordPress without downtime?

Yes, migration plugins can work for small and medium sites. For large, high-traffic, or dynamic sites, manual migration with WP-CLI, rsync, and controlled final sync usually gives more control.

What DNS record do I change during WordPress migration?

Usually you update the A record for the root domain and the A or CNAME record for www. Keep email records such as MX, SPF, DKIM, and DMARC unchanged unless email is also moving.

Why does my migrated WordPress site show 404 errors?

Common causes include missing Apache .htaccess rules, missing Nginx try_files rules, unflushed rewrite rules, incorrect document root, or permalink settings needing to be saved again.

What should I do if the new server breaks after DNS cutover?

Change DNS back to the old server IP, clear CDN cache if used, keep the old server active, and investigate the new server issue using logs and backups. This is why rollback planning matters.