Why Migration Decisions Go Wrong Before Any Code Runs

WordPress migration criteria are rarely discussed in technical terms until something breaks. Most agencies and development teams treat migration as a deployment task — copy files, export the database, update the domain, done. But the projects that end in client calls at 2 a.m. almost always started with a planning gap, not a technical one. The decision about how to migrate a site is just as consequential as the migration itself.

This guide is for anyone evaluating a WordPress migration: whether you’re moving a client’s site from a legacy host, consolidating multiple WordPress installs, rebuilding an old theme into a block-based architecture, or transitioning a WooCommerce store to a new infrastructure. The criteria below apply across scenarios. What changes is the weight you assign to each factor based on your context.

First: Define What You Are Actually Migrating

The word «migration» covers very different operations in WordPress. Conflating them leads to scope creep and underestimated timelines. Before applying any evaluation criteria, clarify which of these you’re dealing with:

• Host-to-host migration — Moving the same codebase and database to new server infrastructure. The site is functionally identical after the move.
• Domain migration — Changing the site’s URL, which triggers a database search-and-replace across serialized data and risks breaking internal links, images, and plugin settings.
• Platform migration — Moving content from a different CMS (Squarespace, Drupal, Joomla) into WordPress. Requires content transformation, not just data transport.
• Theme or builder migration — Rebuilding page layouts from one theme framework (Divi, Elementor, Avada) to another while preserving content. Often the messiest category because visual structure is tightly coupled to the old builder’s shortcodes.
• Version or architecture upgrade — Moving a heavily customized older WordPress install to a modern setup. Often involves PHP version conflicts, deprecated functions, and plugin incompatibilities.

Each type carries different risks, requires different tooling, and has a different definition of «done.» Get this classification right before evaluating anything else.

Core Criteria for Evaluating a WordPress Migration

1. Data Volume and Complexity

The size of a WordPress database is rarely the issue — even a 500MB database transfers quickly. What matters is the structure of the data. Heavily customized post types, complex ACF field groups, serialized options in wp_options, and large amounts of taxonomy relationships all increase migration risk. Before choosing a migration method, audit the database structure, not just the file size.

WooCommerce stores add another layer: order history, customer records, product meta, and payment gateway transaction logs all need to transfer intact. A site processing thousands of orders per month has data integrity requirements that a brochure site simply doesn’t.

2. Acceptable Downtime Window

Downtime tolerance varies dramatically by client type. A portfolio site for a freelance designer can go offline for an hour with minimal consequence. A WooCommerce store running flash sales cannot. An agency site with active client portals falls somewhere in between.

Your downtime window determines your migration method. If downtime must be under 15 minutes, you’ll need a staged migration with a cutover — running the new environment in parallel and switching DNS only once the new site is confirmed functional. If you have a four-hour maintenance window at 3 a.m., a direct file transfer and database import is simpler and lower risk.

According to downtime research in web infrastructure, even brief outages during peak traffic windows can measurably impact revenue and search rankings. Build your downtime estimate conservatively.

3. SEO Continuity Risk

Domain migrations and URL structure changes are the highest-risk migrations from an SEO standpoint. Changing URLs without implementing proper 301 redirects can wipe out years of accumulated link equity. Even host-to-host migrations carry risk if the server configuration changes how WordPress handles permalinks or canonical tags.

Before any migration, export a full crawl of the existing site using a tool like Screaming Frog. Document every indexable URL, every canonical tag, and every internal link. This becomes your post-migration validation checklist. If the new site doesn’t return the same set of URLs (or properly redirects them), you have an SEO problem.

For sites with significant organic traffic — say, more than 10,000 monthly sessions — treat SEO continuity as a first-class migration criterion, not an afterthought.

4. Third-Party Integrations and Dependencies

Modern WordPress sites rarely live in isolation. They pull in CRM data via API, push orders to fulfillment systems, authenticate users through SSO providers, or sync inventory with external platforms. Every integration is a migration dependency.

Map every external connection before you start. Ask: does this integration use a hardcoded domain URL in its configuration? Does it authenticate using a key stored in the database or in a config file? Will the new environment’s IP address need to be whitelisted anywhere?

Plugin license keys are also a common migration blocker. Many plugins are tied to a domain and require deactivation on the old site before activation on the new one. Missing this step means launching with broken premium features and a licensing conflict to resolve at the worst possible moment.

5. PHP and Plugin Compatibility on the Target Environment

If the migration involves a change in server environment — a common scenario when moving from a low-cost shared host to managed WordPress hosting — PHP version compatibility becomes critical. A site running PHP 7.4 on the old host may break on a server running PHP 8.2 if plugins haven’t been updated to handle the deprecations introduced between those versions.

Run a compatibility audit before migration. The PHP language releases detailed migration guides for each major version change. Tools like the PHP Compatibility Checker plugin can surface conflicts in the existing codebase before you move anything.

The same applies to WordPress core version mismatches. If the source site is running WordPress 5.9 and the target environment defaults to 6.5, plugins with tight version dependencies may behave differently.

Choosing Between Migration Methods

Manual Migration vs. Plugin-Based Migration

Plugin-based migration tools like Duplicator, All-in-One WP Migration, or WP Migrate DB Pro are legitimate options for most standard migrations. They abstract the technical steps and reduce the chance of a missed configuration detail. For host-to-host migrations on sites under 1GB, they’re often the fastest path.

