Horizon migration for subscription brands
Subscription programs are the single most common source of unexpected work in a Horizon migration.
The reason is structural rather than incidental, and it’s worth understanding before anyone quotes you a fixed price — because for a subscription brand, the theme rebuild is often the smaller half of the project.
What’s different about migrating a subscription store?
Subscription programs are more exposed to a theme migration than almost any other category of app, because subscription widgets attach directly to the product form.
A subscription selector has to sit inside the purchase flow. It reads variant selection, modifies what gets added to the cart, changes displayed pricing, and persists a selling plan through to checkout. That’s a deep integration with exactly the parts of a theme that Horizon rebuilt as self-contained web components.
By contrast, a reviews widget or an email capture form sits alongside the purchase flow rather than inside it. Those port far more easily.
The practical consequence: a subscription brand’s migration scope is driven at least as much by its subscription platform as by its theme.
Which subscription apps work on Horizon?
Subscription platforms running current integration patterns generally work on Horizon. Platforms still running older integration patterns generally do not.
The determining factor is not which vendor you use — it’s which version and which integration approach your store is on. A store running a current release of a major subscription platform is usually in reasonable shape. A store that integrated the same platform four years ago and hasn’t upgraded since is frequently not, even though the vendor’s current product supports Horizon perfectly well.
This catches people out, because the question “does my subscription app work on Horizon” gets answered by checking the vendor’s documentation, which describes their current version rather than the one installed on your store.
The question worth asking is: which version of the integration are we actually running, and when was it last updated?
What breaks, and why?
Three specific things break for subscription brands, and each has a different remedy.
Older integrations reach into the product form and variant picker directly, which no longer works when those elements are encapsulated. The remedy is a version upgrade from the vendor, not a theme workaround.
Most subscription brands have customized how the selector looks and where it appears — moving it above the add-to-cart button, restyling the frequency options, adding explanatory copy. That customization lives in the theme and does not carry across. It has to be rebuilt.
Rules governing which products offer subscriptions, at what discount, on what frequencies, are often implemented partly in theme code using product tags or metafields. That logic is theme-side and needs reproducing, and it’s frequently undocumented because it was built incrementally.
That third item is where most of the surprise lives. The widget breaking is visible immediately. Eligibility logic that silently stops applying to one product type is not.
What happens to the customer portal?
The subscription customer portal is usually unaffected by a theme migration, because most modern subscription platforms host it themselves.
Where the portal is embedded into your storefront using theme templates, that embed needs rebuilding. Where it’s hosted by the vendor and linked from your account pages, only the link and the surrounding page need attention.
Either way, the portal deserves explicit testing before launch. It’s outside the main purchase flow, which means it’s routinely forgotten during QA and discovered by a customer.
Should you upgrade your subscription app at the same time?
Migrating to Horizon is frequently the forcing event that gets a store onto a current version of its subscription platform, and doing both together usually costs less than doing them separately.
The argument for combining them is that both projects touch the same code and require the same testing. Doing them in one window means one round of QA on the purchase flow rather than two, and one launch risk rather than two.
The argument against is concentration of risk. Two significant changes to the revenue-critical part of your store, landing together, means a problem is harder to isolate.
A reasonable middle path: upgrade the subscription integration first, on the existing theme, confirm it’s stable, then migrate. That sequence costs more time and less risk, and for a brand where subscriptions are a large share of revenue it’s usually the right trade.
How should you sequence the two projects?
| Sequence | Best for | Trade-off |
|---|---|---|
| Subscription upgrade first, then migrate | Brands where subscriptions are a large revenue share | Longest, lowest risk |
| Both together in one window | Brands with modest subscription volume, or a subscription platform already current | Fastest, concentrated risk |
| Migrate first, upgrade later | Rarely correct | Means building against an integration you’re about to replace |
The third option is worth naming specifically so it can be ruled out. Migrating onto a subscription integration you already know needs replacing means doing the purchase-flow work twice.
What should you find out before committing?
Four things determine a subscription brand’s migration scope, and all four can be established before signing anything.
- Which version of your subscription integration is installed, and whether the vendor supports Horizon on that version
- What theme-side customization exists around the selector — placement, styling, copy, layout changes
- Where eligibility logic lives — which rules are configured in the subscription platform and which are implemented in theme code
- Whether the customer portal is embedded or hosted, and what surrounds it
An agency quoting a subscription store without answering those four is quoting against assumptions.
How we document current state → · Which app integrations break on Horizon →
Frequently asked questions
Do subscription apps work on Shopify Horizon?
Subscription platforms on current integration patterns generally work. Older integrations, particularly those that attach directly to the product form and variant picker, frequently break because Horizon renders those elements as self-contained web components.
Will my subscription widget break if I migrate to Horizon?
It depends on which version of the integration your store is running rather than on which vendor you use. A store on a current release is usually fine; a store running an integration installed several years ago frequently is not.
Does my subscription customer portal survive a theme migration?
Usually. Most subscription platforms host the portal themselves, so a theme change doesn’t affect it. If your portal is embedded using theme templates, that embed needs rebuilding.
Should I upgrade my subscription app before or during a Horizon migration?
For brands where subscriptions are a large share of revenue, upgrading first on the existing theme and confirming stability before migrating is the lower-risk sequence. Combining them is faster but concentrates the risk on the revenue-critical part of the store.
What’s the most commonly missed item for subscription brands?
Conditional eligibility logic implemented in theme code — the rules governing which products offer subscriptions, at what discount and on what frequencies. Unlike a broken widget, eligibility logic fails silently.
Find out what your subscription program actually needs.
A five-day Readiness Audit establishes which integration version you’re on, what theme-side customization exists, where your eligibility logic lives, and what the whole project would cost. $2,500, credited in full against the migration.
We’ve built subscription commerce for AG1, Four Sigmatic and Dollar Shave Club, among others.
