Hydrogen is real. So is the cost of leaving a Shopify theme.
I get asked for headless when a storefront feels slow, when a design system wants React everything, or when a team simply heard that “serious brands go headless.” Sometimes Hydrogen (or another headless stack) is worth it. Often it is an expensive answer to a theme-tax problem.
Here is the go / no-go checklist I use before anyone celebrates a migration.
What Hydrogen is buying you
In plain terms, Hydrogen is Shopify’s React-based approach to custom storefronts that talk to Storefront API / customer account APIs, typically hosted on Oxygen or another Node-friendly host. You gain:
- Component-level control over UX
- Closer fit to a modern JS design system
- Flexibility for content-heavy or app-like shopping experiences
- Performance potential if you engineer for it
You give up a lot of Online Store defaults: the theme editor comfort zone, many app embed assumptions, and the “hire any Liquid freelancer” labor market. That trade can be correct. It should be conscious.
The theme ceiling is real — diagnose it carefully
Themes hit ceilings:
- Complex bundling / subscription UX that fights Liquid sections
- Highly interactive merchandising that becomes jQuery soup
- Multi-brand or multi-market experiences that need app-like navigation
- Design systems already standardized on React
Before migration, I still run the theme-tax audit from earlier in this series: kill unused embeds, fix image weight, measure PDP and collection field data. I have seen “we need Hydrogen” tickets close after removing three popups and a chat widget. If you want a revenue framing for speed work, the upcoming page speed revenue calculator is aimed at that conversation.
If the ceiling remains after discipline, we talk headless.
Cost categories merchants underestimate
A honest Hydrogen estimate includes more than “rebuild the homepage in React.”
Budget for:
- Rebuilding templates that themes gave you: cart, collections, search, account, blogs, policies
- App replacements — many apps assume theme app extensions; headless needs APIs, custom UI, or different vendors
- Auth and account flows done properly
- Preview / content workflows for non-developers (CMS choice matters)
- Analytics and pixels re-implemented carefully
- Performance engineering — headless can be slow if you waterfalls fetch
- Ongoing JS maintainership — React upgrades, dependency noise, hosting
- SEO parity QA — canonical tags, sitemaps, redirects, structured data
Teams compare a theme tweak quote to a Hydrogen dream and wonder why numbers differ by an order of magnitude. They differ because the surface area differs.
Go checklist (green lights)
I get more comfortable recommending Hydrogen when several of these are true:
- You have (or will hire) ongoing React/storefront engineering capacity
- Design requires interaction patterns themes fight weekly
- App embeds are already a losing battle and custom UI is inevitable
- You accept that merchandising may move toward a CMS + code workflow
- Performance goals are paired with a measurement plan, not vibes
- Launch scope is phased (core paths first), not “boiling the ocean by Friday”
- Legal / checkout requirements are understood (Checkout extensibility vs reinventing checkout — usually you should not reinvent checkout)
No-go checklist (yellow / red lights)
Pause or stop when:
- The primary pain is third-party scripts on a stock theme
- No one on the team can maintain React in six months
- Budget only covers a glossy homepage, not cart/search/account parity
- Success metric is “be headless” rather than a customer-facing outcome
- You need a dozen theme-app-extension-dependent apps with no replacement plan
- You are three weeks from a peak sale and want a full cutover
Hydrogen does not fix a messy catalog, weak ops, or unclear positioning. It can amplify them with a larger build surface.
Migration shapes that reduce risk
I prefer:
- Phased paths: PDP + collection first behind a flag, then cart, then secondary templates
- Keep checkout on Shopify rather than romanticizing a custom checkout
- CMS for marketing pages so developers are not tickets for every banner
- Contract tests for Storefront API queries you depend on
- Redirect and SEO map before cutover night
- Performance budgets per route (JS KB, waterfalls, LCP owners)
Big-bang rewrites are how brands spend twice.
Theme vs Hydrogen decision table I put in proposals
Lean theme when: editor-driven weekly campaigns are central; app-embed pain can be fixed with discipline; no steady React staffing; near-term peak sale; budget is mostly for design polish.
Lean Hydrogen when: you need highly custom shopping UX; app embeds are a lost cause and custom UI is inevitable; an in-house React team will own the storefront; merchandising can adopt CMS + code; performance work has a real measurement plan.
Staffing is the hidden line item
A theme store can limp along with intermittent freelancer help. A Hydrogen storefront is a living React app. Someone must own dependencies, incident response, and feature velocity after launch week.
When a merchant says they want headless but will “maybe hire later,” I translate that as: the storefront will freeze after launch while competitors on themes keep shipping sections. Unless the initial build truly unlocks revenue that themes cannot, freezing is a bad trade.
From Karachi I can build and maintain these apps — but the retainer must reflect reality. A Hydrogen retainers looks more like product engineering than occasional Liquid tweaks. If the budget only supports tweaks, stay on themes and buy excellence there.
Content previews and the merchant experience
Theme editors forgive a lot. Merchants change headlines, swap heroes, and publish. Headless without a CMS preview workflow pushes every copy change into an engineering ticket. That kills campaign speed.
Before I approve a migration, I ask: who publishes a Mother’s Day landing page, and how? If the answer is “a developer deploys,” we either add a CMS with preview or we reconsider. Hydrogen can integrate with modern CMS options; the point is to fund that integration in the same project, not as a surprise quarter later.
Performance myths that push bad migrations
“Headless is automatically faster” is false. A React storefront with uncached Storefront API waterfalls, huge client bundles, and third-party scripts will lose to a disciplined Online Store theme. Hydrogen gives you control; control can be used well or poorly.
If LCP is the crisis, profile the current site. Remove embeds. Fix images. Tune fonts. Re-check field data. Only when architecture — not negligence — is the limiter do I put Hydrogen on the table for speed alone. Pair that discussion with conversion math; the upcoming page speed revenue calculator exists so “faster” has to earn its migration cost.
My default advice
Treat Hydrogen as a product decision with a staffing plan, not a performance plugin.
Do the theme-tax and UX-ceiling diagnosis first. If you still need headless, phase it, keep checkout boring, and fund maintenance. If you do not need it, invest in discipline on Online Store 2.0 — metafields, sections, ruthless embeds — and measure mobile conversions.
I build both theme systems and React/Next storefronts from Karachi. I do not earn trust by always recommending the bigger rewrite. I earn it by telling you when the migration is worth it — and when it would mainly buy you a new set of problems with nicer components.
When speed is the stated reason, pair this checklist with hard numbers. Until the page speed revenue calculator is live, use field metrics and a simple conversion sensitivity table so “headless for LCP” has to beat “remove the popup.”