Shopify Migration Playbook 2026: Replatforming Without Losing Revenue

Why brands replatform to Shopify in 2026

Shopify passed 12 percent of US ecommerce GMV in 2025 and now hosts more D2C brands doing over 10 million in annual revenue than any other SaaS platform in North America. Operators are not picking Shopify because it is trendy. They are picking it because the combination of hosted checkout, app ecosystem depth, Shopify Functions, and Hydrogen or Liquid flexibility has closed the gap on the features that used to send enterprise brands to Magento or custom builds. The cost of running a custom stack, or staying on a legacy platform that no longer ships meaningful updates, has quietly become the expensive path.

This playbook is the field manual we hand to D2C operators at Pixeltree when they are weighing a replatform from WooCommerce, Magento, BigCommerce, or Squarespace. It is organized the way the work actually flows: decide, audit, plan, build, cut over, stabilize. It assumes you run a real business with real ad spend, real SKUs, and real customers who will absolutely notice if their saved addresses disappear on launch day.

TL;DR

▸ Shopify migrations succeed or fail on three artifacts: the redirect map, the data migration plan, and the app inventory decision log ▸ Budget 10 to 16 weeks end-to-end for a mid-market catalog. Anything faster shifts risk into post-launch, not eliminates it ▸ Never migrate checkout, cart, or subscription logic one-to-one. Rebuild native on Shopify Checkout Extensibility, Shopify Subscriptions, or Recharge ▸ Freeze catalog and content changes 72 hours before cutover, run a seven-day staging order test, and staff support at 1.5x for two weeks ▸ Expect 90 to 100 percent organic retention if redirects and schema are clean. Expect 20 to 40 percent loss if they are not

Table of contents

• When migration makes sense
• Platform comparison matrix
• Pre-migration audit
• Data mapping across platforms
• The redirect plan
• Theme rebuild decisions
• App inventory and the ripcord framework
• Checkout, cart, and subscriptions
• Go-live checklist
• Post-launch monitoring
• 90-day stabilization plan
• Impact modeling
• What to ship this quarter

When migration makes sense

Replatforming is the most disruptive project a D2C operator will run in a given year. The bar for doing it should be high. We see four durable reasons brands successfully make the move, and three common anti-patterns that sabotage the business case.

The durable reasons: first, the existing platform is eating engineering hours that should go into growth. If your Magento 2 team spends two sprints a quarter on security patches and dependency upgrades, you are paying for maintenance instead of revenue. Second, the checkout conversion rate has plateaued below benchmark and you have exhausted optimizations within the current stack. Shopify Checkout is the single highest-converting hosted checkout in the US market for most categories. Third, app and integration velocity has slowed. If adding Klaviyo, Gorgias, or a new fulfillment partner takes eight weeks of custom work instead of eight hours of configuration, you are in the wrong ecosystem. Fourth, a platform end-of-life or acquisition has closed the door on continued support. Magento 1 holdouts, discontinued SaaS tiers, and deprecated BigCommerce plans all qualify.

The anti-patterns: migrating because a specific feature is better on Shopify (almost always solvable on your current stack). Migrating because a new CMO wants to ship something visible in their first 90 days (terrible reason, predictable failure). Migrating to Shopify with the intent of going headless immediately (you end up with two projects, both half-finished).

The test we use before any kickoff: can you write down three specific business outcomes, each with a measurable target, that migration unlocks and the current platform blocks? If you cannot, the project is premature.

Platform comparison matrix

The short version of platform fit across the four common source systems we see in our platform migration practice:

Within Shopify itself, the Basic to Plus question is its own decision. See our Shopify Basic vs Plus comparison, Shopify vs WooCommerce, Shopify vs BigCommerce, and Shopify vs Squarespace for the feature-by-feature reads.

The decision vectors that actually matter

Most platform comparisons list 200 features and weight them equally. That produces noise. The vectors that correlate with successful D2C outcomes:

▸ Checkout conversion rate on the source platform, measured as sessions that reach checkout divided by orders ▸ Time to ship a new sales channel (TikTok Shop, Amazon, retail point of sale) on the source platform ▸ Number of engineering hours per month spent on platform maintenance versus feature work ▸ App ecosystem depth for the three categories you depend on most (commonly email, reviews, subscriptions, shipping) ▸ Ability to run A/B tests on the storefront without custom infrastructure

Score your current platform on each. If three of five are red, Shopify is likely a step up. If only one is red, fix the specific gap first.

Pre-migration audit

The pre-migration audit is not optional and it is not a week of work. Done properly, it runs two to three weeks and produces four artifacts: a full URL inventory, a product data audit, an app and integration dependency map, and a content and SEO audit.

