Ecommerce migration: what to check before changing platform

An ecommerce migration is not simply a matter of copying products into a new admin panel. You need to move data, reproduce sales rules and integrations, preserve valuable URLs, rebuild measurement and switch the live domain safely. Miss one of these areas and the new store may look better while losing orders, inventory updates or organic visibility.

Before choosing a platform, inventory the current store and define exactly what the migration includes. This checklist will help you compare proposals and understand what you are paying for.

When does changing ecommerce platform make sense?

An inconvenient admin interface alone is rarely a sufficient reason. Migration is justified when the existing technology creates a genuine business constraint, for example when it:

• cannot support the required variants, markets, currencies or B2B model,
• needs expensive workarounds for essential integrations,
• makes secure updates and ongoing maintenance difficult,
• restricts improvements to the basket and checkout,
• produces unreliable sales data,
• has a predictable development cost greater than the cost of moving.

First separate platform limitations from problems with the offer, traffic or user experience. If shoppers do not understand the product, delivery costs appear too late or ads attract the wrong audience, migration alone will not solve it. Start with a diagnosis of why an online store is not selling. If you are considering two widely used platforms, compare WooCommerce and Shopify against your own team and operating model.

Inventory the current store before requesting a quote

A supplier should not estimate a migration from product count alone. Two stores with one thousand products can involve very different work. One may sell simple items while the other uses variants, bundles, customer group prices, several warehouses and subscriptions.

Document at least:

• products, variants, SKUs, attributes, categories and media,
• customers, addresses, marketing consents and order history,
• coupons, gift cards, points, reviews and wish lists,
• information pages, guides, policies and language versions,
• payments, delivery, taxes, invoices and discount rules,
• connections to ERP, WMS, accounting, marketplaces and email systems,
• product feeds, Merchant Center, advertising, analytics and consent management,
• domains, subdomains, mailboxes, certificates and account access.

For each item, record who owns the data, how it can be exported, how much history is required and how the result will be accepted. The official migration guidance for moving from WooCommerce to Shopify and moving to WooCommerce demonstrates that different data types can require separate methods, apps or custom imports. Do not assume one CSV file will carry everything.

Specify exactly which data will move

The specification needs a matrix covering the source data, destination, migration method, transformations and validation. Custom fields and relationships need particular care, such as linking a product variant to the correct image or an order to the correct customer account.

Some items cannot be moved on a one-to-one basis. Customer passwords can be stored in a form that cannot be exported to a different platform. Shopify's official store migration checklist notes that customer records can be imported but encrypted passwords cannot. In that situation you need an account activation or secure password reset flow, plus clear communication to customers.

These items also need an explicit decision:

• active subscriptions and payment tokens,
• unused gift cards and loyalty points,
• open returns, claims and orders in progress,
• marketing consent with its source and date,
• document numbers and records required by accounting.

If an item cannot move, the proposal should define an alternative, an archive or a manual process. An unresolved gap is not a migration plan.

Rebuild the sales logic, not just the design

The new store needs to calculate the same outcome wherever the business rules require it. Before launch, compare representative baskets that cover:

1. A simple product and a product with variants.
2. Percentage, fixed-value and restricted discount codes.
3. Free and paid delivery across relevant thresholds and regions.
4. Correct tax treatment for the required products and countries.
5. Guest checkout and an authenticated customer purchase.
6. Successful, failed, cancelled and refunded payments.
7. Inventory updates in both the store and connected systems.

This is an end-to-end test from the product price to the invoice, transactional email and stock adjustment. A list of integrations without test scenarios does not prove the sales process works.

Ecommerce SEO migration starts with a URL map

Collect every important old URL before making changes: products, categories, editorial content and information pages. Use the sitemap, analytics, Search Console and a crawl. Then map each URL to the closest equivalent resource on the new store.

Google's official guidance for a site move involving URL changes recommends:

• permanent server-side redirects from old URLs to new ones,
• direct redirects to the final destination without chains,
• updated internal links, canonical URLs and hreflang references,
• redirect testing and submission of the new sitemap,
• keeping redirects in place for as long as possible and generally at least one year.

Do not send every removed product or category to the homepage. Google warns that irrelevant redirects can be treated as soft 404 errors. Where no close replacement exists, decide whether the URL should return 404 or 410, point to a genuine successor product or lead to a relevant category.

Also check noindex directives, robots.txt restrictions, canonicals, structured data, pagination and language versions before release. The technical SEO checklist for a new website covers the wider launch checks.

Align Merchant Center, advertising and analytics

When URLs change, product feeds and advertising destinations must change with them. Google's Merchant Center landing page requirements state, among other things, that a link should lead to the specific product and that price, currency and availability should match the data sent to Google. After migration, verify a product sample and review feed errors again.

Analytics requires more than copying a script into the page header. The entire purchase journey must be tested. Google's reference for recommended ecommerce events in Analytics includes view_item, add_to_cart, begin_checkout and purchase. For a purchase, check the value, currency, item data and a unique transaction identifier to reduce duplicate revenue reporting.

Place a controlled order after the consent mechanism has been accepted. Then confirm the same transaction across analytics, the advertising platform, the store and the payment provider.

Plan the rehearsal, cutover and rollback

A safe plan includes a trial migration, testing on a non-indexed environment and a final synchronisation of changes. Agree a data freeze time, a method for handling orders submitted during cutover and the person authorised to approve the launch.

The release plan should include:

• a backup and a confirmed way to restore the old store,
• an ordered task list with an owner for each action,
• a final export of new customers, orders and inventory changes,
• switching the domain, SSL, integrations, scheduled jobs and email,
• rapid production tests of the critical purchase path,
• rollback criteria and the steps required to return,
• monitoring for errors, payments, orders and integrations after launch.

The phrase "zero downtime" is not a substitute for a procedure. A proposal should explain what happens to an order started one minute before cutover and how the team will detect a failure.

Post-migration acceptance checklist

Before signing off the work, check outcomes rather than completed tasks. The minimum list includes:

• matching counts for products, variants, customers and orders within the agreed scope,
• accurate images, attributes, prices, taxes, inventory and relationships across a data sample,
• customer login or a planned account activation route,
• search, filtering and the mobile shopping experience,
• every payment and delivery method, discounts, refunds and notifications,
• data exchange with ERP, warehouse, accounting and carrier systems,
• the redirect map, 404 report, canonicals and new sitemap,
• product feeds, campaign landing pages and essential analytics events,
• owner access to the domain, hosting, platform, data and backup.

Combine this with the broader website handover checklist, which also covers accessibility, security, performance, ownership and documentation.

What should an ecommerce migration proposal contain?

A reliable proposal defines the source and destination platforms, data scope, integrations, elements designed from scratch, SEO plan, testing, cutover and post-launch support. It should also state exclusions, responsibility for licences and third-party services, required access and acceptance criteria.

If the document only describes a new look, a page count and a deadline, the commercial risk still sits with the buyer. Give every prospective supplier the same inventory and questions before comparing prices.

Planning a platform change? See how we approach ecommerce development, review our portfolio, then contact us. Based on the current architecture and sales processes, we can determine whether you need a full migration, a phased rebuild or a focused repair.