A commerce migration looks like a data project until you list everything the existing store carries: product relationships, customer history, search visibility, operational habits, integrations and performance expectations. The real task is continuity. The new system has to become better without making the business pay for the transition in missing data, broken URLs or an unreliable launch.
Treat migration as business continuity
Moving records from one database to another is only one part of the work. A product URL may carry years of search authority. A custom field may drive merchandising even if its name is unclear. A customer attribute may be required by support, fulfillment or accounting. Deleting any of them can create a problem far from the migration script.
On the Danielgerard.fr migration from PrestaShop to WooCommerce, the important question was not whether products could be imported. It was whether the catalogue could arrive with its meaning intact and whether customers, search engines and operators could continue from there.
That framing changes the definition of done. Every critical relationship, route and workflow needs an explicit destination or an explicit decision to retire it.
Inventory before you map
Legacy systems contain more truth than their official schema suggests. Plugins add fields, operators develop conventions and old integrations leave values that may still matter. Starting with the destination model encourages the team to force unfamiliar data into familiar shapes before understanding it.
The safer approach is an audit. Catalogue entity types, field populations, relationships, media, identifiers and route patterns. Compare documentation with actual records. Identify fields that are empty, overloaded or encoded differently across time. Only then can the new model distinguish information that should be normalized from information that must remain historically accurate.
- Variants, categories, attributes, media and cross-sells.
- Customer records, addresses and consent-related fields.
- SEO titles, descriptions, canonical behavior and URL history.
- Operational metadata used by fulfillment, support and reporting.
Build a reproducible migration pipeline
A one-time script that succeeds on a developer’s machine is not enough. Migrations need dry runs, logs, deterministic mapping and the ability to resume or safely repeat a batch. The closer launch gets, the more valuable repeatability becomes because the source data continues to change.
I prefer separating extraction, normalization, mapping and destination writes. Each stage produces inspectable output. Stable source identifiers are preserved so rerunning a batch updates the intended record instead of creating duplicates. Failures are recorded with the source context required to diagnose and retry them.
Using the WooCommerce API as an explicit destination boundary also keeps the migration aligned with the platform’s model. Custom customer and SEO metadata can be registered and verified rather than inserted as unexplained database values.
- Use small batches with progress and failure reporting.
- Preserve source IDs for traceability and idempotency.
- Validate required relationships before writing a record.
- Produce reconciliation reports after every full run.
Preserve discovery and improve retrieval
A migrated product that returns a 404 at its old address has been lost from the perspective of a search engine and every external link. Redirects need to be generated from the actual route inventory, not guessed from a handful of examples. Rewritten URL rules should be tested for products, categories, pagination and known historical patterns.
Performance is another form of continuity. A catalogue can be complete and still create a worse business outcome if product pages become slow under real traffic. Object caching with Redis can remove repeated work from expensive catalogue queries, but it needs sensible invalidation and measurement. Caching an incorrect or stale result faster is not an improvement.
The target is not technical parity. It is a store that preserves discovery while giving customers and operators a better system after the cutover.
Reconcile before cutover, observe after it
Verification should compare systems, not rely on spot checks alone. Record counts are the beginning. Relationship counts, missing required fields, price and stock samples, media availability and redirect coverage provide stronger evidence. High-value and structurally unusual records deserve targeted review.
The cutover plan should define a content freeze or final delta import, backups, DNS and cache changes, acceptance checks and the conditions for rollback. Responsibilities need names, not assumptions. A calm launch is usually the result of decisions made before launch day.
After release, monitor application errors, redirect misses, slow queries, checkout behavior and operational feedback. The migration is complete when the new store is stable in production and the team can work without depending on the old system as a hidden source of truth.