WooCommerce Migration Checklist: 5 Critical Phases

A complete WooCommerce migration checklist covering every critical phase — before, during, and after — so you don't lose data, sales, or rankings.

Why an Unprepared WooCommerce Migration Costs You

A safe WooCommerce migration checklist isn’t a luxury — it’s the difference between a smooth launch and a week of damage control. Without a structured process, the most common outcomes are: duplicated or lost orders, broken redirects that destroy months of SEO work, payment gateways that silently stop processing, and customers who can’t complete a purchase for hours. According to e-commerce industry analyses, every hour of downtime for an online store can translate to losing between 2% and 5% of daily revenue, depending on traffic volume.

This guide is written for developers and project leads who already manage WooCommerce stores and need a real technical roadmap — not a generic “make a backup and good luck” list. It covers the three critical phases: pre-migration, execution, and post-migration.

Phase 1: Pre-Migration — Before You Touch Anything

The majority of problems in a WooCommerce store migration originate here, not during the actual transfer. This phase can account for 40–60% of the total project time, and for good reason.

Audit Your Current Environment

Before migrating, you need to know exactly what you’re working with. This includes:

• Active PHP version on the source server. WooCommerce 8.x requires PHP 7.4 as a minimum, but running PHP 8.1 or higher is strongly recommended to avoid compatibility issues on the new environment.
• Active plugin inventory with exact version numbers. Listing them isn’t enough — you need to document which plugins have custom configurations stored in the database (wp_options entries, custom tables).
• Theme customizations: functions added to functions.php, overridden WooCommerce hooks, templates copied into the child theme.
• Active integrations: payment gateways (Stripe, Redsys, PayPal), connected ERPs, email marketing systems, analytics tools.
• Actual database size and the wp-content/uploads folder size. A mid-sized store can easily have 5–15 GB of product images.

Benchmark Key Metrics Before Moving Anything

Most teams skip this step entirely and then can’t prove whether the migration hurt performance. Before you start, record in writing:

• Page load times for the main pages (home, category, product, cart, checkout), measured with PageSpeed Insights or GTmetrix.
• Rankings for the 10–20 most business-critical keywords.
• Average conversion rate over the past 30 days from Google Analytics or WooCommerce reports.
• Total counts of orders, products, categories, and registered customers in the database.

These numbers are your baseline for validating that everything went well after the migration.

Complete and Verified Backup

A backup is non-negotiable — but “making one” isn’t enough. There are three requirements it must meet to actually be useful:

1. Complete: database + all WordPress files (including wp-config.php and the uploads directory).
2. Stored externally — off the current server. A backup that lives on the same server as your store is useless if that server fails.
3. Verified: open the SQL file and confirm it isn’t truncated. Check that the file archive includes the complete wp-content folder.

Tools like Duplicator Pro, All-in-One WP Migration, or UpdraftPlus can automate this with exports to Google Drive, Dropbox, or Amazon S3.

Preparing the Destination Environment

The server you’re migrating to must be fully configured before the transfer begins:

• PHP set to the correct version (8.1+ recommended for current WooCommerce).
• PHP memory limits properly set: 256 MB minimum, 512 MB recommended for stores with large catalogs.
• Required PHP extensions enabled: MySQLi, cURL, GD or Imagick, mbstring, OpenSSL.
• SSL certificate installed and configured on the destination domain.
• A staging subdomain (e.g., staging.yourdomain.com) set up for testing before pointing the live DNS.

Phase 2: Executing the Migration

With the environment audited, the backup verified, and the destination server ready, the actual transfer should be the least dramatic part of the whole process.

Transferring Files and the Database

There are two main approaches. The first is plugin-based (Duplicator, All-in-One WP Migration, Migrate Guru): faster for mid-sized stores, but can hit limitations with large databases (+500 MB). The second is a manual transfer via FTP/SFTP + phpMyAdmin or the command line using wp-cli: more control, more reliable for stores with complex structures or high data volumes.

With wp-cli, the database export and import process comes down to two commands:

wp db export backup.sql
wp db import backup.sql

After importing, you need to update the URLs in the database to reflect the new domain or staging subdomain. wp-cli handles this directly:

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

The --skip-columns=guid flag is important: it prevents the post GUIDs from being overwritten — the values WordPress uses internally to identify content items.

Verifying Critical WooCommerce Data

Once the database has been imported into the staging environment, before running any visual checks, verify the following in the admin panel:

• Total order count (must match the source).
• Number of published products, drafts, and variations.
• Registered customers and their address data.
• Shipping zone configuration and active methods.
• Credentials and mode (test/live) for payment gateways — these are not migrated automatically and must be reconfigured manually.

Functional Testing Before Going Live

This is the stage where many “apparently successful” migrations reveal their hidden problems. The minimum functional checklist includes:

