How long does a Shopify Plus migration take?

For a mid-market store with 5,000 to 50,000 SKUs, the realistic window is twelve to sixteen weeks from kick-off to launch. That covers discovery, data mapping, theme build, integration work, SEO preservation, user acceptance testing, and a staged launch. Simpler catalogues can compress to eight weeks. Complex B2B stores with bespoke pricing logic and multi-ERP integration often run twenty weeks or more.

What migrates cleanly and what has to be rebuilt?

Products, customers, order history, and blog content migrate cleanly with a proper tool. Themes almost always have to be rebuilt because Shopify's Liquid templating and section architecture do not map to any other platform. Checkout extensions, custom pricing scripts, discount logic, and third-party app customisations usually require a rebuild. Tax rules, shipping zones, and payment gateways are reconfigured rather than migrated.

How do you protect SEO during a Shopify Plus migration?

Three things matter most. First, a complete URL redirect map covering every legacy URL pattern, not just top pages. Second, canonical tags, title tags, and meta descriptions ported page-for-page rather than regenerated. Third, a pre-launch crawl of both the legacy site and the staging site so you catch schema, internal linking, and indexability regressions before Googlebot sees them. A properly planned migration loses less than ten percent of organic traffic in the first six weeks and recovers within three months.

Should you rebuild your integrations or lift and shift them?

Rebuild, almost always. Shopify's APIs, webhooks, and event model are structurally different from most source platforms. Trying to preserve the existing integration shape usually produces brittle middleware that breaks under Shopify's rate limits. A clean rebuild against Shopify's Storefront and Admin APIs takes longer upfront but produces integrations that are maintainable for years.

What is the typical budget for a Shopify Plus migration?

For a mid-market store, expect £60,000 to £150,000 for the build itself, depending on theme complexity, number of integrations, and whether you go with a Liquid theme or a headless frontend. Add £25,000 to £400,000 on top if you are building a custom headless storefront. Platform licensing starts at around $2,300 per month. Most first-year total cost of ownership lands between £100,000 and £250,000 inclusive of build, platform, apps, and post-launch support.

When should you freeze changes on the legacy platform?

Freeze code and schema changes four weeks before launch. Freeze product catalogue changes two weeks before launch. Freeze everything — including new customer accounts if possible — 48 hours before cutover. Any change on the legacy platform after the final data export has to be reconciled manually on Shopify, and this is where launch-weekend data loss almost always comes from.

Shopify Plus Migration Checklist: A Technical Teardown

A Shopify Plus migration is a substantial engineering project dressed up as a platform switch. Most of the work is not in Shopify itself — Shopify is the easy part. The work is in the data mapping, the redirect planning, the integration rewiring, and the operational cutover. Teams that treat migration as a configuration exercise tend to launch with broken checkout flows, lost traffic, and three months of firefighting.

This checklist is for operators planning a migration from Magento, BigCommerce, WooCommerce, Salesforce Commerce Cloud, or a custom stack onto Shopify Plus. It assumes you have already made the platform decision — if you are still weighing options, start with our Shopify Plus guide and then come back. Everything below is the sequence and the pitfalls.

Phase 1: Discovery and Scoping (Weeks 1-2)

Before anyone writes code, get the scope pinned down. Migration failures trace back to scope assumptions made in week one that only surface in week ten.

Catalogue audit. Count everything: SKUs, variants, collections, tags, metafields, custom attributes, digital products, bundles, subscriptions. Flag anything unusual — configurable products in Magento, grouped products, MSI inventory, complex attribute inheritance. Each of these requires a mapping decision on Shopify.

Integration inventory. List every system connected to your current platform. ERP, 3PL, PIM, OMS, CRM, email service provider, reviews, loyalty, subscriptions, tax, fraud, analytics, payment gateways. For each: what data flows, in which direction, via which API or file format, and who owns the integration.

Customisation inventory. Document every theme customisation, extension, custom module, script-based discount, hard-coded pricing rule, and front-end change made over the life of the platform. On Magento installations five or more years old, this list is usually longer than the team remembers.

Traffic and revenue baseline. Pull 12 months of organic sessions, revenue by landing page, and top 500 landing URLs. These are your success metrics — you need the baseline to prove migration did not break anything.

Stakeholder list. Merchandising, operations, marketing, customer service, finance, dev. Each has veto power on launch if their domain is not ready. Identify the single decision-maker for each area.

Output: a scoped statement of work, integration matrix, and SEO baseline report. If any of these are missing, do not start the build.

Phase 2: Data Mapping (Weeks 3-4)

Data mapping is where migrations silently go wrong. The data gets moved; the relationships between data do not. Plan for four categories.