URL inventory. Export every indexed URL from Google Search Console, Ahrefs, Semrush, and your server logs. Dedupe. Classify each URL into one of five buckets: product, collection, content, functional (cart, account, etc.), and long-tail (tag pages, paginated archives, filter URLs). This is the raw material for the redirect plan. Expect 20 to 40 percent more URLs than you thought you had. Squarespace and WooCommerce archives in particular bury huge tails of auto-generated URLs that rank for nothing and bloat the migration.

Product data audit. Pull every product record with every attribute, image, and variant combination into a CSV. Flag products with missing images, missing meta descriptions, missing alt text, inconsistent variant naming, or orphaned collections. Shopify's product model has hard limits: 100 variants per product, three option dimensions, 250 characters per metafield key. If your Magento store has products with 500 variants through configurable-complex logic, they need to be restructured before import.

App and integration map. List every app, extension, plugin, and third-party integration touching the source platform. For each, answer four questions: does a Shopify equivalent exist, what is the data handoff on migration day, who owns the reauthorization, and is there a contract or data retention obligation. This feeds directly into the ripcord framework below.

Content and SEO audit. Run a crawl with Screaming Frog, Sitebulb, or Ahrefs. Export page-level metadata, H1s, internal link counts, and schema markup. Cross-reference with Search Console top queries and GSC-reported top pages. This identifies the 20 percent of content responsible for 80 percent of organic revenue. Those pages get migrated one-to-one with manual QA. The rest can move in bulk. If SEO is a first-order concern, pair this with our D2C ecommerce SEO guide.

Data mapping across platforms

Data migration fails for boring reasons. Character encoding, date formats, variant option ordering, tax class mappings, handle collisions. The engineering work is straightforward. The mapping decisions are where projects stall.

For a deeper walkthrough, see our Shopify migration data mapping post. The summary view:

The customer record decision

Three tactical calls on customer data: password handling (always require reset on first login post-cutover), marketing consent (preserve granular opt-in state, never reset to opted-in), and store credit or loyalty balances (migrate with a reconciliation report sent to finance before cutover). Loyalty balance errors are the single most expensive cleanup in a botched migration. We have seen brands eat six figures in comped orders because a balance got doubled or zeroed.

Order history

Historical orders import into Shopify as read-only records. Refunds, partial fulfillments, and returns against migrated orders cannot be processed through Shopify natively. Plan for either a 90-day overlap window where the old platform stays live for refund processing, or an ops runbook that handles refunds manually through the payment processor. Most brands pick the overlap.

The redirect plan

The redirect plan is the artifact that determines whether you keep organic traffic. Our redirect plan post walks through the long version. The short version:

Every URL in the pre-migration inventory gets one of four dispositions: one-to-one redirect to the equivalent new URL, many-to-one redirect to a canonical successor, redirect to the closest parent category, or 410 Gone. The mix on a typical migration is roughly 60 percent one-to-one, 20 percent many-to-one, 15 percent parent-fallback, and 5 percent 410.

The common mistake: blanket redirecting everything to the homepage. This is worse than 404ing the page. Google treats homepage redirects of internal URLs as soft 404s and will drop them from the index within two to three crawls. The rankings do not come back without manual intervention.

Redirect plan build steps

▸ Export the full URL inventory and annotate each with pre-migration organic sessions and revenue ▸ Sort descending by revenue. The top 20 percent gets manual mapping ▸ Pattern-match the long tail with regex rules (for example: /product-category/(.+) to /collections/$1) ▸ QA the pattern rules against a sample of 500 URLs before bulk apply ▸ Stage the redirects in Shopify's redirect tool or an edge redirect layer (Cloudflare Workers, Vercel middleware, Shopify's native URL Redirects) ▸ Validate with a crawler on the staging domain before cutover, not after ▸ Monitor crawl errors daily in Search Console for the first 14 days post-launch

Shopify's native redirect system has a soft limit around 100k entries and starts to affect admin performance well before that. For large catalogs, move redirects to the edge and keep the native tool for ad-hoc fixes.

Theme rebuild decisions

The temptation to port the old theme one-to-one is strong and almost always wrong. The theme is the artifact where you pay the replatforming cost. It should also be where you bank the ROI by shipping a faster, more conversion-optimized storefront.

Three theme paths, from lowest to highest effort:

Dawn or Horizon fork. Start from Shopify's reference theme, customize sections and styles, ship in four to six weeks. Best for brands under 5 million in GMV or those prioritizing speed and Core Web Vitals. Performance is excellent out of the box. See our Shopify performance playbook for the tuning details.