• Place a complete test order: add to cart, apply a coupon, checkout with a card in test mode, verify the confirmation email.
• Confirm that transactional emails (order confirmation, status changes) are being delivered correctly.
• Check that product images are displaying (a common issue when the uploads path doesn’t match).
• Review the My Account page for existing customers.
• Test the internal search if the store uses it actively.
• Verify contact forms and any third-party integrations (CRM, email marketing).

Phase 3: Post-Migration — The Work Doesn’t End at Launch

Pointing the DNS to the new server is only the start of the final phase. What happens in the first 48–72 hours determines whether the project was a success or a firefight.

DNS Management and Propagation Time

When you update your DNS records to point to the new server, propagation can take anywhere from 1 to 48 hours depending on the provider and configured TTL values. During that window, some traffic is still hitting the old server. The recommended approach is to keep the old server active and fully functional for at least 48 hours after the DNS change. If you’re using Cloudflare, you have much tighter TTL control and can reduce that window to 5 minutes with the right pre-configuration.

Post-Migration SEO Verification

WooCommerce migrations are one of the highest-risk events for organic search rankings. The minimum SEO checklist after going live includes:

• Crawl for broken URLs: use Screaming Frog or Google Search Console to identify any new 404 errors.
• 301 redirects: if any URL changed structure during the migration, each one needs a permanent redirect to the new URL.
• XML sitemap: verify the sitemap is accessible and that you’ve submitted it in Google Search Console.
• Robots.txt: confirm you’re not blocking crawling of product or category pages (the most common mistake when migrating from a staging environment where that file was set to disallow indexing).
• Canonical tags: make sure canonical URLs point to the correct domain, not the staging subdomain.

Monitoring During the First 7 Days

A successful migration isn’t declared on launch day — it’s declared a week later. The minimum you should be actively monitoring:

• Daily conversion rate vs. the baseline recorded before migrating.
• Uptime alerts using tools like UptimeRobot or Better Uptime.
• PHP error log on the new server.
• Daily review of the WooCommerce log (System → Status → Logs) to catch gateway or integration failures.
• Keyword ranking comparison against pre-migration data.

Common Mistakes This WooCommerce Migration Checklist Helps You Avoid

After working on migrations of varying scale, these are the errors that come up most often when there’s no structured process in place:

1. Migrating without a staging environment: going live directly on the real domain without testing in an intermediate environment is the riskiest mistake you can make. Any problem shows up in front of real customers.
2. Not updating payment gateway credentials: Stripe or Redsys API keys don’t transfer automatically. If live mode isn’t manually reconfigured, charges fail silently.
3. Ignoring the cache: after migrating, the server cache (Redis, Memcached, WP Super Cache, LiteSpeed) may serve stale pages with incorrect URLs. Flushing all caches is one of the very first post-launch steps.
4. Not verifying transactional emails: many new hosting environments require configuring an external SMTP server (SendGrid, Brevo, Amazon SES) for WooCommerce emails to reach the inbox. Without this setup, customers never receive order confirmations.
5. Assuming plugins will behave the same on the new server: differences in PHP versions, active extensions, or WordPress configuration can break plugins that worked perfectly on the source server.

Frequently Asked Questions About WooCommerce Migration

How much downtime is normal during a WooCommerce migration?

With proper planning and a staging environment, real downtime should be virtually zero. The full process runs on staging, and the DNS switch happens only after everything has been verified. The only critical window is DNS propagation time — during which the old server stays active and continues accepting orders.

Should I clean the database before migrating?

Yes — it’s not strictly required, but doing so reduces the export size and speeds up the process. Post revision tables, abandoned order drafts, and logs that have accumulated over years can account for 20–40% of the total database weight on older stores. Plugins like WP-Optimize let you safely clean this up before exporting. For a deeper understanding of how WordPress organizes this data, it helps to understand relational database structure.

What happens to product images during the migration?

Images are part of the WordPress file system (the wp-content/uploads folder) and must be copied in full to the destination server. The common issue isn’t losing them — it’s that WordPress-generated thumbnails don’t regenerate automatically if the new server has a different Imagick or GD configuration. The “Regenerate Thumbnails” plugin handles this in a single pass after the migration.

How does migration affect SEO if the domain doesn’t change?

If the domain stays the same and the URL structure remains intact, the SEO impact should be minimal. Risks appear when URLs change structure, when the staging environment’s robots.txt isn’t updated before going live, or when the new server’s performance is significantly worse than the old one. Monitoring keyword positions for the 14 days following launch is sufficient to catch any anomalous movement.

If you manage complex WooCommerce projects and need specialized technical support for this kind of process, you can review how I work on the services page.

// About the author

fernandodomecq

Freelance WordPress developer specializing in WooCommerce, integrations and AI. I write about web projects, agencies and technical best practices.

View all articles →