Products and variants. Shopify’s product model has a simple shape: product > variants > options (up to three, with up to 100 variants per product). If your source platform has configurable products with unlimited options, parent-child relationships, or attribute-level inheritance, you need an explicit mapping strategy. Usually this means either flattening options (lose flexibility, gain simplicity) or using metafields plus Shopify Functions to reconstruct complex pricing.

Customers and order history. Shopify accepts customer and order imports through its Admin API. The gotcha is password migration: you cannot migrate hashed passwords. Every customer has to reset their password on first login after cutover. Plan the email communication for this — done badly, it looks like a phishing attempt and spikes your support tickets.

Content and metafields. Blog posts, pages, and CMS content move with Matrixify or similar tooling. Custom attributes become metafields. Decide upfront whether each metafield is surfaced in the storefront (needs theme support) or admin-only (reference for operations).

Media. Product images, lifestyle shots, video. Shopify’s CDN handles serving; you handle uploading. For catalogues over 10,000 SKUs, automate image migration via the Files API rather than clicking through uploads. Budget one full day for media per 5,000 products.

Output: a filled data mapping spreadsheet with source-field-to-target-field for every data type, and a sample migration run of 100 products end-to-end.

Phase 3: Theme and Storefront Build (Weeks 4-10)

This is the longest phase. Two decisions drive everything else.

Liquid vs headless. For most mid-market stores, a well-built Liquid theme outperforms a poorly-maintained headless build at a fraction of the cost. Go headless only for a specific, defensible reason — usually omnichannel content strategy, extreme performance requirements, or an existing in-house front-end engineering team. Our headless commerce guide covers the trade-offs in detail.

Theme source. You can start from Shopify’s Dawn theme, buy a commercial theme, or build bespoke. Dawn is the safest baseline — it is kept in sync with Shopify’s theme architecture and benefits from core web vitals work the Shopify team ships. Commercial themes look polished but often carry technical debt that will bite in year two.

Key theme work during this phase:

Section architecture that gives merchandising teams control without developer involvement
Product page variants — colour swatches, size selectors, dynamic pricing display
Collection filtering and sorting — native Shopify search plus any third-party search (Searchanise, Algolia, Klevu) you are adding
Cart and checkout extensions (Plus only) — loyalty redemption, shipping rules, upsell modules
Metafield surfaces — every admin field that appears in the storefront needs theme code
Mobile performance — Core Web Vitals at mobile benchmarks are table stakes on Plus

Run the emerging theme against real catalogue data from week five onwards. Themes that look fine on the demo data collapse when you point them at 30,000 real products with inconsistent image sizes and half-filled metafields.

Phase 4: Integrations (Weeks 6-12, parallel with theme)

Integrations are almost always the longest tail of a migration. Plan them in three tiers.

Tier 1 — launch-critical. Payment gateway, tax calculation, shipping rates, fraud checks, core ERP/OMS sync. If any of these fail at launch, you cannot take orders. Build, test, and sign these off by week ten.

Tier 2 — launch-important. Email marketing (Klaviyo or equivalent), reviews platform, loyalty programme, CRM sync. Missing these at launch is painful but survivable. Aim to ship Tier 2 at launch; have a fallback plan for each if they slip.

Tier 3 — launch-eventual. Analytics enrichment, reporting warehouses, BI pipelines, non-critical third-party apps. These can ship in the first two weeks post-launch without catastrophic impact.

Approach integrations by rebuilding, not porting. Shopify’s webhook and event model differs significantly from most source platforms. Attempting to preserve the existing integration architecture usually produces middleware that breaks on first rate-limit event.

For high-volume stores — over 1,000 orders per day — treat API rate limits as a first-class design concern. Shopify Plus provides higher limits than standard Shopify, but they are still finite. Batch operations, retry with backoff, and idempotency keys are not optional.

Phase 5: SEO Preservation (Weeks 8-12)

SEO damage is the single most expensive migration mistake. A poorly-executed migration can take twelve to eighteen months of traffic to recover. Three deliverables matter.

Redirect map. Every legacy URL pattern needs a Shopify target. Not just the top 1,000 pages — every pattern. Typical map for a mid-market catalogue includes:

Product URLs: /catalog/product/view/id/12345 → /products/widget-premium
Collection URLs: /category/widgets.html → /collections/widgets
Blog URLs: /blog/post/seo-tips → /blogs/news/seo-tips
Filter URLs: /widgets?size=large → /collections/widgets?filter.size=large
Search URLs: /catalogsearch/result/?q=widget → /search?q=widget

Load redirects into Shopify’s URL redirects feature (up to 100,000 per store) or a redirect app for higher volumes. Test every pattern against live URLs before launch.

