A commerce migration is not a file import. It is a controlled change to the system that customers, staff, accounting, fulfillment, support, and search engines already depend on. Catalog data is visible, but the difficult work usually lives in relationships and operational rules.
A reliable plan defines what must move, what must change, what can be retired, and how the new platform will be proven before traffic is switched.
Begin with discovery, not export tools
Inventory the source platform as it actually operates. Do not assume the database schema tells the whole story. Staff may depend on custom reports, spreadsheet exports, manual status changes, saved payment references, shipping exceptions, or undocumented customer groups.
- Products, variations, attributes, bundles, and downloadable assets.
- Customers, roles, addresses, consent records, and account access.
- Orders, line items, refunds, notes, taxes, discounts, and fulfillment state.
- Categories, brands, media, editorial content, and structured metadata.
- Payments, shipping, tax, ERP, CRM, search, email, and accounting integrations.
- Public URLs, canonical rules, redirects, feeds, and externally linked resources.
Ask operational questions
What does support search for? Which order fields reach the warehouse? Which customer groups receive special payment or tax behaviour? Those answers define the real migration scope.
Create a data contract for every entity
A mapping document should describe the source field, destination field, transformation rule, default behaviour, ownership, and validation method. This turns assumptions into decisions that can be reviewed before code is written.
Preserve stable source identifiers in dedicated metadata when they may be useful for reconciliation. They allow the migration to identify an existing record during repeated test runs instead of creating duplicates. They also give support teams a bridge between historical references and the new platform.
Relationships matter more than totals
An order count can match while the migration is still wrong. Customer ownership, variation references, tax lines, refund relationships, downloadable permissions, order notes, and shipment metadata must point to the correct new records.
Treat URLs as migration data
Capture current product, category, content, and attachment URLs early. Decide whether each URL will remain, redirect to a specific destination, or be intentionally retired. Avoid sending every missing page to the homepage; that hides mapping errors and creates a poor experience.
- Preserve high-value product and category paths where practical.
- Create one-to-one permanent redirects for changed URLs.
- Carry titles, descriptions, canonical intent, and image alternatives into the new system.
- Update internal links in content rather than relying only on redirects.
- Prepare a report for source URLs with no approved destination.
Build repeatable dry runs
A migration script should be safe to run more than once against a clean target. Separate extraction, normalization, transformation, and loading so a problem in one stage does not require rewriting the whole pipeline.
Use representative fixtures early, then perform full-volume rehearsals. Small samples prove the mapping logic; full datasets reveal memory limits, timeouts, malformed legacy records, filename collisions, and performance problems.
The first successful import proves possibility. Repeated clean imports prove that the migration is ready for a cutover.
Validate workflows, not only records
Automated checks should compare totals, required fields, relationship integrity, financial sums, and samples from different time periods. Manual acceptance should then follow real business scenarios.
- A returning customer signs in and sees the correct history.
- A guest places an order using each supported payment path.
- Shipping and tax rules behave correctly for important regions and customer groups.
- Staff can search, edit, refund, print, export, and fulfill the order.
- Inventory and external systems receive the expected identifiers and status changes.
- Old public URLs reach the correct destinations.
Plan cutover and rollback together
Define the content freeze, final data delta, DNS or proxy change, cache warm-up, monitoring window, and the person responsible for each decision. Keep the old platform available in a read-only or recoverable state until the new system has passed the agreed verification period.
A rollback threshold should be concrete. Examples include payment failure, missing order relationships, incorrect pricing, broken authentication, or an integration backlog that cannot be recovered safely. The team should know how to reverse traffic before pressure makes the decision unclear.
The durable outcome
A successful WooCommerce migration does more than reproduce a catalog. It leaves the business with documented data ownership, predictable integrations, tested operational workflows, maintainable extensions, and a record of how historical information reached its new home.
FAQ
Common questions
Concise answers to questions readers often ask about this topic.
How can a WooCommerce migration preserve SEO history?
Map existing URLs, metadata, canonical intent, media, and redirects before launch. Validate the final sitemap and important landing pages after the production domain is switched.
How do you avoid losing new orders during migration?
Use rehearsal imports, define a short cutover window, and plan a final delta migration for orders, customers, and other records created after the initial export.
Should a commerce migration include a rollback plan?
Yes. Backups, validation thresholds, traffic-switch instructions, and responsibility for the rollback decision should be documented before the production cutover begins.
