Moving a Shopify store to Hydrogen, and what actually changes

Going headless is not a redesign. The catalogue, the checkout and the admin all stay where they are — what changes is who renders the page, and how fast.

Nukes AI

Commerce team

Headless is usually sold as a rebuild and bought as a redesign, and it is neither. The catalogue stays in Shopify, the checkout stays in Shopify, and the people running the shop keep the admin they already know. What moves is the rendering layer, and with it a set of responsibilities that used to belong to somebody else.

What stays exactly where it is

Products, variants, inventory, discounts, orders and the checkout stay in Shopify, and so does every admin screen the merchandising team already uses. Nothing about the commerce back end changes, which is why a migration described as a rebuild is mostly not one.

The storefront becomes a Next.js or Remix application that reads the same catalogue over the Storefront API and hands the shopper to the hosted checkout at the end. Everything in between is presentation, and presentation is the part that moves.

What the team takes on

The trade is control for responsibility. A theme is rendered by Shopify, on Shopify infrastructure, behind Shopify caching. A Hydrogen storefront is rendered by code you own, deployed where you choose, and its speed becomes something your team is accountable for on a Monday morning.

The theme editor is the cost

The question is not whether the site can be made faster. It is who is allowed to change the homepage on a Friday without an engineer.

This is the part that decides most migrations. A theme lets a merchandiser rearrange sections and ship a campaign unaided. Going headless removes that unless it is rebuilt, either against Shopify metaobjects or against a headless CMS, and rebuilding it is real work that is rarely in the estimate.

Where the speed comes from

The gain is not that React is quick. It is that a product page can be rendered ahead of time and served from an edge cache, then revalidated when the product changes rather than when a shopper asks for it.

product = storefront.query(PRODUCT)
cache(stale_while_revalidate)

Caching is now your problem

The cost of that is a stale page, which was not previously possible. Cache lifetimes and revalidation stop being an infrastructure detail and become a merchandising decision: how long a price may be wrong is a question somebody in the business has to answer.

Apps are the real risk

Anything installed that injects a script into the theme — reviews, bundles, subscriptions, loyalty — has no theme to inject into any more. Some vendors ship a headless SDK, some expose an API, and some exist only as a Liquid snippet.

Auditing the installed apps before anything is written is the step that most often changes the answer, because one subscription app with no headless path can cost more to replace than the migration was ever going to save.

Move it in stages

A staged migration is possible, and it is usually the right shape:

start with the product and collection templates
leave the long tail on the theme
cut over per route, once the numbers hold

Both can serve behind the same domain at once, which turns an all-or-nothing release into a series of reversible ones.

When it is not worth it

If the storefront is mostly a catalogue and the theme is fast enough, headless buys very little and costs a team. It earns its keep when the front end has to do something a theme cannot — a configurator, a bespoke search, content sourced from somewhere other than Shopify — or when page speed has become the thing holding the conversion rate down.