Ecommerce Platform Migration Checklist (2026)

An ecommerce platform migration checklist that protects revenue has six phases: discovery, data, redirects, integrations, cutover and the ninety days after launch. The data export is the smallest of them. The store that comes through clean is the one that mapped every URL, reconciled every integration and ran both platforms side by side before it pointed traffic at the new one. Our Shopify Plus migration service starts from £15,000, with the fee and the timeline set by data size and complexity; this is the checklist we run inside it, and the same list applies to a BigCommerce move.

The redirect and search steps below follow Google's own site move with URL changes guidance, and the platform steps follow Shopify's and BigCommerce's developer documentation, linked where each is used.

The migration checklist at a glance

Phase 1: discovery

Your current site does more than you think. Catalogue every integration, automation, custom feature and workaround, and talk to everyone who touches the system: customer service, warehouse, finance, marketing. They know the edge cases the documentation never captured: the nightly stock file, the VAT rule for the Channel Islands, the discount that only fires for one wholesale account. Each undocumented behaviour is a launch-day incident waiting to happen.

Then separate must-haves from can-waits. What does the new platform have to do the moment you flip traffic, and what can ship in week two? Write it down and get sign-off; a vague brief is how a project doubles in length. Set the timeline after discovery, not before, and give it a buffer for data cleanup, redirect testing and staff training. Rushing the launch to hit an arbitrary date is how redirect testing gets skipped, and that is where the traffic goes.

• Data: products, variants, customers, orders, content, reviews, SEO metadata
• Integrations: ERP, WMS, email, analytics, payment gateways, shipping
• Search: URL redirects, sitemap, structured data, meta information, inbound links
• Features: everything the current site does that customers or staff rely on
• Training: everyone who uses the admin needs to learn the new one before launch

Phase 2: data migration and the cleanup budget

Product data rarely maps cleanly. Variants, metafields, option sets, category trees and images are structured differently on every platform, and the export almost never lands ready to use. Budget real hours for reconciliation, more if the catalogue has accumulated years of inconsistencies, and always migrate a representative subset first, validate it end to end, then run the full load. On Shopify the full load is a bulk job rather than a UI import: the GraphQL Admin API bulk import takes a JSONL file of mutation variables, uploaded through stagedUploadsCreate and run with bulkOperationRunMutation, which is how a large catalogue lands without a client-side throttle. Check Shopify's variant structure against your product types early; our variant limits guide covers the cases that do not map one-to-one.

Customer and order history are usually more mechanical, but verify the things that quietly break trust: loyalty balances, active subscriptions, saved addresses and tax-exemption flags. Order history has to survive intact for returns, accounting and support; losing it is a problem that resurfaces for months.

Phase 3: the redirect map is the whole game

In the migrations we run, poor redirect handling is the failure that costs the most. Google's site move guidance is specific about what to do, and it is worth following to the letter. Prepare a URL mapping from every old URL to its new equivalent. Give each new URL a self-referencing canonical, update hreflang annotations if you have them, update internal links to the new URLs, and keep two lists for launch day: a sitemap of the new URLs and the list of sites linking to the old ones from Search Console.

Use server-side permanent redirects (301 or 308), avoid chaining them, and never redirect many old URLs to one irrelevant destination such as the homepage, which Google says may be treated as a soft 404. Google recommends that small and medium sites move all URLs at once, while large sites can move one section at a time to make problems easier to isolate. Crawl the existing site in full, export every indexable URL, and map old to new one-to-one, including products, collections, blog posts, paginated pages and legacy campaign URLs.

Platform paths change, so a like-for-like URL is often impossible and the redirect becomes mandatory. On Shopify, redirects are created with urlRedirectCreate, and a large map goes in as a CSV through urlRedirectImportCreate followed by urlRedirectImportSubmit; both need the write_online_store_navigation scope. On BigCommerce, the Redirects API manages 301s per storefront channel, and BigCommerce creates them only for channels of type storefront, not for marketplace or marketing channels.

Test the redirects before launch with Google's URL Inspection tool for individual URLs and a script for the full map, then re-test the highest-traffic URLs the moment you cut over. If the domain or subdomain changes, submit a Change of Address in Search Console. For worked examples of clean platform moves, see our Magento to Shopify migration and Volusion to BigCommerce guides; Volusion exits need SEO triage before the move, which is what our Volusion SEO service exists for.

Phase 4: integrations tested against real orders

Every integration from the discovery list gets rebuilt or reconnected and then exercised with real test orders on staging: an order placed, paid, fulfilled, partially refunded and returned, with the ERP, warehouse, email and analytics each confirming what they saw. This is where the integration that times out under load and the tax rule that rounds the wrong way show up, before they cost real orders. Webhook endpoints need idempotency, because every platform retries.

• One order placed, paid, fulfilled, partially refunded and returned on staging, end to end
• ERP, WMS, email and analytics each confirm the order and its status changes
• Tax and rounding checked on a multi-line order with a discount
• Webhook endpoints idempotent under a replayed event
• Every integration from the discovery list ticked off, or consciously deferred to week two

Phase 5: the parallel run and cutover

Do not flip the switch overnight. Run both systems in parallel: process real test orders on the new site, reconcile inventory against the old one, and let staff work in the new admin before customers see it. Point the DNS and turn on the redirects in one planned window, once the redirect map has been tested and the new sitemap is ready to submit. Google's guidance for the move itself is to implement the redirects, check that canonicals and any temporary noindex rules on the new site have been updated, test, and then monitor traffic on both the old and the new site.

• Redirect map tested on staging and the top URLs re-tested at cutover
• New sitemap ready to submit; temporary noindex rules removed
• Staff trained in the new admin and the support scripts updated
• DNS window agreed, with a named owner for the rollback decision
• Change of Address submitted if the domain or subdomain changes

Phase 6: prove the metrics held

Staff the first weeks heavily. Monitor conversion rate, checkout completion, error logs and customer complaints alongside Search Console; a migration can launch with zero downtime and still lose conversions to a slower checkout or a broken discount. Measure performance against Google's Core Web Vitals thresholds at the 75th percentile: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Organic traffic normally moves while Google recrawls a moved site; what you are watching for is a dip that keeps falling rather than settling, which points at broken redirects or de-indexed pages. A new platform is also the chance to fix what was slow before; our store performance guide pairs with the cutover.

A successful migration is not "we launched without downtime". It is "our organic traffic, conversion rate and order accuracy held or improved ninety days later". For a worked example of the catalogue side, the Veluare launch case study shows a full product catalogue migrated onto Shopify with clean data: consistent naming, materials kept in titles where buyers search for them, accurate collection tagging, and no dead links on go-live day.

Shopify migration checklist: the platform-specific items

• Map every old path to Shopify's /products/, /collections/ and /pages/ structure before you build the redirect CSV.
• Load the catalogue with the bulk import, not the admin importer, once the subset has validated.
• Import redirects through urlRedirectImportCreate and confirm the count in the admin before launch.
• Check variant and option counts against Shopify's limits per product.
• Plan the customer password flow at cutover before you announce the launch date.
• If you are moving to Plus for B2B, confirm which features your plan includes using our Shopify B2B guide.

If you are still choosing a platform before any of this starts, our BigCommerce vs Shopify decision guide and when Shopify Plus makes sense cover the choice itself; this checklist is what you run once it is made.