How to Migrate a WordPress Site to a New Host

Downtime hurts trust and revenue, so a clean migration matters.

Moving WordPress is straightforward when you follow a disciplined plan. This guide shows you exactly how to migrate to a new host with near-zero disruption, whether you use a managed tool, a plugin workflow, or a manual file and database move. You’ll get checklists, step-by-step commands, and safe rollback paths so launch day stays calm.

White volvo semi truck on side of road — Photo by Quintin Gellar on Pexels

Pre-Migration Checklist: Prove Readiness

Inventory your stack. List the theme, child theme, core plugins, premium plugins, mu-plugins, and any custom code. Export settings for SEO, cache, forms, and backup tools. Capture a full page list and the top 20 traffic routes from analytics.

Confirm access. Verify admin logins for your current host, the new host, your domain registrar, CDN, and DNS provider. Enable two factor on all of them. Store credentials in a password manager.

Back up twice. Create two independent backups: one with your current method and one with a second tool. Keep copies off the server. If you use object storage, confirm the bucket is accessible from another network.

Lower DNS TTL. Reduce the A record TTL to 300 seconds at least 24 hours before the cutover. That change speeds propagation on launch day.

Freeze the right things. Agree on a content freeze window. For active stores, plan a brief maintenance mode during final sync, or use a delta-sync tool.

Map email and third-party services. List transactional email, payment gateways, webhooks, SSO, and any allow-listed server IPs. You’ll update SPF, DKIM, DMARC, and webhook endpoints after cutover.

Decide your path. Choose host-assisted migration, a plugin-based package, or a manual move with WP-CLI. Pick the simplest method that gives you control and a rollback path.

Choose a Migration Path That Fits Your Risk

Host-assisted migration. Many managed hosts will copy your site for you. This is ideal when time is tight, your site is large, or you lack shell access on the source. You still validate the result on staging, run your own tests, and own the cutover.

Plugin-based migration. Packaging plugins create an archive of files and database, then restore it on the new host. This is fast and simple for most single-site WordPress installs. Check your file size limits and confirm your new host allows the chosen tool.

Manual migration. You copy files and export the database yourself, then import on the new server. Manual is reliable, transparent, and works even when plugins fail. It is also the best way to learn how things really work.

Method 1: Host-Assisted Migration

Open a ticket with clear details. Provide domain, source host access, desired PHP version, and any special cache rules. Ask for a staging URL and an estimated completion window that avoids your traffic peaks.

Prepare the source. Clear cache at the application level. Disable backup and cache plugins that conflict with the host’s tools. Place a temporary notice for editors about the freeze window.

Validate on staging. When the host finishes the copy, you test with your checklist. Confirm permalinks, search, forms, checkout, media, and logged-in behavior. Check server error logs for notices that signal missing extensions.

Request a delta sync close to cutover. If edits continued during testing, ask the host to run a final differential copy right before you go live.

Method 2: Plugin-Based Migration (Package and Restore)

Package the site. Use your preferred migration plugin to build a full archive. Exclude server-generated cache directories and backup archives to reduce size.

Create the destination site. On the new host, spin up a clean WordPress instance on a temporary domain or staging URL. Install the migration plugin there.

Upload and restore. Transfer the archive and the installer script if required. Run the on-screen restore steps. Most tools recreate the database schema and import content automatically.

Fix URLs. If the staging URL differs, run a search and replace for the site URL in the database using the plugin’s tool or WP-CLI. Update home and siteurl values if needed.

Re-enable your essentials. Activate security, backup, and performance plugins that were excluded. Regenerate image thumbnails if your theme uses specific sizes.

Test everything on staging. Then move to cutover steps below.

Method 3: Manual Migration With WP-CLI

This approach avoids plugin limits and works well on any Linux-based host.

Copy files.
On the source server, create a tarball of wp-content and a copy of key configs:

tar -czf wp-content.tgz wp-content
cp wp-config.php wp-config.backup