On-page SEO parity. Title tags, meta descriptions, canonical tags, H1 content, structured data — port page-for-page, do not regenerate. Teams that regenerate meta at launch see rankings drop for weeks while Google re-learns the page. Port first, optimise later.

Crawl comparison. Run Screaming Frog or similar against the staging site and the live legacy site. Compare: indexable URL count, structured data coverage, internal link counts, title length distribution, hreflang implementation if international. Any significant divergence needs explanation before launch.

Our technical SEO guide for ecommerce covers crawl budget, faceted navigation, and canonical strategies in depth if you want the fuller picture.

Phase 6: User Acceptance Testing (Weeks 11-13)

UAT is where most migrations are saved or lost. Structure it in two waves.

Wave 1 — feature UAT. Merchandising, operations, customer service, and marketing each run through their daily workflows on staging. Create a product. Add a collection. Process a return. Run a discount code. Ship an order. Each team signs off their domain before launch. Time-box this to one week; dragged-out UAT is usually a sign that scope was wrong.

Wave 2 — customer-flow UAT. End-to-end customer journeys: browse, search, add to cart, checkout as guest, checkout as logged-in, apply discount, request return. Test on desktop and mobile. Test with real payment methods (sandbox for cards, live for PayPal and BNPL where sandbox is limited). Log every issue, triage, fix, retest.

Performance testing runs in parallel: realistic load tests against staging — not just page-speed benchmarks, but concurrent-user tests that match your peak traffic.

Phase 7: Cutover (Launch Weekend)

The cutover itself should be boring. Everything interesting should have happened in testing.

T-minus 48 hours: final data export from legacy, final data import to Shopify, DNS TTL reduced to 300 seconds to enable fast cutover, cart and customer account freeze announced to customers (usually not needed but good hygiene).

T-minus 12 hours: final reconciliation of orders placed during the freeze window, manual import of any stragglers, final smoke test of every payment method and every critical integration.

Cutover: DNS switches to Shopify. Monitor every tier-1 integration for errors in the first hour. Have a rollback plan documented (redirect DNS back to legacy) but know that for most migrations, rollback is not actually viable after the first hours of live traffic.

T-plus 24 hours: monitor error rates, conversion rate, and organic traffic. Expect a small dip in conversion (customers adjusting to new UX). Larger dips suggest broken analytics, not broken checkout. Validate analytics before diagnosing checkout.

Phase 8: Post-Launch Stabilisation (Weeks 14-18)

The work is not done at launch. The next four to six weeks matter almost as much.

Daily: error rate monitoring, integration health checks, conversion rate versus baseline, organic traffic versus baseline.

Weekly: redirect health (which redirects are getting hit, which are 404ing, any patterns missed), GSC coverage and core web vitals, customer service ticket trends for migration-related issues.

Monthly for three months: organic revenue by landing page compared to pre-launch baseline. A successful migration is back to baseline within three months and ahead of baseline by month six.

Common Failure Modes

A few patterns show up in nearly every migration that goes badly.

Skipping the integration inventory. Week ten, someone remembers that the sales team uses a bespoke quoting tool that hooks into the legacy platform. This happens on almost every migration over £100,000. The fix is discipline in Phase 1.

Passwords as a surprise. The merchandising team discovers two weeks before launch that customers will need to reset passwords. They ask to keep legacy passwords. The answer is no — but the conversation needed to happen in week two, not week eleven.

Discount logic on launch day. The promotional calendar has a site-wide 20% discount running on launch day. The discount was implemented on the legacy platform via a script that does not exist on Shopify. Sales reps improvise. Revenue reporting is useless for six weeks. Freeze promotional logic in the last two weeks before launch.

SEO regressions caught too late. The migration launches, rankings drop, diagnosis starts. By the time the redirect map is fixed, two months of organic revenue is lost. The fix is a pre-launch crawl comparison, not a post-launch diagnosis.

What a Good Partner Looks Like

Most businesses migrating to Shopify Plus hire an agency rather than run the migration in-house. A good partner on Plus migrations:

Has run at least five migrations from your source platform specifically
Writes migration plans that name the week-by-week deliverables, not just the phase list
Insists on a frozen scope by end of week two
Assigns a single technical lead who stays on the project from discovery to post-launch
Provides a retained support engagement for the first three months after launch

Beware partners who quote fixed-price migrations without a discovery phase, propose launch timelines under eight weeks for mid-market stores, or suggest bypassing UAT to hit a date. Any of these is a signal that the partner is optimising for signing the contract, not for a clean launch.

We run Shopify Plus migrations for UK mid-market ecommerce businesses. If you are planning one, get in touch — or read more about our approach on the Shopify Plus services page.