Multilingual WooCommerce Migration: Timeline and Costs
A multilingual WooCommerce migration is not one import followed by a language switcher check. It is a coordinated move of products, translation relationships, taxonomies, customer-facing URLs, integrations, and live order data. The import may finish in hours; proving that the new store is complete can take weeks.
For planning purposes: a clean small store may move in one to two weeks, a mid-size catalogue in roughly three to five weeks, and a large or inconsistent store may need six weeks or more. Those are elapsed-time ranges from project work, not fixed quotes. The real schedule depends on data quality, the number of languages, the migration method, and how much can be tested before the final cutover.
| Phase | Typical elapsed time | Evidence produced |
|---|---|---|
| Discovery and mapping | 2–5 working days | Inventory, exception list, URL map, migration plan |
| Staging and dry run | 3–7 working days | Representative test import, timings, corrected mappings |
| Full migration and QA | 3–10 working days | Reconciled counts, language-by-language acceptance results |
| Cutover and observation | One quiet window, then 1–2 weeks of monitoring | Final delta, redirects, smoke tests, rollback record |
First decide what kind of migration this is
“Move the store” can describe three very different jobs. Choosing the wrong method creates work that did not need to exist.
| Situation | Usually the safest method | Main risk |
|---|---|---|
| Same WordPress store, new server or domain | Clone the files and database, then update environment-specific URLs and configuration | Carrying old technical debt into the new environment |
| New build, cleaner catalogue, or changed language structure | Export, transform, and import into a controlled data model | Breaking product identity or translation relationships |
| Merging stores or changing platforms | Staged extract, transform, and load (ETL) process with explicit source-to-target mapping | Conflicting identifiers, taxonomies, customers, and order history |
If the existing WordPress database is healthy and the store structure is staying the same, copying the database preserves product IDs and WPML relationships more reliably than rebuilding them. An import becomes the better choice when the target structure changes, the source data needs cleaning, or the new store should not inherit years of accumulated configuration.
This article concentrates on the harder second case: a multilingual WooCommerce catalogue moving into a new or substantially rebuilt installation.
Phase 0: audit the store before estimating it
A responsible estimate begins with counts and exceptions, not the number of rows in one CSV. The audit should answer:
- How many products, variations, categories, attributes, images, customers, and orders exist?
- Which language is the source language, and which languages are complete or partial?
- Are translated products and taxonomy terms linked correctly in WPML?
- Are SKUs or another business identifier present, stable, and unique?
- Which fields are shared across languages, and which are translated?
- Which URLs already receive organic traffic or external links?
- Which systems write to the store: ERP, PIM, feeds, subscriptions, payment gateways, shipping, CRM, or custom APIs?
The deliverable is a written exception list. Duplicate SKUs, orphaned translations, missing category parents, inconsistent attribute slugs, and mixed encodings are not small cleanup tasks to discover during the final import. They are scope.
On one catalogue I worked on, roughly 8,500 products and more than 1,000 categories arrived across four languages. Moving the rows was not the hard part. Reconstructing reliable translation groups and category hierarchies was. I wrote the technical data-model story separately for Business Bloomer; the project lesson relevant here is simpler: catalogue size multiplies inconsistencies that are almost invisible in a 50-row test.
Phase 1: define the data contract on staging
The migration file needs an explicit contract: which field identifies a product, which language owns each translated value, how parent-child relationships are represented, and what happens when a source row has no match.
Database IDs are useful when cloning the same installation, but they are not portable business identifiers for a rebuild. For an import, use a stable SKU or an external source key. Titles and translated slugs are content, so they should not also be trusted as identity.
The dry run should include more than the easiest products. A useful sample contains:
- a simple product with complete translations;
- a variable product with translated attribute terms;
- a product with images and formatted long descriptions;
- a category several levels deep;
- a product missing one optional translation;
- a URL that must redirect after launch; and
- a product touched by an ERP, feed, or other integration.
Record the expected result before running the sample. A progress bar at 100% only proves that the importer stopped without reporting an error. It does not prove that the correct records were created, linked, or updated.
For matrix-style multilingual imports, I use a tool I built specifically to solve this problem: Shirely, a WooCommerce and WPML import/export plugin. That disclosure matters, but the method matters more than the brand: every language variant must remain tied to one stable product identity, and the shared catalogue structure must be applied consistently.
Phase 2: migrate, reconcile, then inspect
Run the full migration on staging and reconcile it numerically before clicking through pages. At minimum, compare source and target counts for products, variations, categories, attributes, translations per language, images, customers, and orders that are in scope.
Counts catch omissions; they do not catch incorrect relationships. The acceptance sample must therefore cover each product type and every language:
- the language switcher reaches the corresponding translated product;
- categories and breadcrumbs remain in the current language;
- variation labels and attribute terms are translated and selectable;
- prices, taxes, stock, currency behavior, and shipping remain correct;
- cart, checkout, payment, emails, and account pages use the expected language;
- search, filters, feeds, and API integrations return the correct products; and
- canonical and hreflang annotations point to the new final URLs.
WPML stores translated products as separate records connected through its language data, so visual similarity is not proof of a valid relationship. Its own developer documentation explains why those links and language assignments matter to queries and templates.
SEO migration is a URL mapping exercise
Before cutover, export every indexable URL from the old store for every language. Map each old product, category, landing page, and important attachment URL to its closest new equivalent in the same language.
Then verify:
- server-side permanent redirects go directly to the final destination, without chains;
- internal links use the new URLs rather than relying on redirects;
- canonicals are self-referencing on the new site;
- hreflang annotations contain the new language URLs;
- XML sitemaps contain only final, indexable URLs; and
- both the old and new properties are available in Google Search Console.
Google’s site-move guidance recommends preparing a URL map, using permanent server-side redirects, updating canonicals and hreflang, and retaining redirects for at least a year. On a multilingual store, that work is multiplied by languages, not just by products.
How migration cost is actually calculated
A migration quote is mostly an estimate of uncertainty and verification work. The useful model is:
audit + cleanup + migration build + QA × languages + redirect mapping + cutover + monitoring
| Cost driver | Lower effort | Higher effort |
|---|---|---|
| Source data | Unique keys, consistent encodings, complete translations | Duplicates, missing keys, orphaned or partial translations |
| Catalogue shape | Mostly simple products | Variable, bundled, subscription, or heavily customized products |
| Languages | Two complete languages | Several languages with different levels of completeness |
| URLs | Structure stays the same | Domain, slugs, languages, and category paths all change |
| Integrations | No external writers | ERP, feeds, subscriptions, custom checkout, or live synchronization |
| Cutover | Content can pause briefly | Orders and stock must remain live with a very small freeze window |
This is why product count alone is a poor pricing unit. Five thousand clean products cloned with their database may be easier than 500 products rebuilt from inconsistent language files. A useful proposal names the assumptions, the acceptance checks, and what happens when the audit disproves an assumption.
Cutover: the shortest phase with the highest stakes
The launch window should follow a written runbook:
- Pause catalogue edits and record the exact start time of the content freeze.
- Take a fresh off-server backup and confirm the rollback path.
- Run the final delta for products, customers, orders, stock, and any other changing data in scope.
- Enable redirects and switch traffic in the store’s quietest window.
- Test one real transaction, the language switcher, search, forms, emails, feeds, and scheduled jobs.
- Compare the final counts and monitor application, payment, and server logs.
Define rollback conditions before launch. Examples include checkout failure, missing recent orders, widespread redirect errors, or an unexplained mismatch in translated product counts. “We will decide if it looks bad” is not a rollback plan.
Keep the old store available but read-only until the new installation has passed the observation period. It is both a recovery point and the reference used to resolve disputed content after launch.
What the handover should contain
A completed migration is not just a working storefront. The handover should include:
- Audited source inventory: counts and the exception list;
- Migration inputs: the transformation or import files actually used;
- Mapping rules: the product identifier and language-field decisions;
- SEO migration assets: the old-to-new URL map and redirect configuration;
- Acceptance evidence: the completed checklist with results per language;
- Cutover record: final counts, timestamps, and unresolved exceptions; and
- Recovery information: the backup and rollback locations.
Without those artifacts, the next update, feed change, or catalogue refresh starts the investigation again from zero.
When DIY is reasonable
DIY is reasonable when the catalogue is small, identifiers are clean, the language structure is already correct, URLs are not changing significantly, and somebody on the team can build and restore staging. Run the complete workflow on a representative sample before committing to the full move.
Bring in specialist help when the store has thousands of products, live integrations, existing WPML relationships that must survive, a domain or URL change, incomplete translations, or a deadline tied to a campaign or season. Those are not signs that the migration is impossible. They are signs that the audit and rollback plan are part of the migration, not optional extras.
Need this migration handled end to end? Hire me to audit the catalogue, build and test the migration, run the cutover, and verify every language after launch. Send the store URL, language count, approximate product count, and what is changing to get a scoped proposal.