WordPress Migration: A Step-by-Step Checklist for a Smooth Move

A WordPress migration is one of those “high impact, high anxiety” projects. You’re moving the foundation your marketing, support, and product teams rely on – so you don’t want a single broken form, missing image, or surprise drop in search engine rankings.

The good news: the migration process is very doable with a plan.

In this guide, you’ll get:

• A pre-flight checklist (before you touch anything).
• A practical way to choose manual vs. a WordPress migration tool vs. migration plugins.
• The reliable manual migration flow (files, WordPress database,wp-config.php, and search replace).
• A post-migration QA checklist to confidently ship your live site.
• Fast fixes for the most common migration issues (hello, white screen).

TL;DR:

• Start with backups, access, compatibility checks, and a rollback plan.
• Choose your migration method based on complexity, downtime tolerance, and risk.
• Manual migrations are predictable, but demands technical knowledge and careful search/replace.
• Plugin-based migrations are fast for most sites, especially when you need repeatability across multiple WordPress websites.
• Post-migration QA is not optional; it’s how you catch silent failures (forms, media, redirects, SEO tags).

What is a WordPress website migration?

A WordPress website migration is the process of moving your entire site (WordPress files, site’s database, domain/DNS settings, and environment configurations) from one place to another without breaking functionality.

That move could be:

• New host / new server – Moving your current WordPress site to a different hosting provider.
• Domain change – Switching from an old domain to a new domain (or merging brands).
• HTTP → HTTP – Migrating to SSL and cleaning up mixed content.
• Staging → production – Promoting an existing site build from staging to the live site.
• Redesign or rebuild – The same domain with a new theme, new plugins, and/or new custom settings.
• Multisite moves – Shifting a network, splitting a subsite into a standalone WordPress setup, or replatforming a multisite network.

For larger organizations with multi-brand, multi-market web ecosystems, WordPress site migration is rarely “one site, one time.” It’s often a repeatable playbook you run every quarter: launches, localization waves, rebrands, and platform consolidation.

WordPress migration checklist

Before you migrate WordPress, do this. It will save you hours (and a few grey hairs).

1. Create a full backup and prove it restores

You want at least two backups:

• A full backup file of all the files – WordPress core, wp-content, and uploads.
• A database export – your SQL file.

If your backup is stored off-server (cloud storage like Google Drive, S3, or Dropbox), even better.

How-to checks:

• Confirm the backup contains /wp-content/uploads as missing media means that everything looks fine until it doesn’t.
• Confirm you can restore to a staging environment, not just download a zip.

2. Collect access credentials

You’ll likely need:

• WordPress admin login for the existing WordPress site.
• Hosting control panel access, such as cPanel, Plesk, or host dashboard.
• FTP/SFTP credentials or SSH.
• Database credentials, including database name, username, password, and host.
• DNS access (registrar or DNS provider).
• CDN/WAF access, e.g., Cloudflare, if you use it.

3. Inventory plugins, themes, and integrations

Create a quick inventory of:

• Active theme and child theme.
• Active plugins, especially security, caching, membership, WooCommerce, forms.
• Integrations: email provider, analytics tags, payment gateways, CRM, CDN, object cache, SMTP plugins.

This is also the right moment to remove dead weight (old plugins, abandoned themes, unused integrations). Less to migrate means less to break.

4. Check PHP/MySQL compatibility and the latest versions

A lot of migration issues are really environment mismatches:

• PHP version differences (7.4 vs 8.x is a common culprit).
• MySQL/MariaDB versions.
• Storage limits and upload limits.
• File permission behavior.
• Server-level caching differences.

If you’re moving to a new host, ask them what their recommended “latest versions” are for WordPress and PHP, and mirror that in staging first.

5. Plan for downtime – as little as possible

Decide upfront:

• Do you need true near-zero downtime, or is a 15–60 minute maintenance window acceptable?
• Will you put the existing website into maintenance mode?
• What’s your rollback plan if something goes wrong?

6. Reduce DNS pain: adjust TTL

If you’re changing DNS records, lower your DNS TTL (time-to-live) 24–48 hours before go-live so changes propagate faster.

7. Get stakeholder sign-off and set up issue tracking

For enterprise teams, the migration is half technical and half coordination.

Have these ready:

• A stakeholder sign-off checklist – what “done” means.
• A clear QA owner.
• An issue tracking tool so feedback doesn’t get lost in Slack.

Marker.io is useful here because stakeholders can leave visual feedback directly on the destination site during verification, and every report includes technical context – URL, browser, device, console logs – so fixes are easier to reproduce.

Marker.io is one of the best tools for WordPress migration feedback collection. You can also use a traditional ticketing tool like Jira, but the big advantage of Marker.io is that it enables you to capture screenshots on-site and, thanks to integrations with project management tools, send them to the right team members directly.

