← InsightsSEO · 15 min read

How to migrate a WordPress site safely in 2026

By Cameron, Founder9 August 2026

The safest way to move a WordPress site is straightforward: back up everything first, copy the site to the new host and test it there, then switch DNS. For most sites, a migration plugin handles the heavy lifting. For very large or heavily customised installs, a manual file-and-database transfer gives you more control. Here is what that looks like in practice: Back up your files and database before touching anything. Set up the new host and install WordPress there. Copy the site using a plugin (All-in-One WP Migration, Duplicator, UpdraftPlus, or Migrate Guru) or manually via SFTP and phpMyAdmin. Test on a staging or temporary URL before going live. Lower your DNS TTL to 300 seconds at least 24-48 hours before cutover. Switch DNS, verify SSL, and keep the old host live for 7-14 days as a rollback. That sequence protects your data, keeps downtime to minutes rather than hours, and avoids the SEO damage that comes from a botched domain switch. ***

Key takeaways

A safe WordPress migration comes down to three non-negotiables: a verified backup, a tested staging copy, and a DNS switch only after the new site is confirmed working.

Point Details Back up and verify first Download a full backup of files and database before touching anything; confirm the archive opens. Two viable methods Plugin-based migration suits most sites; manual file transfer suits large or custom installs. URL replacement risk Never use a raw SQL find-and-replace when changing domains; use WP-CLI search-replace to avoid serialised data corruption. DNS and rollback Lower TTL to 300 seconds 24-48 hours before cutover; keep the old host live for 7-14 days after. Project-pixel migration Project-pixel offers fixed-price migrations covering staging, SSL, redirects, Search Console, and post-launch testing.

***

What does migrating a WordPress site actually involve?

A WordPress migration moves three things: your files (themes, plugins, uploads), your database (posts, settings, user data), and your configuration (wp-config.php, .htaccess). Get all three right and the site works identically on the new host. Miss one and you get white screens, broken images, or a database connection error.

The complexity scales with two factors: site size and whether the domain is changing. Moving to a new host on the same domain is relatively low-risk. Changing the domain introduces the biggest risk because every URL stored in the database needs updating, and doing that incorrectly corrupts serialised PHP data.

***

Your WordPress migration checklist at a glance

Work through this in order. Each step builds on the last.

***

01Gather credentials (hosting control panel, SFTP/SSH, database login, domain registrar, SSL management, WordPress admin). Estimated time: 15-30 minutes.
02Full backup of files and database, verified and downloaded locally. 30-60 minutes.
03Set up new host, create a database, and install a fresh WordPress copy. 30-60 minutes.
04Copy files and import database via plugin or manually. 1-4 hours depending on site size.
05Update wp-config.php with new database credentials and check WP_HOME / WP_SITEURL constants. 10 minutes.
06Test on staging or temporary URL - check pages, forms, images, and checkout if applicable. 1-2 hours.
07Lower DNS TTL to 300 seconds. Do this 24-48 hours before cutover.
08Final sync of any content added since the initial copy, then enable maintenance mode on the source site.
09Switch DNS to the new host's nameservers or A record.
10Verify SSL and confirm the site loads on https:// without mixed-content warnings.
11Keep old host active for 7-14 days in case you need to roll back.

Before you start: what to prepare and check

Credentials and access

You need login details for: your current hosting control panel (cPanel, Plesk, or equivalent), SFTP or SSH access to both servers, phpMyAdmin or direct database access on both hosts, your domain registrar account, and SSL certificate management. Write these down somewhere secure before you begin. Running out of access mid-migration is a common and avoidable delay.

Making and verifying a full backup

A backup you have not verified is not a backup. Use UpdraftPlus to create a full backup of both files and the database, then download the archive locally. Open the zip and confirm the database .sql file is present and non-zero in size. If your host provides automated snapshots, take one of those too - belt and braces.

Pro Tip: *Before migrating, check your backup file actually opens. A corrupted archive discovered after you have already deleted the source site is a very bad day.*

Staging options