Use rsync or SFTP to move wp-content.tgz to the new server’s document root. On the destination, extract it:

tar -xzf wp-content.tgz

Export the database.
If WP-CLI is available, run:

wp db export site.sql –add-drop-table

If not, use the host’s database tool to export as SQL with routines and triggers where applicable.

Create the database on the new host.
Create a new database, user, and strong password. Grant privileges. Note the host, database name, user, and password.
Import the database.
Upload site.sql to the destination. Then run:

wp db import site.sql

Wire up wp-config.php.
Edit DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match the new credentials. Set the correct table prefix if it is not the default. Add salts if they were missing.
Fix URLs and serialized data safely.
Run a search and replace with WP-CLI so serialized arrays stay intact:

wp search-replace ‘https://old.example.com‘ ‘https://new.example.com‘ –all-tables

Permalinks and caches.
Log in to wp-admin, visit Settings → Permalinks, and save to flush rewrite rules. Purge the server cache and your CDN cache.
Staging to production.
If you used a temporary domain, repeat the search replace for the live domain right before cutover.

Cutover Plan: Switch Traffic With Confidence

Pick a low-traffic window. Use your analytics to choose a 30 to 60 minute period with minimal risk.

Lower the blast radius. Keep the old origin running but locked behind a secret path for 24 to 48 hours. That gives you a quick fallback if something surprises you.

Update DNS. Point the A record to the new host. AAAA if you serve IPv6. With TTL at 300 seconds, most users move within minutes.

Issue SSL on the new origin. Use the host’s certificate automation or Let’s Encrypt. Confirm both www and apex names validate. Test redirect rules so every route lands on HTTPS.

Watch the health signals. Track 4xx and 5xx errors, response time on cache miss, and any spikes in PHP worker usage. Keep a real-time log tail open for the first hour.

Run a smoke test. Visit the top 20 pages and the key conversion flows. Submit a form. Place a test order if you run commerce.

Post-Migration Checklist: Close the Loop

Reenable editors. Lift the content freeze and confirm new publishes appear quickly. If you use an object cache, watch it for the first day for unexpected evictions.

Update integrations. Switch webhook endpoints, payment gateway allowed IPs, and any third-party service that references the old server. Confirm analytics tags and pixels fire as expected.

Fix email deliverability. Set SPF, DKIM, and DMARC for your sending domain. If your new host changes outbound IPs, update SPF include mechanisms and any allow lists.

Refresh sitemaps and Search Console. Regenerate sitemaps and resubmit in search consoles. Check for crawl errors and mixed content warnings.

Archive the old site. After 48 hours, snapshot the old origin and shut it down. Remove staging URLs from indexing by confirming noindex headers or robots rules are correct.

Roll Back Without Panic

Rollback is a decision, not a scramble. Keep these ready:

A DNS back-pointer. Save the old A record value so you can revert in one change if the new host fails.

A fresh database export. If you allowed edits during cutover, export the final database on the old host. If you must roll back, you can restore the latest content there.

A timed decision window. Decide in advance how long you will tolerate a degraded state. If the issue persists past that mark, roll back and regroup rather than hunt in production.

Special Cases and High-Risk Scenarios

Multisite. Confirm that your new host supports network setups, wildcard subdomains, and domain mapping. Export and import with tools that understand multisite tables. Test sub sites explicitly.

High-traffic commerce. Use a short hard freeze or a queue to capture orders during final sync. If your stack supports it, route carts to maintenance while you copy the last delta, then re open checkout after cutover.

Large media libraries. Move uploads to object storage if your library is huge. Run a background job to backfill older media while serving new requests from the origin.

Custom rewrites and redirects. Export existing rules. Validate legacy route behavior on staging with a URL list from analytics and from your SEO team.

Geographically distributed users. Enable a CDN with origin shield. Confirm cache keys and purge behavior for personalized pages so you do not leak private content.

Troubleshooting: Fast Fixes for Common Issues

