Migrating from Shopify to headless architecture means replacing the Liquid theme with your own frontend that talks to Shopify through the Storefront API, while catalog, orders, payments, inventory, and shipping stay in Shopify unchanged. A typical project takes 8-16 weeks and costs $80,000 to $150,000+ for a fully custom build - the range depends heavily on catalog complexity and the number of third-party integrations. The move doesn’t pay off for every store: below are the specific thresholds past which a Shopify theme becomes an architectural problem, not a design question.
In Exceltic.dev’s e-commerce web development projects, the typical trigger point looks almost the same every time: a Shopify store has grown steadily, the catalog has crossed a few thousand SKUs, the theme carries 15-20 installed apps - and PageSpeed on the product page has dropped below 50 under live traffic at peak hours.
According to Shopify’s own comparison of Liquid and headless performance, around 60% of Liquid stores pass all Core Web Vitals thresholds - meaning nearly half don’t, and the problem is systemic, not isolated. Allbirds reported a 40% improvement in load speed after moving to headless, and Staples Canada reached sub-one-second LCP on key landing pages.
What follows: the thresholds past which a Shopify theme becomes a bottleneck, what gets lost in a naive move, how a pre-migration audit works, which architecture to choose - Hydrogen or Next.js - and the Core Web Vitals numbers headless stores typically report after migration.
The problem isn’t abstract. The marketing team can’t add a new block to the product page because the theme is assembled from three page builders and any change breaks the mobile layout. The developer can’t speed up checkout because checkout logic is baked into apps that update without warning. And the executive can’t estimate the real cost of growth, because every new app adds a monthly subscription and tens of kilobytes of JavaScript that nobody ever removes.
Headless commerce: an architecture where Shopify remains the commerce engine - catalog, orders, payments, inventory, fulfillment - while the storefront runs as a separate application that pulls data through an API instead of server-rendering the Liquid theme.
When a Shopify Theme Becomes an Architectural Problem
Headless isn’t a default upgrade - it’s an architecture change with its own trade-offs: more expensive, slower to ship, and it requires a standing development team. It’s worth moving only when several of the thresholds below line up at once, not just one.
- Catalog and filtering - 2,000-3,000+ SKUs with multi-level variants and faceted search: a standard Liquid theme starts to lag on category pages because of DOM size and client-side filtering scripts.
- Number of apps - 15+ apps, each injecting its own JavaScript into the theme: total script weight grows faster than the store itself, and nobody on the team owns reducing it.
- Multiple storefronts on one catalog - a retail storefront, a B2B portal, and a mobile app all need to show the same catalog, but with different pricing and availability logic.
- Custom checkout beyond the plan - you need checkout logic that Checkout Extensibility doesn’t provide even on Shopify Plus.
- International storefronts - different languages, currencies, and legal requirements on the frontend that don’t fit the theme’s multi-storefront logic.
If none of these thresholds are crossed and the real problem is one slow section of the theme, it’s usually cheaper and faster to rewrite that section or switch themes than to launch an $80,000+ headless project.
What Gets Lost in a Naive Move to Headless
A direct lift-and-shift without a plan almost always breaks logic that has quietly relied on built-in theme and app functionality for years.
Apps built for Liquid themes - review widgets, popups, upsells - mostly don’t have a ready-made headless version. Each one has to be either replaced with an API-compatible alternative or reintegrated by hand through custom code.
Checkout logic customized through checkout.liquid on older plans doesn’t carry over to headless directly: Checkout Extensibility works on a different extension model, and part of the old customization has to be rebuilt from scratch.
Metafields and theme-specific data structures don’t always match what’s convenient to pull through the Storefront API - without explicit mapping, part of the product page content simply doesn’t show up on the new storefront.
SEO signals suffer without a redirect map: if the new storefront’s URL patterns differ from the theme’s, part of the accumulated search visibility is lost for a few weeks until Google re-indexes the new addresses.
Pre-Migration Audit - Checklist
Skipping the audit is the single most common reason headless projects go over budget: teams lose 15-40% of the real scope of work precisely because they never inventoried the store before starting. The difference shows up in money: an audit for a mid-size project runs roughly $8,000-12,000, and skipping it typically doubles the cost of fixes later on.
- Catalog and variant structure - number of SKUs, category depth, custom filters, products with unique pricing logic
- Apps and their role - which of the 15-20 apps are actually needed on the frontend, which can be replaced with backend logic
- Custom theme code - all the Liquid code that changes default behavior: galleries, upsells, shipping logic
- Checkout - what’s customized today and what’s covered by Checkout Extensibility
- Integrations - ERP, PIM, inventory management, email marketing, analytics - anything that pulls data from Shopify or writes into it
- URL and redirect map - the full list of current addresses, including category pagination, filters, collections
Architecture: Hydrogen, Next.js, or Remix
In 2026, the framework choice for headless Shopify comes down to three options, and the decision depends on how deeply the business is tied to Shopify specifically.
Hydrogen - Shopify’s own framework built on React Router v7 (formerly Remix), deployed on Oxygen, Shopify’s global edge hosting. It ships with ready-made commerce components, Storefront API hooks, and a predictable total cost of ownership because hosting is already included in the plan.
Next.js works headless against any backend with a GraphQL or REST API - not just Shopify. That choice makes sense when Shopify isn’t the only system in the architecture: there’s a separate CMS, PIM, or analytics platform alongside it, and you need independence from Shopify’s infrastructure.
Practical rule of thumb: if Shopify handles 80% or more of the business’s commerce logic, choose Hydrogen. If it’s under 50%, choose Next.js. Cases in between come down to team composition and project timeline, not abstract framework preference.
Marketing sites go through a similar architecture decision: migrating from WordPress to Next.js hits the same fork - a ready-made ecosystem versus a flexible custom stack.
Example Storefront API request
query ProductByHandle($handle: String!) {
product(handle: $handle) {
id
title
variants(first: 10) {
edges {
node {
id
price { amount currencyCode }
availableForSale
}
}
}
}
}Step-by-Step Migration Process from Shopify to Headless
1. Audit and Technical Scope
Inventory the catalog, apps, custom code, and integrations against the checklist above. The output is a document with the full scope of work and a list of risks - not just an estimate in weeks.
2. Framework and Hosting Choice
Decide between Hydrogen on Oxygen and Next.js on external hosting, based on Shopify’s share of the overall architecture and the development team’s composition.
3. Data Model Design
Map Shopify’s metafields, variants, and collections into a structure that’s convenient for the frontend: which data gets pulled directly through the Storefront API, which needs to be denormalized.
4. Building the Storefront and Connecting the Storefront API
Build the catalog, product page, cart, and search in the chosen framework, comparing each page against the current theme’s functionality.
5. Migrating and Adapting Apps
Replace apps without a headless version with API-compatible alternatives or custom code - the most consistently underestimated stage of the project in terms of time.
6. Checkout Customization via Checkout Extensibility
Rebuild checkout logic under the new extension model instead of directly porting the old checkout.liquid.
7. Redirect Map and SEO Signal Testing
Build a full 301 redirect map from old URLs to new ones, and verify structured data, sitemap, and canonical tags before launch.
8. Parallel Launch and Monitoring
Launch the new storefront on a share of traffic or in staging mode, monitoring conversion, speed, and checkout errors before the full cutover.
Core Web Vitals Before and After a Headless Move
According to Shopify’s own comparison, well-built headless stores show noticeably lower LCP and INP than a typical Liquid theme carrying a full set of apps - the gap is especially visible on product pages and category pages with filters.
In a typical migration project for a store with a catalog of 3,000+ SKUs, the headless version usually delivers a 30-50% improvement in load speed over the previous theme - the range is wide because the outcome depends heavily on implementation quality, not just the architecture switch itself.
Important caveat: the architecture change alone doesn’t guarantee a gain. A headless storefront built without attention to bundle size and caching strategy can end up slower than a well-optimized theme. The difference between “headless” and “headless done right” is a separate line item in the budget that’s often underestimated at the scoping stage.
If your team is already working through performance on the current platform, INP optimization - the metric that most often lags on product pages with many interactive elements - shows which problems the move solves architecturally and which you’ll need to fix regardless.
Common Mistakes When Moving to Headless
Skipping the catalog and app audit is the most expensive mistake: without it, the team discovers a critical app with no API access in the middle of development, when rework costs several times more than it would have at the planning stage.
Underestimating checkout: checkout logic looks like a secondary task, but it’s the piece that most often blows the launch timeline, because it’s tied to an extension model different from the old customization.
Launching without a redirect map: part of organic traffic drops for weeks if 301 redirects are set up after the fact instead of being built in parallel with the storefront.
Choosing a framework by hype instead of by Shopify’s share of the architecture: a team picks Next.js “because it’s more flexible,” even though 90% of the logic is pure Shopify, and ends up with more custom code to maintain without real upside.
Which Stores Should Consider a Headless Move
A headless migration pays off for stores with a catalog of several thousand SKUs or more, steady traffic growth, and a team ready to run development as a standing function - not a one-off project, but part of operating costs. For smaller catalogs and limited marketing budgets, the same money put into CRO and traffic acquisition on the standard theme usually pays back faster.
Frequently Asked Questions
How much does migrating from Shopify to headless cost?
A fully custom build typically costs $80,000 to $150,000+, depending on catalog complexity, the number of apps, and checkout requirements. Simpler projects built on Hydrogen’s ready-made components fall in the $15,000-50,000 range. The exact figure depends on audit results, not a standard price list.
How long does a move to headless architecture take?
A typical timeline is 8-16 weeks from the start of the audit to launch. Stores with a complex catalog, custom checkout, and many third-party integrations tend to land at the upper end of the range or beyond it.
Do you need Shopify Plus for a headless store?
For most production builds with full checkout customization - yes: Checkout Extensibility at the level you need is only available on the Plus plan. Some headless projects are feasible on base plans, but with limits on checkout customization.
Should you choose Hydrogen or Next.js?
If Shopify handles 80% or more of the business’s commerce logic, teams usually choose Hydrogen: predictable cost of ownership and ready-made components. If Shopify is only part of a broader architecture with a separate CMS or PIM, Next.js is often the better fit because of the independence from Shopify’s infrastructure.
Can you move only part of the store to headless?
Yes, a partial move is technically possible - for example, only category pages or a specific campaign - but it complicates maintenance because of two parallel rendering systems running at once. In most projects this only makes sense as a temporary step before a full move, not as a permanent architecture.
Bottom Line
- Move to headless only when several thresholds line up at once: catalog size, number of apps, custom checkout, or multiple storefronts on one catalog - not because headless sounds more modern.
- Budget the audit as a mandatory stage, not an option: skipping it is the main reason headless projects go over budget.
- Choose the framework based on Shopify’s share of the business architecture, not the development team’s personal preferences.
- Expect 8-16 weeks and $80,000-150,000+ for a fully custom build, adjusted for catalog complexity and the number of integrations.
If you’re evaluating a move of your Shopify catalog to headless architecture, tell the Exceltic.dev team about your catalog size, number of apps, and checkout requirements. We’ll break down the architecture and give you an honest estimate of timeline and budget.