Ecommerce Site Migration

Most migration guides are a list of steps. This one is organised around the questions that actually determine the outcome, because migrations rarely fail at the data-transfer step everyone worries about. They fail on the redirect map, they fail on a catalog that doesn’t fit the new platform’s model, and they fail on the plugin nobody realised was load-bearing.

We have been moving stores between platforms since 2010 — off WooCommerce and Magento, between BigCommerce and Shopify in both directions, and onto headless when the platform itself has become the constraint. This is the guide we wish clients had read before the first call.

First: should you migrate at all?

A large share of migration conversations start with a problem that will follow the store to any platform it moves to. Worth separating before spending anything.

The store is slow. On most slow stores we audit, the dominant cost is accumulated third-party scripts — apps on Shopify, plugins on WooCommerce — not the platform. Fifteen apps, several duplicating each other, some still loading for a campaign that ended two years ago. That store will be slow anywhere. Cleaning it up is days of work, not a replatform.

Conversion is poor. A new platform converts the same traffic at roughly the same rate, on a new bill. If demand is the problem, migrating is an expensive way to discover that.

It looks dated. That’s a theme. A new theme costs a fraction of a migration and arrives in weeks.

“We’ve hit the platform’s limits.” Worth testing precisely. Most limits merchants hit are configuration nobody has revisited. The real ones — Shopify’s three-option variant model, checkout customization outside Plus, native B2B depth, BigCommerce’s documented limits — are specific and nameable. If you can’t name yours, it may not be a platform problem.

Migrate when you have a constraint you can state in one sentence and it is costing you money. The rest of this guide assumes you do.

Choosing where to go

The honest version of platform selection is short, because the choice is usually driven by two or three facts about your business rather than a feature matrix.

Shopify has the strongest app ecosystem, the best checkout, and the smoothest day-to-day operations — particularly for DTC brands selling across channels. Its constraints: three options per product, checkout customization that lives on Plus, and B2B that needs Plus plus apps.

BigCommerce handles large catalogs and B2B natively — customer groups, price lists, quantity breaks and purchase orders without an app stack — and charges no platform transaction fees on top of processing. Its constraints: a smaller app ecosystem and fewer people who know it.

WooCommerce gives you the code and the checkout, with zero platform fees, and hands you hosting, patching and plugin compatibility. The low platform cost frequently reappears as developer time.

Headless — keeping a commerce engine and replacing the storefront with an application you control — is the answer when the storefront itself is the constraint: configurators, real-time availability logic, buying flows that don’t fit a product page. It is a commitment to maintaining software, not a theme.

The detailed comparisons: WooCommerce vs Shopify, Shopify vs BigCommerce, Magento vs Shopify, Shopify alternatives for the broader field, and headless commerce for what that trade actually involves — including our own platform, Throttle, and when it isn’t the right answer.

What decides the outcome: the redirect map

Every URL on your current store is about to change. On Shopify that’s guaranteed by enforced /products/ and /collections/ prefixes; on other platforms the structures simply differ. Each old URL needs to send visitors and search engines to its closest equivalent, and the completeness of that map is the single largest predictor of whether you keep your rankings.

Build the inventory from a crawl, not the sitemap. This is the step most often skipped, because the shortcut looks reasonable. Sitemaps on established stores are incomplete — they miss orphaned pages, retired campaign landing pages, discontinued products that still hold links, paginated and filtered category URLs, and anything the CMS quietly stopped listing. On a store of any age, a full crawl typically finds 20–40% more URLs than the sitemap knows about. Because those URLs are the oldest, they are disproportionately the ones with backlinks.

So the real inventory is the union of three lists: a full crawl of the live site, every URL that earned a visit or an impression in the last twelve months, and every URL in your backlink profile.

Every URL gets its closest equivalent. Not the homepage, not a generic category. Bulk-redirecting discontinued products to the homepage is treated as a soft 404 and the equity is discarded. Products with no equivalent and no backlinks can return 410; anything with links goes to the nearest relevant category or replacement.

Test both trailing-slash forms. Platforms and hosting layers disagree about whether /product/ and /product are the same address, and some redirect systems match literally with no normalisation. A map that covers one form and 404s the other silently loses half of everything — and it looks fine in a spot check. We found exactly this on our own site: four backlinks, including one from a DR 92 domain, landing on 404s because the rule matched the slashed form only.

No chains. If you have migrated before, old rules may already point A→B. The new map must point A→C directly. Chains leak authority and eventually get abandoned by crawlers.

Test every rule programmatically before launch. Not a sample. The full map, against staging, both slash forms.

The full method, as a working checklist: SEO migration checklist.

The catalog rarely fits

Product data transfers easily. Product structure frequently doesn’t, and this is the problem that surfaces late and blows up timelines.

Moving to Shopify: three options per product. A configurable product with size, colour, material and finish does not fit, and no setting reconciles it. The resolutions — combining attributes into a compound option, splitting into several products, moving a dimension into line item properties — each have consequences for merchandising and reporting. This is the defining problem of Magento to Shopify migrations and it shows up on WooCommerce to Shopify moves too.

