Failure stays small
A template that underperforms is rolled back on its own, without touching the routes that are working.
NO DATA MOVES
Moving a Liquid theme to a headless front end
A headless migration replaces the rendering layer while Shopify keeps the catalogue, cart, checkout and orders. That makes it lower risk than a replatform — no data moves — but it is not low risk: URLs, structured data, analytics and every piece of merchandising tooling your team uses are all rendered by the layer being replaced, so each one has to be deliberately carried across.
IN SHORT
- A headless migration replaces the rendering layer only: Shopify keeps catalogue, cart, checkout and orders, so no data moves.
- The risk is not data loss. It is that canonicals, structured data, pagination and hreflang came free with Liquid and do not come free after.
- Every app that works by injecting a script into the theme stops working on cutover day.
- Migrating route by route is safer and reversible, and a permanently partial site is a legitimate destination.
- Rankings hold when the markup is rebuilt deliberately, because URLs and content have not changed.
This is not a replatform
Headless migration
Replacing the layer that renders pages while the commerce platform underneath stays exactly where it is. A platform migration moves products, customers and order history between systems. A headless migration moves none of that — which makes it safer, and makes people underestimate it.
What survives cutover, and what does not
| Survives | Must be rebuilt | |
|---|---|---|
| Products, customers, orders | Untouched in Shopify | — |
| Checkout and payments | Stays on Shopify | — |
| URLs | Yours to preserve, and you should | Only if you choose to change them |
| Canonicals and structured data | — | Liquid emitted these; the front end will not |
| Theme editor pages | — | Rebuilt in a CMS |
| Script-injected apps | — | Replaced, integrated by API, or dropped |
How we run the migration
- 01
Inventory what earns traffic
Pull the URLs that actually receive search and revenue from Search Console and analytics, not from the sitemap. The migration gets measured against those pages, and nothing else.
- 02
Audit the app layer
Every app listed, and each one classed as API-capable, replaceable or dropped. Reviews, popups, personalisation and most analytics tools are script injections with nothing to inject into after cutover.
- 03
Rebuild the invisible markup
Canonicals, product and breadcrumb structured data, pagination signals, hreflang and robots directives. Liquid emitted these automatically; the new front end emits nothing until it is told to.
- 04
Port the merchandising surface
Whatever your team used the theme editor for now has to exist in a CMS. If this stage is skipped, the site launches and marketing quietly stops shipping.
- 05
Cut over by route
Lowest-risk template first, highest-value template last, each behind a switch that can be reversed alone. A bad product template should never require rolling back the whole site.
- 06
Watch the right numbers
Indexation, Core Web Vitals and revenue per template, compared against the pre-migration baseline for at least one full crawl cycle before the next route moves.
Why route-by-route
Evidence before commitment
The first migrated template tells you whether the benefit is real before the rest of the budget is spent.
Stopping is allowed
If the gain does not appear, a partially headless site is a fine place to stop rather than a failed project.
Search risk is contained
One template at a time means one crawl cycle to verify, not a whole site’s indexation in the air at once.
The pre-flight checklist
- Baseline captured: indexation, Core Web Vitals and revenue per template, before anything moves.
- Every app classified — API-capable, replaceable, or dropped — with the cost of each replacement priced.
- Structured data and canonical output specified as acceptance criteria, not left to whoever builds the template.
- CMS live and the content team trained before the first route cuts over, not after.
- A named rollback switch per route, tested once in staging so nobody is learning it during an incident.
Migrations we have run
Our migration experience is platform migration rather than headless: Trunki and Big Shoes off Magento, Chicco off Salesforce Commerce Cloud, Dekoni Audio off WooCommerce. The discipline is the one that matters here — URL inventories taken from real search data, redirects mapped before launch, indexation watched afterwards — and it transfers directly to a front-end migration, where the same markup has to be recreated by hand.
Who we have done this for
Clients from the roster whose work this page describes. Each links to what we actually built.
Trunki
Trunki moved from Magento to Shopify Plus, with a configurator for the custom, one-off ride-on designs the brand is known for. We have managed the store since.
Chicco
Chicco moved off Salesforce Commerce Cloud onto Shopify. The same team has handled landing pages and maintenance since launch.
Headless migration questions
Will a headless migration hurt our SEO?
It can, and the cause is almost always the same: markup that Liquid produced automatically — canonicals, product structured data, pagination — is simply absent in the new front end. Rebuilt deliberately, rankings hold, because the URLs and the content have not changed.
What happens to our apps?
Any app that works by injecting a script tag into your theme stops working on the day you go headless. Reviews, popups, personalisation and most analytics tools fall into this group. Audit them before the project starts — the replacements sometimes cost more than the migration.
Can we migrate one page type at a time?
Usually, and it is the safer plan. Serving product pages from a headless front end while collections stay on Liquid is entirely workable if the two are treated as one site for analytics and internal linking. It also lets you stop if the benefit does not materialise.
Does a headless migration move our data?
No. Products, customers, orders and inventory stay in Shopify throughout — that is what makes this different from a replatform. Only the layer that renders pages is replaced, which removes the entire category of data-loss risk and leaves a presentation-layer risk instead.
How long does a headless migration take?
It depends almost entirely on how many templates move and how many apps need replacing, not on catalogue size. A single high-value template can move in weeks; a whole storefront with a CMS migration and a dozen app replacements is a multi-month programme.
Can we roll back?
If you migrate route by route, yes — the Liquid theme is still there and still serving the routes you have not moved. Cutting the whole site over at once removes that option, which is the main argument against doing it that way.
Related
Hydrogen & Oxygen Builds
Shopify’s own React framework and hosting — the shortest path to headless that keeps you inside supported territory.
Storefront API Front Ends
A custom front end on Next.js or your existing stack, reading catalogue and cart from the Storefront API.
Headless CMS Integration
Editorial content in Sanity or Contentful, product data in Shopify, composed into one front end without either team blocking the other.
NEXT STEP
Free store audit
Most stores that ask about headless have a theme or app problem instead. A senior engineer will tell you which one you have, at no cost.