Premium theme customization. Start from a commercial theme (Impulse, Prestige, Motion, Broadcast), customize heavily. Ship in six to ten weeks. Best for brands that need rich editorial sections, lookbooks, or complex PDP features without custom development.

Custom theme or headless. Build on Liquid from scratch, or go headless with Hydrogen, Next.js, or Nuxt. Ship in 10 to 16 weeks. Best for brands with in-house frontend teams, genuine content freshness requirements, or multi-brand architecture. Our headless development and Shopify development services cover both paths.

The Liquid versus headless decision

We build both. The honest framing: headless is a freedom-versus-overhead trade. You get full frontend control and composable architecture. You take on the cost of owning your own frontend, deploy pipeline, and a second codebase. For most D2C brands under 10 million GMV, a well-built Liquid theme outperforms a rushed headless build on every metric that matters (LCP, INP, conversion rate, time to ship). Go headless when the business case is specific: a content-heavy publishing arm, a multi-region storefront with true localization needs, or an existing frontend team that will own it.

App inventory and the ripcord framework

Apps are where replatforms quietly bleed margin. The average Shopify store in our portfolio runs between 12 and 20 apps. Each one has a monthly cost, a performance cost (JavaScript and CSS injected into the storefront), and a dependency cost (data lock-in, integration maintenance).

The Ripcord Framework is how we audit apps during migration. Every app gets one of four classifications:

▸ Ripcord - mission-critical, replacement blocks go-live (payment processor, tax engine, shipping rates) ▸ Load-bearing - material to ops or revenue, replacement is pre-planned (email, reviews, subscriptions, helpdesk) ▸ Nice-to-have - used by the team but not critical (analytics dashboards, reporting, wishlist) ▸ Vestigial - installed, forgotten, contributing nothing (candidates for removal, not migration)

The rule: every Ripcord and Load-bearing app gets a named owner on both the old and new platform, a data handoff plan, and a rollback path. Every Nice-to-have gets installed in week six or later and gated behind a "do we actually need this" review. Every Vestigial app gets deleted before the audit ends.

On a typical 20-app store, the classification shakes out to roughly 4 Ripcord, 6 Load-bearing, 6 Nice-to-have, 4 Vestigial. Brands often ship launch with 10 to 12 apps and add back over the first 90 days as actual needs surface.

Checkout, cart, and subscriptions

This is the section where projects die. Checkout, cart, and subscriptions are the three areas where Shopify's model diverges most sharply from every source platform and where one-to-one ports break.

Checkout. Shopify Checkout is hosted, non-customizable at the payment layer, and governed by Checkout Extensibility for Plus merchants. If your source platform has custom checkout logic (dynamic upsells, gift wrap, B2B net terms, custom shipping calculators), each piece needs to be mapped to a Checkout UI extension, a Shopify Function, or an app that provides equivalent functionality. Do not schedule this in the final sprint. Scope it in week one.

Cart. Shopify's cart is session-based and simpler than most Magento or BigCommerce carts. Features that often need to be rebuilt: cart-level discounts with complex logic (moved to Shopify Functions), cart drawers with upsell logic (moved to theme + app combination), saved carts for logged-in users (native in Shopify), and multi-currency carts (native in Shopify Markets).

Subscriptions. Subscription migrations are their own specialty. The three options: Shopify Subscriptions (free, simpler, improving quickly), Recharge (market leader, deep features, additional cost), Bold Subscriptions (mid-market, flexible). The critical constraint: billing cycles and next-charge dates cannot be preserved perfectly across platforms. You will either have to pause, recharge-adjust, or communicate a one-time schedule change to subscribers. Communicate it. Do not hide it.

For the retention layer that sits on top of subscriptions, see our Klaviyo retention playbook and retention marketing service.

Go-live checklist

Cutover is ruthlessly mechanical. Every item here has killed a launch at some point. The full sequence, in order:

▸ T-minus 14 days: staging store locked, all data imported, redirects staged, apps installed ▸ T-minus 10 days: full QA pass on staging (catalog, checkout, customer account, subscription billing, tax, shipping) ▸ T-minus 7 days: parallel order test on staging with seven real orders through payment processor sandbox ▸ T-minus 72 hours: catalog and content freeze on source platform, final delta import scheduled ▸ T-minus 48 hours: DNS TTL reduced to 300 seconds ▸ T-minus 24 hours: support, ops, and marketing briefed on cutover plan and rollback criteria ▸ T-minus 6 hours: final delta import run, final QA smoke test ▸ T-minus 0: DNS flip, source platform put into read-only mode ▸ T-plus 15 minutes: synthetic order placed and refunded end-to-end ▸ T-plus 1 hour: ad platforms and email platforms repointed to new URLs ▸ T-plus 24 hours: first Search Console inspection of top 20 revenue URLs ▸ T-plus 72 hours: cutover retrospective with all stakeholders, incident log closed or promoted

