WooCommerce Migration Checklist: Data, Checkout and Cutover
A WooCommerce migration is ready when the catalog, customer journeys and new orders survive the move. Use this checklist to plan the transfer, rehearse it and protect trading activity at cutover.
Read the guide
Search Field Notes
A useful next read.
36 field notes
No matching guide yet. Try “checkout”, “shipping” or “catalog”.
All Field NotesInventory more than the product catalog
List products, variations, images, customers, order history, content and subscriptions. Then list the rules that make the store work: delivery charges, discounts, tax settings, account access and warehouse handover. Data and behaviour are separate parts of the move.
For each item, mark what will transfer, what will be rebuilt and what can stay archived. Identify the source tool and the person who can export it. App-specific records often need their own route. Discovering those gaps before development is much cheaper than finding them during launch week.
Match the transfer tool to the data
The built-in WooCommerce CSV importer handles product data; it does not recreate customer accounts, historical orders or subscription billing. Check the chosen migration tool’s coverage for every entity in your inventory. A product count says little about whether the store’s relationships survived.
Keep original exports intact and work from preparation copies. Customer and order files belong in private storage with limited access. For existing subscriptions, establish the supported payment-reference and gateway route before promising continuity. A recurring product imported into the catalog is not the customer’s active billing agreement.
The order of a store move
Rehearse the transfer and checkout before choosing the cutover window.
Inventory
List data to transfer and store rules to rebuild.
Confirm tools and owners.Rehearsal
Import representative products and complete the buying journey.
Fix mapping and checkout gaps.Cutover
Capture later source activity and protect new destination orders.
Follow the agreed switch plan.Live checks
Verify products, payment, URLs and staff handover.
Keep the source until checks pass.
Rehearse with products that expose problems
Choose a simple product, a variable product with several options, an unavailable item and any unusual product type. Compare SKUs, parent-child links, prices, images and attributes after transfer. Then select the options on the storefront and add the intended item to the cart.
If customers or orders are included, check representative account and order relationships as well as record totals. A technically successful import can still attach an image to the wrong product or leave a variation without a usable price. Fix the preparation rules before the full transfer.
Rebuild the buying journey and URL map
The destination needs its own payment, shipping, mail and integration configuration. Test the destinations and gateways you actually offer, including guest and returning buyers. Follow a test order into the staff workflow so fulfilment does not stop at the new site’s edge.
Keep useful product and category URLs where possible. Map changed addresses to their relevant replacement and update internal links and the sitemap. A renamed category needs a deliberate route; redirecting every missing address to the homepage will not preserve the customer’s reason for following the old link.
Protect orders arriving during the move
Agree a cutover window, final transfer and owner for each step. The source can receive new orders and stock changes after the rehearsal. Those changes need a final sync or another explicit preservation process before traffic moves.
Create and verify source and destination backups before the approved cutover. Define the point at which the old store stops accepting orders, how new destination orders are protected and when a rollback is still practical. Restoring yesterday’s database after taking today’s payments can create a second incident.
Check the live store before closing the source
After switching traffic, check the catalog, changed URLs, cart, account access, agreed payment path and order handover. Compare the final counts with the transfer log and inspect the exceptions. Keep the old platform and image assets available until the move has passed these checks.
Hand staff the new access details, responsibility list and unresolved items through private channels. Monitor missing pages, failed payments, delivery mismatches and sync failures during the initial trading period. Close the source only when the team no longer needs it for data, assets or recovery.
Common questions
Can we migrate a whole store with a product CSV?
No. Product CSV covers the catalog fields the importer supports. Accounts, orders, subscriptions and app-specific data need separately checked transfer methods.
Which products should a migration test include?
Include the product types and states most likely to break: variations, images, unavailable items and any subscription, bundle or custom type. Test them through selection and cart.
Should the old store keep taking orders during migration?
It can during preparation, provided the cutover plan captures later activity. At the final switch, define exactly when the source stops accepting orders and where every subsequent order belongs.
When can we cancel the old platform or hosting?
After the final transfer and live checks pass, and after confirming that no image, data, subscription or recovery step still depends on the source.
Can we keep the existing product URLs?
Keep them when they fit the new structure. For changed routes, map the old address to the corresponding final page and update internal links and the sitemap.