Here’s a quick table to compare visual bug reporting vs. traditional ticketing for WordPress moves.

Manual vs. automated – choosing a WordPress migration tool

There are three common ways to migrate a WordPress site:

1. Manual migration – FTP + database export/import + config updates.
2. Migration plugins – Package/export/import inside WordPress.
3. Host-assisted migration – Your hosting provider does it.

When a WordPress migration tool or plugin is the better choice

A migration tool shines when you want:

• Speed and repeatability – You’re doing multiple site migrations and need a consistent workflow.
• Fewer steps – Just a few clicks is realistic for standard sites.
• Safer search replace – Good tools handle serialized data properly.
• Better logs – You can see what was copied, what failed, and why.

When manual migration is safer

Manual migration is often the better choice when:

• You have a complex setup – Custom server configs, unusual file structure, custom tables.
• The site is huge – larger sites with massive uploads directories.
• You need precise control over the upload process, caching layers, or security rules.
• Your destination environment requires custom settings you want to apply deliberately.

Quick decision factors

Use this as your gut-check:

• Site size – Bigger sites push you toward manual or premium tooling.
• Downtime tolerance – Lower downtime tolerance pushes you toward proven plugins or host-assisted approaches.
• Access level – If you don’t have SSH/DB access, plugins or host migrations may be the only option.
• Risk – E-commerce, memberships, and forms increase risk; you’ll want a tighter QA plan either way.

Read our guide to e-commerce accessibility to reduce risk on your website even more.

How to do a WordPress site migration manually

Manual migration sounds scary. It’s not, as long as you follow a reliable order and don’t skip all the checks.

The basic manual migration flow

You will:

1. Copy WordPress files from the old site.
2. Export the WordPress database as a SQL file.
3. Create a new database on the destination site.
4. Import the SQL file.
5. Update wp-config.php and server settings.
6. Run search and replace carefully.
7. Flush permalinks and clear caches.
8. QA everything before you switch DNS.

Copy the site files

What to move:

• /wp-content/ for themes, plugins, uploads.
• WordPress core files, unless you plan a fresh WordPress installation on the new server.
• Configuration files like .htaccess file, like Apache, or Nginx config equivalents.

How-to options:

• FTP client is simple, but slower.
• SFTP/SSH + rsync is faster and more reliable.
• Host file manager in your control panel is OK for smaller moves.

Where mistakes happen:

• Uploads folder not fully copied, such as missing images and broken uploads.
• Incorrect permissions, especially on hosts that handle ownership differently.
• Forgetting hidden files, like .htaccess.

Export and import the database

Export from the old host:

• Use phpMyAdmin export method, Adminer, or CLI like mysqldump.
• Save the SQL file somewhere safe, such as using cloud storage, is fine.

Create a new database on the new host:

• In your control panel, create:
  • A database name.
  • A database user.
  • A password and store it securely.

Import (new host):

• phpMyAdmin import tab for smaller databases.
• CLI import for larger databases, as it’s more stable.

What to check for errors:

• Timeouts during import.
• Collation/charset mismatches.
• Missing tables, especially for WooCommerce and membership plugins.

Update wp-config.php and server settings

On the destination site, update wp-config.php with your new database credentials:

• DB_NAME is your new database or database name.
• DB_USER / DB_PASSWORD.
• DB_HOST (sometimes not localhost).

Also watch for:

• Table prefix ($table_prefix) if it’s not wp.
• Environment-specific configs, like cache keys, salts, and SMTP settings.
• If you’re hardening configs, keep enhanced security changes consistent.

Run search and replace safely

If you changed the domain, or even moved between environments (like staging URLs), you’ll need search and replace.

What you’re replacing:

• Old domain → new domain
• Old paths → new paths (occasionally)
• Protocol updates (http → https)

Serialized data pitfall:

WordPress stores some data in serialized arrays. A naive “find/replace” can corrupt it.

Safe approaches:

Use WP-CLI search replace (recommended when you have SSH access):

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables --dry-run ‍

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables

Here are two alternatives:

• Use a plugin specifically designed to handle serialized replacements.
• Use a migration tool that includes safe find/replace and WP-CLI support.

Fix permalinks and basic settings

Once the site loads on the destination site:

• Go to Settings → Permalinks and click Save, which flushes the rewrite rules.
• Confirm Site Address (URL) and WordPress Address (URL) are correct.
• Clear caches – plugin caches and host caches.

WP-CLI cache flush can help if you use it: wp cache flush


At this point, your manual migration is complete enough to start QA on staging before go-live.

The best WordPress migration plugins – what to look for before you install one