Moving to BigCommerce: the distinction between options that create variants and modifiers that change price without creating a SKU is genuinely useful, and it means WooCommerce attributes and Magento configurables need deliberate remapping rather than a straight transfer.

Moving off BigCommerce: modifiers have no direct equivalent on Shopify, so modifier-heavy catalogs need rethinking.

The practical defence is a trial migration on a deliberately awkward subset — your most complex configurable, a bundle, a grouped product, a handful of customer records — run in the first week rather than the last. It converts the hardest question in the project from a month-three discovery into a week-one decision.

Apps, plugins and extensions

On every platform, a large share of storefront behaviour lives outside the platform: reviews, loyalty, subscriptions, wishlists, bundling, quoting, search. Each of those needs an equivalent on the destination, a custom implementation, or a decision to drop it.

Auditing that stack is frequently the largest single piece of work in a migration, and it should happen before the project is priced, because it determines whether you are looking at a migration or a migration plus a development programme.

Two specific traps: uninstalling an app rarely removes its theme code, so the old storefront’s leftover scripts are worth clearing before you measure anything; and reviews carry your review structured data, so losing them has a visible cost in search results, not just on the page.

Data: what moves and what quietly doesn’t

Products, categories and customer records generally transfer fine. The problems are in what people assume comes along:

• Password hashes never transfer between platforms. Every customer resets. Plan the communication — an unannounced forced reset across your customer base reads as a security incident and gets treated like one.
• Subscriptions almost never transfer. Recurring billing is tied to the payment processor and the app. In practice this means re-enrolling customers, which is a communication project as much as a technical one, and it deserves its own plan from the first conversation.
• Order history often migrates partially, and partial history is worse than none. Decide deliberately what you’re keeping and where customers can see it.
• Reviews live in an app or plugin, so they are invisible to a standard export.
• Gift cards and store credit are real liabilities. Confirm balances survive, or that you have a manual process.
• Tax and shipping rules need rebuilding and re-verifying, not porting.

The SEO surface beyond redirects

• Carry over titles and meta descriptions rather than regenerating them from templates. A wholesale rewrite at migration time makes it impossible to separate a design problem from a copy problem afterwards.
• Rebuild structured data. Product, breadcrumb and review markup are easy to lose in a theme change.
• Check canonical tags on the new platform, particularly on faceted category pages where defaults are frequently wrong.
• Keep robots.txt honest. Staging is normally blocked wholesale. Shipping that block to production is a classic, expensive launch-day mistake.
• Record the baseline before launch — organic sessions and revenue by month, top pages by traffic and by backlinks, current rankings, conversion rate, Core Web Vitals. Without it, you cannot distinguish a normal four-week dip from a real problem.

Timeline, and what actually moves it

Six to ten weeks for a conventional catalog including the storefront build. Longer with a large catalog, B2B pricing, ERP integration or subscriptions.

The variable that moves timelines most is rarely the platform work. It’s content and data: product information that lives in three systems, photography that needs redoing to a new design’s standard, category structures that haven’t been reviewed since the store launched. Projects that stall almost always stall there.

Two timing rules that save a great deal of grief: don’t migrate into your peak season — if it’s September and you sell at Christmas, the answer is January — and don’t redesign and replatform at once if you can avoid it, because afterwards you won’t know which change did what.

Launch, then watch

Lower DNS TTL a day or two ahead so you can reverse quickly. In the first 48 hours: monitor 404s continuously, watch server errors, confirm orders are flowing, submit the new sitemap to Search Console.

Over the following weeks, watch the Coverage report, watch rankings on priority terms, and expect a dip. Four to six weeks at 10–20% down is normal. A dip still deepening at week six is a problem, and the cause is almost always the redirect map.

Keep the old platform accessible — not serving — for at least a month. When something turns out to be missing, you’ll want somewhere to look it up.

Doing it yourself, or having it done

For a small, conventional catalog with no subscriptions and modest organic traffic, self-service is genuinely fine. Shopify’s Store Importer and BigCommerce’s migration apps move products, customers and orders competently, and there is no virtue in doing that by hand.

It stops being self-serviceable when the catalog needs remodelling, when reviews and subscriptions are involved, or when you have enough organic traffic that getting the redirects wrong costs more than the project. That’s the work we do — the redirect map, the remodelling, the app audit, the data that doesn’t move — and it’s described on the ecommerce migration services page.

Where to go from here

By route: WooCommerce to Shopify · WooCommerce to BigCommerce · Magento to Shopify · Magento to BigCommerce · Shopify to BigCommerce · BigCommerce to Shopify · Onto headless

By question: Should we leave Shopify at all? · WooCommerce vs Shopify · Shopify vs BigCommerce · Magento vs Shopify · The SEO migration checklist · The migration checklist, ordered by what goes wrong

Or tell us what you’re running — including the parts you suspect nobody has documented. If migrating isn’t the right answer, we’ll say so.