Planning an online store migration

A store migration needs an agreed list of what is moving and a way to check the result. Product totals alone are insufficient: the right number of products can still contain missing variations, broken images or incorrect purchasing rules.

Start by recording the systems involved in an order. Include payment processing, shipping, inventory, accounting and any spreadsheets staff use to correct or supplement the website.

Map the catalog before importing it

Keep an untouched export of the original database and files. Use a separate copy to investigate duplicates, incomplete attributes and inconsistent categories.

Create a field mapping between the two stores. For each field, record the source, destination and transformation. For example, a supplier’s free-text colour might need to become a controlled attribute, while a product’s external reference must remain unchanged for inventory matching.

Check a sample containing:

• A simple product and a product with several variations.
• A sale price with a start or end date.
• An unavailable item and an item allowing backorders.
• A product with extra options or custom purchasing rules.
• An item with several images, attachments or downloadable files.

Agree which customer and historical order data must remain accessible. Account passwords, saved payment methods and third-party identifiers need their own assessment; they should not be assumed to transfer with a product export.

Prepare a URL map

Export existing product, category and important content URLs. Match each retained page to its destination before launch. Where the URL stays the same, preserve it unless there is a clear reason to change it.

Google’s site migration guidance recommends permanent server redirects for moved URLs and direct redirects to the final destination. An old product address should lead to its replacement, rather than a general homepage.

Check internal links, image references, canonical URLs and sitemap output. Keep the URL map as a testable file, with the expected response and destination for each address.

Rehearse complete orders

Use staging and payment test modes. WooCommerce explains that test orders can trigger emails and connected integrations, so isolate fulfilment, accounting and other services before placing them.

Test successful purchases, declined payments, cancellations and stock changes. Check the order in the administration area as well as the confirmation page. Staff should be able to identify the item, shipping method, custom options and payment state without reconstructing them from emails.

Plan the final data transfer

A test import becomes outdated while the existing store continues trading. Decide whether launch needs a maintenance window, a final incremental import or another controlled handover. Document who owns that decision.

Record the final backup time, import sequence and conditions for rolling back. A rollback plan must also explain how to handle any orders accepted by the new store before the problem was discovered.

After launch, compare agreed totals and inspect exceptions. Monitor checkout, payment notifications, redirects and integration failures. Keep a short issue log with an owner and expected resolution for each remaining problem.