There’s no single “best WordPress migration plugin” for every situation. But there are features that matter if you want a predictable, low-drama WordPress site migration.

Here’s what to look for:

• Large site support – Can it handle big backup file sizes, large media libraries, and long runtimes?
• Serialized search-replace – This is non-negotiable if you’re changing domain.
• Minimal downtime – Ideally, you can build a package, transfer, then switch over quickly.
• Good logging – You want a clear success/failure report, not vibes.
• Easy restore/rollback – One-click restore is ideal.
• Cloud storage options – Google Drive, Dropbox, S3, and OneDrive are all helpful for moving packages.
• Works with your host – Managed hosts sometimes block certain plugin behaviors.
• Multisite support – If you run multisite, confirm the plugin explicitly supports it.

A few popular options teams often evaluate include Duplicator, All-in-One WP Migration, Migrate Guru, and WP Migrate – but focus on fit, not hype.

Plugin-based WordPress migration (quick path for most sites)

For many teams, plugin-based migration is the fastest way to migrate your WordPress site with fewer manual steps.

The usual flow looks like this:

1. Prep the source site

Before you create the package:

• Update WordPress, themes, and plugins (within reason).
• Temporarily disable caching/minification plugins to reduce weird edge cases.
• Make sure you have enough disk space to generate the archive.

2. Create a package and exporting

Most migration plugins will generate either a single ****file archive and installer, or a backup bundle you can import on the new site

3. Transfer to the destination site

Typical options:

• Upload via plugin UI.
• Upload via FTP/SFTP.
• Pull from cloud storage (Google Drive, etc.).

4. Install on the destination site

Depending on the tool, you might install WordPress fresh (clean WordPress installation), then import the package, or run an installer script.

5. Validate and clean up

After import:

• Re-enable caching carefully.
• Confirm file permissions.
• Remove installer files / leftover archives.
• Rotate secrets if needed (keys/salts).

This path is often truly “just a few clicks” for straightforward sites, and it scales nicely if you’re doing repeatable migrations across multiple WordPress websites.

Host-assisted WordPress site migration

Many managed WordPress hosts advertise free migration. It’s real, and it’s useful – but it’s not always the right solution for you.

What “free migration” usually includes

• Copying WordPress files and the WordPress database.
• Getting the site working on the new host environment.
• Basic checks that the site loads.

What it may exclude (plan for this)

• Email migration, including mailboxes, MX records.
• DNS configuration beyond basic guidance.
• Custom server configs and unusual .htaccess file rules.
• Third-party CDN configuration.
• Cleanup of mixed content, redirects, or SEO polish.
• Full QA of user journeys, such as checkout, membership, lead flows, and CTAs.

What to prepare to avoid back-and-forth

Send your hosting provider:

• Admin credentials or temporary access.
• Source host access (control panel, SFTP, DB).
• Any custom settings that must be mirrored (caching, PHP version, redirects).
• A list of critical pages and flows to verify after cutover.

WordPress data migration details that commonly break a site

Here are the common WordPress data migration gotchas:

• Serialized data – Breaks if you do a naive search replace.
• CDN/media URLs – Images can still point to the old site domain or old CDN paths.
• Hard-coded theme URLs – Some themes embed absolute URLs in templates or page builder settings.
• Custom tables – CRMs, memberships, and e-commerce plugins may create extra tables you must migrate.
• WooCommerce order data – Orders, customers, and transaction logs must be intact – and you should validate checkout on staging.
• Forms – Forms “work” visually but fail silently (SMTP issues, blocked API calls, missing keys).

Quick checks to confirm nothing silently failed

Do these checks on your destination site before you go live:

• Submit every important form, for instance your lead gen, support, demo request, and contact sales forms
• Place a test order if applicable
• Check the Media Library for random older images
• Scan for 404s on high-traffic pages
• Confirm tracking scripts, analytics tags, and pixels still fire

Post-migration QA: How to verify your WordPress migration was successful

Here’s a practical verification checklist you can run every time.

Core pages and templates

Functional flows

Media and content integrity

SEO essentials

Performance and caching

Logs and error monitoring

Compare staging vs. production

If you’re moving from staging to production:

‍

Tip: tools like Marker.io’s website feedback widget help here because reviewers can mark up issues directly on the migrated pages, and developers get the exact URL and environment data without playing detective.

Troubleshooting common WordPress migration issues

White screen after migration

Potential causes:

• Fatal PHP error.
• Plugin conflict.
• PHP version mismatch.
• Memory limit too low.

Fixes:

• Enable debug mode in wp-config.php:
  • define('WP_DEBUG', true);.
  • define('WP_DEBUG_LOG', true);.