Manual migration — SSH access, mysqldump, rsync, and a search-and-replace script — gives you more control and is more appropriate for large sites, complex database structures, or situations where you need to exclude specific data (like staging content that shouldn’t go to production).

The choice isn’t about technical sophistication. It’s about which method gives you better visibility into what’s happening at each step. A black-box plugin that «just works» until it doesn’t can be harder to debug than a transparent manual process.

Staged Migration vs. Direct Cutover

A staged migration runs the new environment in parallel with the old one. You test everything on the new server using a temporary domain or hosts file override, confirm that the site works correctly, then switch DNS when you’re confident. This approach minimizes user-facing risk but requires that you account for any content or orders created on the old site during the staging period.

A direct cutover is faster and simpler for sites with low traffic or a clean maintenance window. You take the old site offline, transfer everything, bring the new site up, and update DNS. The risk is that problems discovered after cutover have immediate user impact.

For high-traffic or revenue-generating sites, the staged approach is almost always worth the extra effort.

Validation: What to Check Before You Call a Migration Complete

A migration isn’t done when the site loads on the new server. It’s done when you’ve confirmed that everything that was working before is still working — and that nothing new has broken.

Functional Validation Checklist

• All pages and posts load without 404 errors
• Images display correctly (check srcset and uploads path)
• Forms submit successfully and notifications send
• WooCommerce checkout completes a test transaction
• User accounts can log in and access their data
• Email sending works from the new server (check SMTP configuration)
• SSL certificate is valid and HTTPS enforces correctly
• Caching is configured on the new server (not just carried over from the old one)
• All 301 redirects are in place and returning the correct status codes
• Google Search Console and Analytics tracking codes are firing

Performance Validation

A migration to a new host is often an opportunity to improve performance — but only if you measure it. Run a Lighthouse or GTmetrix test on the old site before migration and compare it to the new one after. If Time to First Byte (TTFB) has gone up, something in the new server configuration needs attention. Don’t assume a new environment is automatically better.

According to web performance research, a 100ms increase in TTFB can measurably reduce conversion rates on e-commerce sites. Migration is not the time to accept a performance regression without investigation.

Common Migration Mistakes That Create Long-Term Problems

Migrating Without a Rollback Plan

Every migration needs a defined rollback procedure. If the cutover fails — database corruption, a licensing conflict that breaks a critical plugin, an SSL issue that prevents login — you need to be able to restore the old environment within minutes. Keep the old server active and don’t cancel hosting until the new site has been running cleanly for at least two weeks.

Ignoring the wp-config.php Differences

The wp-config.php file contains environment-specific settings: database credentials, debug flags, salts, and custom constants. Copying it directly from the old server to the new one is a common mistake. You’ll either end up pointing the new WordPress install at the old database (if credentials are different) or carrying over debug settings that expose errors to public users.

Assuming Search-and-Replace Gets Everything

A database search-and-replace for the old domain URL is necessary — but not sufficient. Serialized data in WordPress stores string lengths alongside the content. If your search-and-replace tool doesn’t account for serialization, it can corrupt option values and widget configurations that silently break frontend elements. Use a tool built for WordPress serialized data, not a generic SQL find-and-replace.

Not Documenting What Changed

After a migration, write down what was different between the old and new environment. PHP version, server software (Apache vs. Nginx), caching layer, CDN configuration, plugin updates applied during the process. This documentation is invaluable if a problem surfaces two weeks later and you need to trace it back to a configuration change.

When to Bring in External Development Support

Not every migration warrants bringing in a specialist. A basic host-to-host migration for a simple brochure site is well within the scope of any competent WordPress developer. But several scenarios genuinely warrant more experienced hands:

• WooCommerce stores with thousands of orders and complex inventory integrations
• Migrations involving a URL structure change for high-traffic sites where SEO risk is significant
• Legacy sites running custom plugins or themes built against old WordPress APIs that may break on current versions
• Multisite networks being split into standalone installs (or the reverse)
• Migrations that must happen during a narrow maintenance window with no margin for error

If your migration falls into any of these categories and you’re evaluating whether to handle it in-house or bring in a technical partner, the conversation is worth having early — before the migration plan is locked in, not after a cutover goes sideways.

Putting the Criteria Together: A Decision Framework

Before finalizing your migration approach, score each of these factors on a simple low/medium/high scale for the specific project:

• Data complexity — How structured and interdependent is the database content?
• Downtime tolerance — What is the maximum acceptable outage duration?
• SEO risk — Does the migration change URLs or canonical structure?
• Integration dependencies — How many external systems connect to the site?
• Environment delta — How different is the target server from the current one?
• Rollback complexity — How hard would it be to reverse the migration if needed?

A site that scores «low» across all six factors can be migrated with a standard plugin-based approach and a straightforward cutover. A site with multiple «high» scores needs a staged migration, a detailed validation checklist, and possibly dedicated staging infrastructure. The scoring forces the conversation about risk before the project starts — which is exactly when it should happen.

WordPress migrations are one of those technical tasks where the planning work is far more valuable than the execution skill. The files transfer in minutes. The thinking about what could break, and what you’ll do if it does, is what separates clean migrations from fire drills.