Start a project
Strategy7 min read18 October 2024

When to leave Shopify (and when not to)

Shopify handles most eCommerce requirements well. The cases where it genuinely can't are specific. Here's how to think through the decision without the vendor bias.

Most advice on whether to stay with Shopify comes from someone who either sells Shopify services or sells something competing with Shopify. Neither perspective is useful. Here's a more honest framework.

The case for staying almost always holds

Shopify has improved faster in the last three years than in the preceding decade. Shopify Markets, B2B on Plus, Functions, Hydrogen, metaobjects, checkout extensibility — the platform has addressed most of the historical gaps that used to drive migrations away.

Before you conclude Shopify can't do what you need, check the date on the limitation you're citing. A lot of "Shopify can't do X" takes are from 2019.

That said, there are real cases where you're hitting a genuine ceiling.

When staying is probably the right call

You want more editorial flexibility. This is the most common stated reason for leaving Shopify. It's almost never a real constraint. Online Store 2.0's section/block architecture is genuinely flexible. If your theme doesn't do what you need, the problem is the theme, not the platform. A custom theme build costs less than a platform migration and doesn't introduce three years of maintenance overhead.

You want a faster site. Page speed is an engineering discipline, not a platform characteristic. Shopify storefronts built properly consistently hit Core Web Vitals green. Shopify storefronts built carelessly fail it, same as any other platform. The fastest sites on Shopify out-perform the median sites on every platform.

You sell B2B and need volume pricing / purchase orders. This used to be a genuine gap. Shopify Plus B2B handles most B2B requirements natively now — volume pricing, customer-specific catalogues, purchase order workflows. If you were planning a migration for this reason, revisit the timeline.

You've been told you need headless. You probably don't. The headless architecture debate is mostly vendor marketing (from Hydrogen, from composable commerce platforms, from agencies who charge more for headless builds). Unless you have a specific, articulable reason why the standard Shopify storefront can't serve your requirements — and "we want more flexibility" isn't specific enough — the operational overhead of a headless build is rarely justified.

When leaving might actually be correct

You need complex product configuration that runs calculations. CPQ (configure, price, quote) scenarios — products built from components with interdependent pricing rules — are genuinely difficult in Shopify. Functions can help but have execution limits. If your product catalogue is fundamentally a configurator that outputs a custom SKU, Shopify may not be the right fit.

You're a marketplace, not a store. Shopify is built for a single-vendor model. Running a multi-vendor marketplace on Shopify is possible (various apps exist) but requires significant custom work to maintain. If marketplace mechanics are core to your business model rather than an edge-case feature, a platform built for that model will serve you better.

Your regulatory environment has data residency requirements Shopify can't meet. For most UK/EU brands, Shopify's data handling is compliant. For specific regulated sectors (certain financial products, healthcare data, defence), you may have requirements that Shopify's infrastructure genuinely can't satisfy. This is rare and specific — get a legal opinion before using it as a migration reason.

You're doing genuine high-velocity flash sales with sub-second timing precision. Shopify's queue system handles demand well but isn't built for scenarios where fairness at millisecond precision matters (limited-edition drops with thousands of simultaneous users). There are workarounds, but if this is your core model, you'll spend more engineering effort working around Shopify's queue behaviour than you'd spend on a platform built for it.

The migration cost is always higher than quoted

Migration timelines and budgets are consistently underestimated — by the client and by the agency pitching the migration. The direct technical cost is the visible part. The hidden costs:

  • SEO recovery time (months, not days, even with perfect redirects)
  • Integration rebuild cost (every app and integration you have needs to be rebuilt or replaced)
  • Operations retraining
  • The 3-6 months of reduced conversion rate while customers learn the new experience
  • The ongoing cost of maintaining a more complex infrastructure

If the migration is solving a genuine platform ceiling, those costs are worth it. If it's solving a problem that's actually a theme problem or a configuration problem, you're spending migration budget on the wrong thing.

The honest question to ask

Before starting a migration conversation: can you articulate the specific capability gap in one sentence? Not "we want more flexibility" or "it's technically limiting" — those aren't specific enough to evaluate. Something like: "We need to configure products with more than 100 variants and Shopify's variant limit is a genuine operational constraint."

If you can't state the specific gap precisely, the answer is usually to fix the implementation rather than move the platform.

Facing a similar challenge?

If this resonated, we probably think alike. Get in touch.

Start a project