What actually breaks when you migrate to Shopify Horizon
Migrating to Horizon is a rebuild, not a theme swap. Some of what your store does today will not survive that rebuild without work, and the honest version of this question is worth understanding before anyone quotes you a price.
This page covers what breaks, why it breaks, and how to find out which of it applies to your store.
Why does anything break at all?
Functionality breaks during a Horizon migration because Horizon reconstructed several core storefront elements as self-contained web components, and older integrations were written against the previous markup.
On Online Store 2.0 themes like Dawn, the variant picker, product gallery, cart drawer and predictive search render as ordinary theme markup. An app or a custom script could find those elements in the page and attach itself to them. Horizon encapsulates those same elements, which means integrations that expected to reach into them no longer can.
The second reason is structural. Horizon uses a nested block architecture rather than Dawn’s section model, and there is no automatic translation between the two. Shopify did not build a one-click migration path, because one isn’t technically possible. Every custom section, template and setting has to be rebuilt or re-mapped deliberately.
Neither of these is a flaw. Encapsulated components are why a broken app can no longer take down a whole page, and nested blocks are why a merchandiser can restructure a page without a developer. But both mean a migration is real work rather than a setting change.
Which apps survive, which need re-placing, and which break outright.
Apps built on theme app extensions and app embeds generally work on Horizon without modification, because those integration patterns re-inject cleanly into any theme that supports them.
In practice this covers most of the major DTC stack and nearly all official Shopify apps. Email and messaging tools, support platforms, and most current-generation review apps fall into this category. If an app was integrated by toggling it on in your theme editor rather than by pasting code into a file, it is very likely fine.
The practical test is how the app got into your theme in the first place. Apps installed through the theme editor’s app blocks and embeds are portable. Apps installed by editing code are not.
Some apps work on Horizon but lose their placement, which means someone has to open the theme editor and put them back where they belong.
Apps in this category typically predate theme embeds, or were installed at a point when manual placement was the standard approach. Older popup and upsell tools, and review apps from earlier generations, commonly need this treatment. The functionality is intact; the position isn’t.
Manual re-embedding is inexpensive but easy to forget, and forgetting is how a store launches without its review widgets on the product page. Every app in this category belongs on a written checklist before launch, not in someone’s memory.
Three integration patterns break outright on Horizon and require either a vendor update or a custom rebuild.
- Anything that modified theme.liquid directly. Code pasted into the theme’s layout file does not travel to a new theme. Whatever it was doing stops happening.
- Anything installed through the “edit code” flow as a script injection. Custom scripts added by hand to your existing theme are, by definition, part of that theme. A new theme does not have them.
- Subscription apps still running pre-2022 integration patterns. Subscription widgets that hook into the product form and variant selection the old way do not work against encapsulated components. For subscription brands this is frequently the largest single item in a migration, because the fix is usually a version upgrade of the subscription platform itself rather than a theme change.
The awkward thing about this category is that these integrations are often the oldest and least documented parts of a store. Nobody remembers adding them, and nobody knows what happens if they disappear.
What happens to custom sections?
Custom sections do not carry across, because Horizon’s block architecture is structurally different from the section model they were built for.
Any bespoke section — a custom homepage module, a specialized product page layout, a campaign template built for a specific launch — has to be rebuilt as Horizon blocks. The functionality can be reproduced. The files cannot be copied.
Custom section count is the single biggest driver of migration effort. A store with four custom sections and a store with forty are different projects at different prices, which is why any quote given without examining the theme is guesswork.
What happens to metafields and metaobjects?
Metafields and metaobjects survive a migration, because they live in your store rather than your theme — but every reference to them has to be rebuilt.
Metafields are the most commonly missed category in a theme migration, and the reason is that nothing looks broken. A product page renders. The layout is correct. The ingredient list, the care instructions, the size chart or the certification badge is simply absent, and unless someone knows it should be there, nobody notices for weeks.
Every metafield namespace and key needs mapping to the templates that reference it, and every one of those references needs reproducing in the new build. This is a documentation problem, not a technical one, which is why it gets missed by teams that treat requirements as an afterthought.
What happens to tracking, tags and analytics?
Tracking breaks when it was installed by editing theme files, and survives when it was installed through Shopify’s own integrations or through a tag manager loaded properly.
The specific risks are custom dataLayer pushes written into theme templates, conversion pixels pasted into theme.liquid, and any event tracking that depends on particular CSS selectors or DOM structure. Selector-dependent tracking is especially fragile, because Horizon’s markup differs from Dawn’s and a selector that no longer matches fails silently.
Silent failure is the problem worth planning around. A broken tag doesn’t produce an error — it produces a gap in your data that surfaces at the end of the month when the numbers look wrong.
The way to prevent it is to record every event firing on the current store before the migration starts, then verify the new build event by event against that recording. Checking it visually in preview is not verification.
What happens to SEO and redirects?
SEO breaks during a theme migration when URL structure changes, redirects are dropped, or structured data isn’t reproduced — not because the theme changed.
Your existing redirect table needs to carry across in full. Every schema type your current theme emits — product, breadcrumb, organization, FAQ, review — needs reproducing in the new build. Any URL that changes needs a redirect, and any URL that doesn’t change needs to genuinely not change.
Like broken tracking, SEO damage is delayed. Nothing looks wrong on launch day. Traffic decline appears two to four weeks later, by which point it’s difficult to attribute and expensive to unwind.
What doesn’t break
Several things people worry about are not affected by a theme migration.
These live in Shopify, not your theme, and are untouched.
Checkout is not part of your theme. Checkout behavior, payment methods and post-purchase flows are unaffected.
The apps themselves remain installed. What changes is their integration into the storefront, not the app or its data.
All unrelated to the theme.
It does not need to be deleted. It can stay in your theme library, unpublished, indefinitely — which makes rollback a single action.
How do you find out what will break before you commit?
The only reliable way to know what breaks on your specific store is to inventory the theme and score every integration against Horizon before any work is quoted.
That means four things:
Extracted from the theme files, not recalled from memory.
Theme app extension, app embed, hardcoded snippet or script tag. The integration method predicts the migration risk more reliably than the app’s name does.
Mapped to the templates that use it.
Real templates, real states, real breakpoints — so the new build can be compared against it rather than against a checklist someone typed.
A migration quoted without this work is quoted against assumptions. The assumptions are usually optimistic, and the correction arrives as a change order in week three.
Frequently asked questions
Will my apps break if I migrate to Shopify Horizon?
Some will. Apps using theme app extensions and app embeds generally work without changes. Apps that were installed by editing theme code, and subscription apps on older integration patterns, typically break and need a vendor update or a rebuild.
Does migrating to Horizon delete my current theme?
No. Your existing theme stays in your theme library as an unpublished theme unless you delete it deliberately. Rolling back is a single action.
Do my products and orders migrate?
There is nothing to migrate. Products, collections, customers and orders live in your Shopify store, not in your theme, and are unaffected by a theme change.
Can I migrate to Horizon automatically?
No. Shopify has not built an automatic migration path, because Horizon’s nested block architecture has no direct equivalent in the section model that Dawn and other Online Store 2.0 themes use. Every custom section and template is rebuilt.
Will I lose my SEO rankings?
Not if URL structure, redirects and structured data are preserved. Traffic loss after a migration is caused by those being mishandled, not by the theme change itself.
What’s the most commonly missed thing in a Horizon migration?
Metafield references. Nothing appears broken — the page renders correctly with content simply absent — so the gap often isn’t noticed for weeks.
See where your storefront stands today.
We’ll benchmark your store against three competitors on speed, accessibility and technical SEO. Free, two minutes, and nothing to install.
If you’d rather have the answer for your specific store, the Readiness Audit is a five-day written assessment of exactly what would break and what it would cost to fix.
