The honest answer up front
Most stores that ask us about going headless shouldn't. The "Shopify is slow" complaint is usually a theme problem, not a platform problem. A well-built Liquid theme on a recent Shopify Plus stack hits the same Lighthouse scores as a custom Hydrogen build, with one-tenth the operating cost and a marketing team that can ship without engineering.
Headless is the right answer when your specific constraints make it the right answer. Below is the framework we use to decide, with the actual numbers from migrations we've shipped.
When headless wins
Five concrete situations where the math favors going headless:
1. You're outgrowing the Shopify CMS for content pages.
Shopify's CMS is built for products. If your site is half store, half magazine — content marketing, recipe pages, tutorials, location pages — the Shopify Pages editor falls apart around 50 pages. We see clients jury-rigging this with metafields, third-party CMS apps, and Liquid hacks. By the time you have 200+ content pages, you've already paid the cost of a CMS migration. Headless plus a real CMS (Sanity, Payload, Storyblok) is cleaner.
2. You need actual programmatic SEO at scale.
100 collection pages? Liquid handles it. 5,000 location pages × city × service combinations? Shopify's CMS hard-caps you and the build time becomes brutal. A headless front-end pulling from a structured data source can statically generate 50,000 pages at deploy time on Vercel or Cloudflare Pages.
3. Your design is genuinely outside what themes do well.
Three.js product viewers, complex multi-step quizzes, real-time configurators, AR try-ons. Themes can do these via heavy JavaScript embeds, but the result is slow. A custom React app makes them first-class.
4. You're operating in 5+ languages or 10+ markets.
Shopify Markets is fine for a handful of locales. Past that, the Liquid templating gets complex and the editor experience degrades. A headless setup with a CMS that has proper localization (Sanity is the gold standard here) handles 30+ locales without breaking a sweat.
5. Your team is already engineering-led.
If you have 4+ frontend engineers working on the storefront daily, Liquid is a productivity tax. Modern React tooling (TypeScript, hot reload, component libraries, testing) doesn't exist in Liquid land. The engineering velocity gain pays for the migration.
When headless loses
Four signals you're not ready, even if it sounds appealing:
1. Your team is under 50 engineers and your store does under $20M/year.
The annual cost of running headless — engineering time + hosting + CMS + edge compute + observability — typically lands at $80–150k for a non-trivial store. That's salaries-equivalent for one and a half engineers you don't have to spare. Below the $20M revenue threshold, the math rarely works.
2. Your marketing team owns the storefront day-to-day.
Headless moves authoring control from the Shopify admin into a CMS. Some marketing teams love it (Sanity Studio is genuinely good). Many don't — the workflow they're used to (preview, edit, publish, see it on the live store in 10 seconds) gets harder. If your marketing lead is going to send a Slack message every time they want to change a headline, headless will create more friction than it removes.
3. You haven't first squeezed your existing theme.
Half the "Shopify is slow" complaints we hear are theme issues fixable in a week. Lazy-load images. Defer non-critical JS. Remove the four review apps that nobody uses. Move from a stock Dawn fork to a custom theme tuned for performance. We've seen Lighthouse scores go from 28 to 87 without leaving Liquid. Don't migrate to escape a problem you haven't tried to solve.
4. You depend heavily on Shopify-native apps.
Subscriptions (Recharge, Bold), product reviews (Yotpo, Judge.me), wishlists, loyalty programs, abandoned cart, post-purchase upsells — every Shopify app makes assumptions about the storefront DOM that headless breaks. Some have official headless integrations, many don't. If your stack relies on five apps with no Hydrogen support, you're rebuilding their functionality from scratch.
What headless actually costs
Real numbers from migrations we've shipped, normalized to 2026 dollars:
| Cost | Range | Notes |
|---|---|---|
| Migration build (one-time) | $80k–$300k | Wide range driven by app integrations and CMS scope |
| Migration timeline | 14–24 weeks | Excluding the inevitable post-launch stabilization month |
| Hosting (Vercel/Cloudflare) | $200–$2,000/mo | Depends on traffic and ISR vs SSR mix |
| CMS (Sanity, Storyblok, Payload) | $100–$1,500/mo | Scales with editor seats and content volume |
| CDN/image optimization | $0–$500/mo | Depends on volume and provider |
| Observability + monitoring | $100–$400/mo | Sentry + Vercel Analytics or equivalent |
| Engineering maintenance | 0.3–1.0 FTE ongoing | Real number nobody quotes upfront |
Compare to a polished custom Liquid theme: $30k–$80k one-time, $0 in additional hosting (Shopify includes it), 0.1 FTE for maintenance. The gap is meaningful.
The four migration paths
If you've decided headless is the right call, the four common architectures and what each one is actually best at:
Path 1: Hydrogen + Oxygen (Shopify's stack). Shopify-built React framework + Shopify-hosted edge runtime. Tightest integration with Shopify APIs, official support, the cart/checkout primitives are first-class. Best when you're committed to staying in the Shopify ecosystem and you don't want to maintain hosting yourself.
Trade-offs: Hydrogen is opinionated, the routing model has changed twice in the last 18 months, and Oxygen pricing is per-traffic which gets expensive on viral spikes.
Path 2: Next.js (or TanStack Start) + Storefront API. You write a React app that calls Shopify's Storefront API (GraphQL). Hosted wherever you want — Vercel, Cloudflare, your own infra. Maximum flexibility, full control over the stack.
Trade-offs: You're building cart, checkout-redirect, and customer-account flows yourself against Shopify's APIs. Real work. The benefit is you can replatform off Shopify later with much less rework.
Path 3: Hybrid (Liquid + Next.js for content). Keep the storefront on Liquid (product pages, cart, checkout), put the marketing/blog on Next.js with a CMS, route between them with a reverse proxy. This is the underrated option.
You get the editor-friendly content layer without rebuilding the parts of the store that already work. Cost: ~30% of a full migration. We recommend this more often than full headless.
Path 4: Composable (multiple front-ends per surface). Marketing site on a CMS-driven Next.js app. Storefront on Hydrogen. Help center on a third platform. Each surface optimized for its purpose, glued together with a shared design system.
Reserved for stores doing $50M+ where the engineering team can support it. Most teams that try this without that scale end up with a maintenance nightmare.
The migration timeline that doesn't lie
A typical full Shopify → Hydrogen migration on a mid-sized DTC store ($5M-$30M annual revenue, ~500 SKUs):
| Phase | Duration | What's happening |
|---|---|---|
| Discovery + tech audit | 2–3 weeks | App inventory, custom Liquid map, integrations list, redirect map planning |
| Architecture + design system | 3–4 weeks | Component library, CMS schema, infrastructure setup |
| Storefront build | 8–10 weeks | PDPs, collections, cart, search, account pages |
| Apps + integrations | 3–4 weeks | Reviews, subscriptions, loyalty, abandoned cart |
| Content migration | 2–3 weeks | Blog, marketing pages, redirect map enforcement |
| QA + soft launch | 2–3 weeks | Staged rollout, parallel running, comparison metrics |
| Cutover + stabilization | 4 weeks | Real launch + the inevitable bugs nobody saw in staging |
Total: 24–30 weeks calendar time, 18–22 weeks of dev work. Anyone quoting you under 16 weeks is either lying or about to ship something broken.
What we typically deliver
For reference — this is the rough scope when we ship a Shopify migration:
- Full headless front-end on Hydrogen or TanStack Start
- CMS (Sanity or Payload, depending on team preference) with editor training
- Programmatic page templates for collections, blog, location/use-case pages
- Server-side analytics layer (the Cloudflare Worker pattern from our GA4 post)
- Meta CAPI dedup (the pattern that actually works)
- Redirect map preserving every existing URL with a 301
- Performance budget: sub-1.5s mobile LCP, sub-50ms INP, CLS under 0.05
- 30 days of post-launch optimization on the live data
- Documentation so your team can ship the next 100 pages without us
The recommendation we give 70% of the time
Don't migrate. Spend two weeks on theme performance, two weeks on a content audit, and two weeks instrumenting a real analytics layer. Most stores that arrive at our door wanting headless leave with a faster Liquid theme, a better tracking setup, and more revenue, for one-fifth the cost of the migration they came in asking about.
The 30% where we do recommend headless are stores that have hit one of the five "headless wins" criteria above and have the engineering team to support it. For everyone else: stay on Liquid, fix what's actually broken, revisit in 18 months.
Trying to decide on this and want a written diagnostic specific to your store? Send us your domain and we'll do the audit — what's actually slow, what's worth fixing in Liquid, what would only be solved by going headless, and what each option would cost over 24 months. Free, takes us about a day, no pitch.