White screen on load. Turn on WP_DEBUG in wp-config.php, check error logs, and disable recently added plugins via WP-CLI:

wp plugin deactivate plugin-slug

Database connection errors. Recheck DB credentials in wp-config.php and confirm the host uses the correct socket or hostname. Verify the user has privileges to the database and that the prefix matches.

Mixed content warnings. Force HTTPS in siteurl and home, update hard coded URLs in theme settings, and run a search replace for http links in content.

Infinite redirect loops. Inspect your redirect rules, reverse proxy headers, and any HTTPS forcing plugin. Ensure only one layer forces the scheme and host.

Missing images or 404s in uploads. Confirm the uploads path matches the database entries. Regenerate thumbnails and check file permissions after extraction.

Admin login loops. Clear browser cookies for the domain and check the AUTH and SECURE_AUTH cookie paths. Resave permalinks to refresh rewrite rules.

SEO, Analytics, and Stakeholder Communication

Tell stakeholders the plan. Share the timeline, the freeze window, the testing checklist, and the rollback trigger. Clear communication reduces anxiety and keeps approvals on schedule.

Protect rankings. Maintain the exact URL structure, redirects, titles, and meta descriptions. Do not change multiple variables and the host on the same day. If you must, stage changes over time.

Monitor search signals. Watch crawl stats and coverage for the first two weeks. Fix soft 404s and rogue redirects quickly. Keep your XML sitemap clean and up to date.

Verify analytics. Confirm pageview tags, conversion events, and server side tracking if used. If you change domains, update referral exclusion lists to avoid self referrals.

Security and Compliance Hygiene

Harden the new origin. Enforce strong admin passwords and 2FA, limit login attempts, and install a reputable firewall plugin if your host lacks one. Confirm file permissions and disable file editing from the dashboard.

Rotate secrets. Regenerate salts and keys in wp-config.php. Rotate any API keys that were stored on the old server and remove secrets from code repositories.

Document access. Update who has access to the new host, DNS, and registrar. Revoke old accounts that no longer need access.

Log retention. Set a sensible retention window for web server logs and application logs so you can investigate incidents without keeping data forever.

Capacity and Cost: Right-Size the New Plan

Match resources to reality. Pick PHP worker counts, memory limits, and database sizes that reflect your traffic and cache hit rates. If your site is mostly cached, CPU may not be the bottleneck. If you serve many logged-in users, concurrency matters more.

Keep a growth path simple. Favor hosts that let you scale vertically first, then horizontally, without a platform migration. Ask how upgrades work and whether they require downtime.

Count the hidden savings. Faster deploys, simpler backups, fewer late-night incidents, and reliable support lower total cost of ownership. Price those outcomes, not only the monthly invoice.

Final Takeaway

A calm migration is a checklist executed with discipline. Pick the simplest path that preserves control, test on staging like it is production, cut over during a quiet window, and keep rollback one change away. Do that, and your users will never notice you moved at all.

Frequently Asked Questions

How long should a migration take
Simple sites finish in a few hours including validation. Larger commerce or media heavy sites often plan a half day for testing and a short freeze during cutover.

Can I migrate without downtime
Yes for most brochure sites. For commerce or membership sites, plan a short freeze or a delta sync. Your goal is near zero disruption, not magical thinking.

What is the safest way to change domains during a move
Change hosts first while keeping the same domain. After traffic is steady, change the domain with a controlled search and replace, new SSL, and redirects. Avoid stacking both changes at once.

Do I need to update any licenses
Many premium themes and plugins bind to a domain. After cutover, deactivate the old activation and activate the license on the new site. Vendors usually allow reassignments.

Is a CDN required
Not required but recommended for global users and media heavy pages. A CDN reduces latency and spreads load. Keep cache rules simple to avoid stale personalized content.

What if my new host’s PHP version breaks a plugin
Pin the old PHP version on staging, update or replace the plugin, then upgrade PHP. Never upgrade PHP and deploy code changes at the same time without testing.

References