Two approaches work well. A temporary domain (e.g. a subdomain your new host provides) lets you test the full site without touching DNS. A hosts-file override on your local machine points your browser at the new server while the rest of the world still sees the old one. The hosts-file method is faster to set up but only works on your own device. For team testing or client sign-off, a temporary subdomain is cleaner.

DNS TTL timing

Lower your domain's TTL to 300 seconds (5 minutes) at least 24-48 hours before you plan to switch DNS. Most registrars allow this in the DNS management panel. When TTL is still at its default (often 3,600 or 86,400 seconds), a DNS change can take hours to propagate globally. At 300 seconds, it propagates in minutes.

***

Option A: how to migrate with a plugin

This is the right route for most site owners. The general flow is the same across all major plugins: install the plugin on both the source and target site, export a package from the source, import it on the target, run a URL replacement if the domain is changing, then test and finalise.

The official Learn WordPress tutorial demonstrates this workflow using All-in-One WP Migration and explicitly recommends installing the same plugin on both sites before you begin.

Recommended plugins

All-in-One WP Migration exports the entire site - database, media, themes, and plugins - into a single .wpress file. The free version has an upload size limit on import (512 MB by default, though some hosts extend this). For larger sites, you need the paid extension. Simple interface, very beginner-friendly.

[Duplicator](https://wordpress.org/plugins/duplicator/) packages the site into an installer and archive file. You upload both to the new server and run the installer via a browser. It handles the database import and URL replacement in one go. The free version works well for small-to-medium sites; the Pro version adds scheduled backups and cloud storage.

UpdraftPlus is primarily a backup tool, but its Migrator add-on supports full site transfers. If you are already using it for backups, it is a natural choice. The free version does not include migration; that requires the paid Migrator extension.

Migrate Guru is built specifically for migrations and handles large sites well. It transfers files directly between servers rather than routing through your browser, which sidesteps PHP upload limits entirely. Free to use, with no file-size ceiling for most installs.

Feature All-in-One WP Migration Duplicator UpdraftPlus Migrate Guru Ease of use Very easy Easy Moderate Easy Cost Free (paid for large sites) Free / Pro Free backup; paid migration Free Site-size limit 512 MB free No hard limit (Pro) Depends on plan No hard limit Multisite support Paid only Pro only Paid only Yes External storage needed No No Optional No

Step-by-step plugin workflow

Pro Tip: *If your media library is large (several gigabytes), consider moving the wp-content/uploads folder separately via SFTP rather than bundling it into the plugin export. This avoids timeouts and keeps the plugin package small enough to import cleanly.*

***

01Install your chosen plugin on the source site and run an export. Download the file locally as a backup copy.
02On the target site, install the same plugin and run the import. Watch for upload-size errors - if the import fails, increase upload_max_filesize and post_max_size in php.ini, or switch to Migrate Guru which bypasses this entirely.
03If the domain is changing, run a URL replacement after import (most plugins offer this as part of the import wizard).
04Log in to the target site's WordPress admin and confirm pages, media, and plugins are intact.
05Re-save permalinks under Settings > Permalinks to flush rewrite rules.

Option B: manual migration for advanced users

Manual migration takes longer but gives you full control. It is the right choice for very large sites, custom server configurations, or any install where a plugin export times out or produces errors.

The WordPress Codex moving guide covers the canonical steps. Here is the full sequence:

The risk of serialised data corruption when changing domains is real. A raw SQL find-and-replace changes string lengths without updating the length counters that PHP serialisation stores alongside them, silently breaking widgets, theme settings, and plugin options. WP-CLI search-replace recalculates those counters automatically.

Pro Tip: *After import, go to Settings > Permalinks and click Save Changes without changing anything. This regenerates the .htaccess rewrite rules, which is the fix for most 404 errors post-migration. Also confirm the PHP version on the new host matches or exceeds the old one - a downgrade breaks plugins silently.*

***

01Export the database from the source using phpMyAdmin (Export > Quick > SQL) or via command line: mysqldump -u username -p database_name > backup.sql.
02Archive the files: on the source server via SSH, run tar -czf site-backup.tar.gz /path/to/wordpress/. This creates a compressed archive you can transfer in one go.
03Transfer to the new server via SCP (scp site-backup.tar.gz user@newhost:/path/) or SFTP using FileZilla or Cyberduck. For Windows users, PuTTY with PSCP works well.
04Extract the archive on the new server: tar -xzf site-backup.tar.gz.
05Create a new database on the target host via cPanel or the command line, then import: mysql -u username -p new_database < backup.sql.
06Edit wp-config.php to point to the new database. The wp-config.php reference documents every constant - update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. If the domain is changing, also update WP_HOME and WP_SITEURL.
07Run URL replacement if the domain is changing. Never do a blind find-and-replace on the raw SQL file. WP-CLI's search-replace command handles serialised data correctly: wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables.
08Check file permissions: wp-content should be 755, files 644. Ownership should match the web server user (typically www-data on Ubuntu).
09Test on the new server using a hosts-file override or temporary URL before switching DNS.

DNS, SSL, and the final go-live steps

The cutover sequence

Lower your DNS TTL to 300 seconds at least 24-48 hours before you plan to switch. On cutover day, follow this sequence:

01Do a final sync of any content created since the initial copy (new posts, orders, form submissions).
02Enable maintenance mode on the source site to stop new content being written.
03Import the final database snapshot to the target.
04Switch DNS: update the A record or nameservers at your domain registrar to point to the new host.
05Monitor propagation using a tool like dnschecker.org - at 300-second TTL, most regions resolve within 5-10 minutes.
06Once the new site is confirmed live, disable maintenance mode.

SSL considerations

Install the SSL certificate on the new host before switching DNS. Most UK hosts (including those using cPanel) offer Let's Encrypt via the SSL/TLS section. Confirm WP_HOME and WP_SITEURL in wp-config.php both use https://. After the switch, load the site and check for mixed-content warnings using your browser's developer console or a tool like Why No Padlock.

Rollback plan

Keep the old hosting account active for 7-14 days after cutover. If something goes wrong, you can point DNS back to the old server within minutes. This window also covers the tail end of DNS propagation for any resolvers that cached the old record at a long TTL.

***

How to protect your SEO during a migration

A migration that changes URLs or domains can damage search rankings if handled carelessly. These steps keep the damage to zero.

To test redirects, use curl -I https://olddomain.com/page/ in a terminal and confirm the response is 301 Moved Permanently with the correct Location header. Search Console's URL Inspection tool shows whether Google has indexed the new URL.

***

01301 redirects: if any URLs are changing, set up redirects from old to new before you switch DNS. The Redirection plugin handles this without server access; for server-level redirects, add rules to .htaccess. The official WordPress tutorial specifically recommends 301 redirects when the domain changes.
02Google Search Console: add the new domain as a property, submit your XML sitemap, and monitor Coverage and URL Inspection for crawl errors in the days after cutover.
03Sitemap and robots.txt: regenerate your sitemap (Yoast SEO or Rank Math do this automatically on save) and confirm robots.txt is not blocking crawlers on the new host.
04Canonical tags: check that canonical tags point to the correct new URLs, not the old domain.
05Analytics: update your Google Analytics (GA4) data stream URL and confirm tracking is firing on the new host.
06CDN and external integrations: update any CDN origin settings, third-party APIs, or CRM webhooks that reference the old domain.

Common migration problems and how to fix them

Most post-migration errors fall into a short list of causes.

Error establishing a database connection: open wp-config.php and verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST match the credentials on the new host exactly. Some hosts use localhost; others use a specific hostname. Check the wp-config.php documentation for the correct format.

500 Internal Server Error: usually a permissions or ownership problem. Set directories to 755 and files to 644. If the error persists, check .htaccess - a corrupted or incompatible rewrite block causes 500s. Replace it with the default WordPress .htaccess and re-save permalinks.

404 errors on all pages except the homepage: go to Settings > Permalinks and click Save Changes. This regenerates .htaccess rewrite rules, which is the fix for the vast majority of post-migration 404s.

Mixed-content warnings (padlock broken): the site is loading some resources over HTTP. Run a WP-CLI search-replace to update any hardcoded http:// URLs in the database, or use the Really Simple SSL plugin to catch stragglers.

White screen of death: enable WP_DEBUG in wp-config.php (define('WP_DEBUG', true);) to surface the underlying PHP error. Common causes are a plugin incompatible with the new PHP version or a missing file from an incomplete transfer.

Pro Tip: *Check your server error log first - it is usually at /var/log/apache2/error.log or /var/log/nginx/error.log. The log gives you the exact file and line number causing the error, which is faster than guessing.*

***

When should you hire a professional for a migration?

Some migrations are genuinely complex. Consider bringing in a professional when:

Project-pixel handles migrations as part of its fixed-price web design service. To get a quote, send over: your current site URL, your hosting provider and control panel type, an estimate of site size (number of pages, approximate media library size), and your preferred cutover window. Project-pixel's process covers staging setup, SSL, 301 redirects, Search Console configuration, and post-migration testing - the full checklist, not just the file transfer.

For a sense of how the process is structured end-to-end, the Project-pixel 7-stage process page outlines what happens at each stage from brief to go-live.

***

01The site is large (several gigabytes of files or a database with millions of rows).
02You are running a WordPress Multisite network.
03The server stack is custom (Nginx with custom configs, Redis, Varnish, or a bespoke PHP setup).
04You run an ecommerce store with live orders during the cutover window.
05Downtime has a direct revenue cost and you need a guaranteed sub-5-minute cutover.
06You are switching platforms entirely - for example, a WordPress to Webflow migration or moving from Squarespace to WordPress involves content restructuring that goes beyond a straight file transfer.

The simplest safe approach, in plain terms

The migration guides that get people into trouble are the ones that skip the staging step or assume the DNS switch is instant. Every migration I have seen go wrong shares one of two causes: no verified backup before starting, or DNS switched before the new site was properly tested.

The plugin route is genuinely good enough for most sites. Where people underestimate it is with large media libraries - a 4 GB uploads folder will time out on most shared hosts during a plugin import. That is not a reason to avoid plugins; it is a reason to move the uploads folder separately via SFTP and let the plugin handle the database and configuration.

Manual migration looks intimidating but it is just a sequence of copy-paste commands. The one step that trips people up is URL replacement when changing domains. A raw SQL find-and-replace feels logical but it silently corrupts serialised data. WP-CLI's search-replace is the right tool, full stop.

If you are unsure at any point, stop and ask before proceeding. A 30-minute conversation before a migration saves hours of recovery work after one.

***

Project-pixel's fixed-price migration service

Moving a WordPress site yourself is entirely possible with the steps above. But if you would rather hand it off and know it is done correctly, Project-pixel offers a fixed-price migration service with no hidden extras.

Every migration includes staging setup, SSL installation and verification, 301 redirect configuration, Google Search Console setup, and a full post-migration test before the DNS switch. You get a clear timeline, a rollback plan, and a site that works correctly on the new host from day one. No retainer required, no vague "time and materials" billing.

To request a quote, send the following to Project-pixel:

Get a fixed-price migration quote and Project-pixel will confirm scope and timeline within one working day.

***

01Your current site URL and hosting provider.
02Your new host (or ask for a recommendation).
03An estimate of site size (pages and media library).
04Your preferred cutover window.

Sources

FAQ

Why are people moving away from WordPress?

Performance, maintenance overhead, and security patching are the most common reasons. Some businesses switch to platforms like Webflow for a managed hosting environment with fewer plugin dependencies, though WordPress remains the dominant CMS for content-heavy sites.

How do I export an entire WordPress site?

Install All-in-One WP Migration or Duplicator on your site, run an export, and download the resulting archive file. For a manual export, use phpMyAdmin to export the database as a .sql file and download the wp-content folder via SFTP.

How do you migrate a WordPress site without losing SEO?

Keep URLs identical where possible, set up 301 redirects for any changed URLs, add the new domain to Google Search Console, and submit an updated XML sitemap immediately after cutover. Monitor Coverage reports for crawl errors in the following week.

How do you migrate a WordPress site without a plugin?

Export the database via phpMyAdmin or mysqldump, archive the files with tar, transfer both to the new server via SCP or SFTP, import the database, update wp-config.php with the new credentials, and run wp search-replace if the domain is changing. The WordPress Codex moving guide covers each step in detail.