3 min read
Categories Guides

How to Migrate a Multilingual WooCommerce Store to a New Server

A server migration and a catalog migration solve different problems.

A full WordPress move should preserve the database, uploads, plugins, themes, configuration, users, orders, URLs, and WPML relationships together. Shirely is useful when you deliberately want a structured CSV or Google Sheets round trip for supported catalog or store-data objects. It is not a replacement for a complete site backup and migration process.

Choose the migration type first

Use a full-site migration when the destination should be the same store on new infrastructure. That normally keeps the WordPress database and uploads together, preserving local IDs and plugin state.

Use a structured Shirely round trip when you are rebuilding or selectively moving data into a different WooCommerce installation and want to review the rows first. Shirely has dedicated workflows for products, categories, posts/pages, orders, customers, coupons, and reviews within their supported contracts.

Do not mix the two casually. Importing catalog rows on top of a full database clone can create unnecessary duplicate work.

Inventory everything outside the catalog

A multilingual WooCommerce site also depends on:

  • WordPress and WooCommerce configuration;
  • WPML/WCML settings and translation tables;
  • users and permissions;
  • orders, refunds, customers, and emails;
  • theme and child-theme files;
  • plugin licenses and settings;
  • uploads and generated media sizes;
  • cron jobs and background queues;
  • redirects, canonicals, and sitemap configuration;
  • DNS, TLS, caching, and mail delivery.

Shirely can move supported data sets, but it does not clone this complete operational environment.

Preserve identity according to the path

For a full database migration, local IDs and WPML relationship data travel as part of the database.

For a structured cross-store catalog move, do not assume those local IDs remain meaningful. Use SKU as the normal portable product key or Matrix ID / External ID for a multilingual Matrix workflow. Use category source_id and parent_source_id for hierarchy.

Shirely 1.3 catalog provenance helps avoid blindly treating foreign IDs as local records, but stable natural keys and staging QA remain necessary.

Test the destination before cutover

Build a staging copy on the new server and verify:

  • WordPress, PHP, WooCommerce, and WPML compatibility;
  • permalinks and multilingual URL structure;
  • products, categories, variations, and attributes;
  • Media Library and image delivery;
  • users, customer profiles, orders, and refunds;
  • scheduled actions, WP-Cron, and system cron;
  • checkout, payment, email, and webhooks;
  • SEO output and redirects;
  • desktop and mobile behavior.

Use the same domains or controlled host mapping only where the migration plan permits it. Keep staging blocked from accidental indexing.

If you use Shirely for selective data

A typical structured sequence is:

  1. Prepare translated category hierarchy.
  2. Import a representative product sample.
  3. Verify products, variations, attributes, images, and language switching.
  4. Import the wider catalog.
  5. Import customers and then orders when the migration requires them.
  6. Handle coupons and reviews through their dedicated workflows.

Keep origin_ref fields supplied by Shirely exports. They help the destination distinguish provenance from an accidental local-ID collision.

Plan a quiet final window

Between the last copied database state and DNS cutover, new orders, accounts, stock updates, and content changes can create divergence. Define a maintenance or synchronization window and who owns the final comparison.

Do not overlap Shirely jobs that can modify the same products, terms, or WPML/WCML groups. If Automation or WP-CLI is part of the plan, inspect Run History and cron state before launch.

Keep rollback concrete

A rollback plan should name the database backup, uploads snapshot, DNS or proxy action, responsible person, and trigger for returning to the old server. Test access to the backup rather than assuming its filename proves it can be restored.

After cutover, monitor errors, checkout, mail, cron, search indexing signals, and representative multilingual pages. Retain the old environment only for the approved rollback period and protect its customer data.

For a selective catalog move, see the WooCommerce import/export workflow and migrating orders. The documentation defines Shirely's supported boundaries.