• Temporarily disable plugins by renaming /wp-content/plugins/ to /wp-content/plugins_old/.
• Check PHP version on the new host and align it with what the site expects.
• Increase memory limit if needed.

Broken links and mixed content

Potential causes:

• HTTP/HTTPS mismatch.
• Incomplete search replace.
• Cached old URLs.

Fixes:

• Re-run safe search replace.
• Clear all caching layers (plugin + host + CDN).
• Force HTTPS and update any hard-coded URLs.

Missing images or broken uploads

Potential causes:

• Incomplete uploads migration.
• Wrong file paths.
• Bad permissions on wp-content/uploadsthe.

Fixes:

• Re-copy the uploads directory (prefer rsync/SFTP for reliability).
• Fix permissions/ownership on the server.
• Confirm the site URL is correct and not pointing to the old domain.

Login or admin issues

Potential causes:

• Site URL mismatch (home URL vs site URL).
• Cookies/sessions confused after domain change.
• Security plugin blocking access.
• Old .htaccess rules not compatible.

Fixes:

• Confirm WordPress Address and Site Address match the destination site domain.
• Clear cookies and try incognito.
• Temporarily disable security plugins.
• Regenerate permalinks and review .htaccess file rules.

How much does a WordPress migration cost?

Costs vary wildly because WordPress migration can mean anything from a simple host move to an enterprise-grade rebuild with integrations, localization, and heavy QA.

Here are realistic ranges by approach:

DIY migration (time cost)

• A few hundred dollars in direct spend, maybe for a paid plugin.
• Your real cost is internal time: planning, doing the move, validating, and fixing issues

Paid migration plugins

Many have a free version, but serious migrations often require paid tiers for larger sites, multisite support, or cloud storage.

Hosting provider migration

• Often included with your hosting plan, so “free” but bundled into monthly costs.
• Great when you want speed and a known path, but you still need to QA outcomes.

Freelancer or agency support

The cost of this will have many factors, principal among them the complexity of the migration and how involved the agency/freelancer will be.

A simple migration can, for example, cost a few hundred to a couple thousand dollars, whereas enterprise-level migrations can go much higher when you include integrations, custom dev, SEO work, content migration, and structured QA.

What drives the price up

• Larger sites – Big media libraries and databases.
• E-commerce complexity – WooCommerce, subscriptions, memberships, number of sites.
• Downtime constraints – Near-zero downtime adds process and testing.
• Extra environments – Multiple staging layers.
• Required QA rigor – Especially if multiple teams must sign off.

Conclusion

A WordPress migration doesn’t have to be chaos.

The clean path is consistent:

1. Start with the checklist, covering backups, access, compatibility, rollback, and DNS planning.
2. Pick the right migration method, whether it’s manual, plugin, host-assisted, or partially automated.
3. Prioritize data integrity.
4. Run a structured QA before and after you cut over.

If your WordPress migration involves multiple stakeholders reviewing migrated pages, try Marker.io. It helps teams collect visual feedback and bug reports directly on the site – so post-migration fixes stay organized, actionable, and easy to reproduce.

WordPress migration FAQs

Why do WordPress pages become white after migration?

Usually, it’s a fatal error caused by a plugin conflict, PHP version mismatch, or a memory limit issue. Enable debug logging in wp-config.phpthe , check error logs, and disable plugins to isolate the cause.

How much does a WordPress migration cost?

It ranges from near $0 (DIY) to paid plugins, to hosted migrations bundled with plans, to enterprise migrations where scope grows with integrations, SEO, and QA.

How do I verify if a WordPress migration was successful?

Run a structured post-migration QA: key pages, forms, login flows, media library, SEO basics (robots.txt, sitemaps, redirects), analytics tags, performance, and error logs. Compare staging vs production when relevant.

How do I triage migration bugs into the backlog from website feedback tools?

Use a visual bug reporting tool like Marker.io. For a WordPress move, this is faster for post-migration QA because reviewers can mark issues directly on the page with the URL, screenshot, and context captured automatically.

Jira-style ticketing is better for managing the broader migration workload, including owners, timelines, dependencies, and stages, but it’s slower for reporting page-level bugs. A practical setup is to capture QA issues in Marker.io, then sync the important ones into Jira for prioritization and delivery.

What are the best tools for WordPress migrations?

When you’re comparing WordPress migration tools, look for full-site backups of both your files and database, automatic URL and serialized-data rewriting, support for large sites or multisite, and a dependable restore workflow with strong docs/support – plugins like Duplicator, All-in-One WP Migration, WP Migrate, and Migrate Guru are common picks.

After the move, use Marker.io to run post-migration QA so that stakeholders can click any page and submit annotated bug reports that help you spot theme/plugin regressions fast.