We run cutover on a Tuesday morning US Eastern time. Never a Friday, never before a major sales event, never during a holiday week.

Post-launch monitoring

The first 14 days post-launch are where you discover what the QA missed. The metrics that matter, in priority order:

The analytics and reporting service we run for clients automates most of this. If you are operating solo, a Google Sheet with daily check-ins hits 80 percent of the value.

For the attribution layer specifically, see our attribution setup and GA4 implementation resources.

90-day stabilization plan

Migration is not done at cutover. It is done at day 90 when the metrics match or exceed pre-launch baseline across all priority indicators. The stabilization plan has three phases.

Days 1-14: triage. Every incident gets logged. Every metric outside alert threshold gets an owner and an ETA. No new features. No new apps. No scope creep. The only work is getting green.

Days 15-45: optimization. With baseline restored, start the conversion and performance work the migration was supposed to enable. PDP optimization, collection page improvements, cart drawer UX, checkout extensions. See our Shopify CRO playbook (if you have it) and the performance guide linked above.

Days 46-90: growth reinvestment. With the storefront stable and optimized, redirect the engineering and marketing bandwidth freed by the replatform into growth work. This is where the ROI on migration actually shows up. Common wins in this window: new paid channels enabled by cleaner attribution, new retention flows enabled by Klaviyo + Shopify data fidelity (see our Klaviyo implementation work), new LTV modeling enabled by cleaner customer records (see the LTV cohort playbook and our LTV modeling service).

Impact modeling

The numbers brands actually see post-migration, based on our portfolio across ~40 completed Shopify migrations:

▸ Core Web Vitals. LCP improvement of 20 to 45 percent when moving from unoptimized WooCommerce or Magento to a Dawn or Horizon-based Shopify theme. INP improvement of 15 to 30 percent. ▸ Checkout conversion rate. 8 to 18 percent lift when moving from custom or legacy checkout to Shopify Checkout. Larger lifts on mobile (often 20 to 30 percent) and for brands with high international traffic. ▸ Time to ship new features. 40 to 70 percent reduction in engineering time for platform changes (new sales channels, app additions, promotion types). ▸ App cost efficiency. 10 to 25 percent reduction in total SaaS spend when consolidating from Magento-era tooling into Shopify-native apps, after the transition window. ▸ Organic traffic. 90 to 100 percent retention at 60 days when redirects and schema are executed correctly. 110 to 140 percent of pre-launch organic at 12 months when paired with the D2C SEO work the migration enables. ▸ LTV measurement fidelity. 30 to 60 percent reduction in data reconciliation hours per month when moving to a native Shopify + Klaviyo + GA4 stack. This is the stealth ROI of replatforming and it shows up in better allocation decisions within a quarter. See our cohort analysis work for the measurement side.

None of these are guaranteed. Each requires the migration to be done correctly and the post-launch work to actually happen. Replatforming without the stabilization phase captures maybe 30 percent of the modeled upside.

What to ship this quarter

If you are weighing a Shopify migration and reading this guide, here is the 90-day checklist that makes the decision fundable and the project de-risked:

▸ Commission the pre-migration audit (URL inventory, product data, apps, SEO). Two to three weeks of work. Produces a go/no-go artifact. ▸ Lock the platform decision (Advanced vs Plus) with a written business case tied to three measurable outcomes ▸ Draft the redirect plan at 80 percent completeness before writing a line of theme code ▸ Run the app inventory through the Ripcord Framework and cut Vestigial apps on the source platform immediately ▸ Stand up the staging store and begin data import dry runs in parallel with theme work ▸ Scope checkout, cart, and subscription changes in the first sprint, not the last ▸ Write the go-live checklist and rehearse cutover at least once on staging ▸ Brief support, ops, and marketing on the cutover plan 14 days out ▸ Set up the post-launch monitoring dashboard before cutover, not after ▸ Plan the stabilization phase before the build phase starts, so day 15 does not catch the team flat-footed

Replatforming is not a technology project. It is an operations project with a technology component. Brands that treat it that way keep their revenue through the transition and capture the upside on the other side. Brands that treat it as an engineering sprint discover on day 30 why the field manual exists.

For engagement on any of this, our platform migration and ecommerce strategy teams run this playbook end-to-end. For the marketing layers that sit on top of the new stack, see paid ads, SEO, and the paid ads playbook.