Horizon vs. Dawn vs. Custom Theme: A Decision Framework for Plus Brands

Horizon is Shopify's current theme architecture, built around expanded sections/blocks and deeper metaobject support. Dawn was the previous default. A custom theme remains an option for brands with requirements neither foundation meets natively. The right choice depends on how much native flexibility you need versus how much bespoke functionality you're building regardless. Here's the framework.

Last verified: September 6, 2026.

This page is the three-way build decision, including when a fully custom theme is still the right call. For the deep technical comparison of Dawn and Horizon specifically — architecture, editor capability, app compatibility, and whether Dawn is being discontinued — see Dawn vs Horizon.

The Three Options

Decision Framework

Choose Horizon if: you're doing a new build or a re-theme for other reasons anyway, and your customization needs — while real — can be met through Horizon's expanded native flexibility (sections, blocks, metaobjects) rather than requiring custom code for most of the experience. This describes the large majority of enterprise Plus brands evaluating a theme decision in 2026.

Stay on Dawn if: your current theme is stable, isn't causing performance or maintenance problems, and there's no re-theme already planned for other business reasons. There's no forced migration date pushing existing Dawn-based stores off it, and a stable, working theme is not a good candidate for change purely for change's sake.

Go custom if: your requirements genuinely exceed what Horizon's native flexibility supports — highly bespoke interactive experiences, non-standard commerce flows, or design requirements that would fight against any theme's block-based architecture regardless of which one you started from. This is a smaller set of brands than commonly assumed; test against Horizon's actual capabilities before concluding you're in this category.

What Migrating Between Them Actually Looks Like

Dawn to Horizon is comparable in scope to a standard re-theme — content and product data carry over, but templates, sections, and any custom theme code need to be rebuilt against Horizon's architecture. The scope depends heavily on how customized the existing Dawn implementation was: a largely stock Dawn build migrates faster than one with significant custom sections and logic layered on top.

Custom theme to Horizon is a bigger undertaking, since it typically means evaluating which custom functionality can be retired in favor of Horizon's native capabilities, and rebuilding only what genuinely still requires custom work. This is often a net simplification — a meaningful share of what justified custom development against Dawn doesn't require the same custom work against Horizon's expanded native flexibility — but the audit process to determine what can be retired takes real time.

Horizon to custom is the reverse scenario, appropriate only when a specific requirement has been clearly identified as exceeding Horizon's capabilities after genuine evaluation, rather than assumed upfront.

Cost and Timeline Expectations

A Horizon-based new build or re-theme, for a brand without unusual requirements, is comparable in cost and timeline to a standard Dawn-based build was previously — Horizon isn't inherently more expensive to build on, and its expanded native flexibility can reduce the custom development that would otherwise be needed. A custom theme build, by contrast, scales with genuine custom scope and is the most expensive and longest-timeline option of the three by a meaningful margin, since every piece of functionality is bespoke rather than starting from a native foundation.

The Mistake We See Most Often

Choosing custom by default because “we have complex needs,” without first testing whether Horizon's expanded native flexibility actually falls short. Horizon covers meaningfully more ground natively than Dawn did — a requirement that needed custom code under Dawn may not need it under Horizon. Test against Horizon's actual capabilities before assuming custom is necessary; it's a more expensive and higher-maintenance path that should be earned by genuine requirement, not assumed by habit or by a requirements list written years ago against Dawn's more limited flexibility.

If You're Already Planning a Re-Theme

This is the natural decision point — evaluate against Horizon now rather than defaulting to whatever your last theme foundation was. A re-theme is already disruptive to the business in a planned, budgeted way; that's the right moment to also ask whether the underlying architecture should change, rather than treating the theme foundation as a fixed constant and only redesigning what sits on top of it. → For the Horizon migration process itself, cost, and what changes, see Migrating to Shopify Horizon.

Worked Scenario: Three Brands, Three Answers

A DTC apparel brand with a stable, largely-stock Dawn theme, no performance issues, no re-theme planned. Stay on Dawn. There's no forced date and no problem to solve — migrating here would be change for its own sake.

A subscription brand planning a rebrand and new collection-page layout over the next two quarters. Evaluate against Horizon as part of that project rather than rebuilding on Dawn again. The re-theme is happening regardless; the only question is which foundation it's built on.

An enterprise brand with a heavily customized Dawn theme carrying years of accumulated custom sections, some of which are now duplicating functionality Horizon supports natively. Worth a genuine audit before deciding — this is exactly the profile where migrating to Horizon can result in a net reduction in custom code, since some of what justified custom work under Dawn may not need it under Horizon's expanded native flexibility.

A Note on Theme Customization Skill Requirements

Horizon's expanded sections-and-blocks model and metaobject support generally means less need for a developer to hand-code custom functionality — more of what used to require custom Liquid or JavaScript can be configured through the native block system. This has a practical staffing implication: teams evaluating a Horizon migration should factor in that some of the ongoing maintenance burden may shift from developer time to a merchandiser or content-team member configuring native blocks, which is a different (and often less expensive) resourcing model than a heavily custom Dawn theme required.

Frequently Asked Questions

Is Horizon better than Dawn?

Horizon offers more native flexibility through expanded sections, blocks, and metaobject support. Dawn remains a solid foundation for stores with no pressing reason to move — there's no forced migration date for existing Dawn-based stores.

Do I need a custom theme for complex requirements?

Not necessarily — test against Horizon's expanded native flexibility first. Many requirements that needed custom code under Dawn are natively supported under Horizon, which shrinks the set of brands that genuinely need a custom build.

Should I migrate to Horizon if my current theme works fine?

Not urgently — there's no forced cutover date. The natural time to evaluate Horizon is when you're already planning a re-theme for other reasons, since a re-theme is already a planned disruption.

How much does migrating from Dawn to Horizon typically cost compared to a standard re-theme?

Comparable, for a brand without unusual requirements — Horizon isn't inherently more expensive to build on than Dawn was, and its native flexibility can reduce custom development that would otherwise be needed.

Does moving to Horizon change who can maintain the theme day to day?

Often yes, in a positive direction — Horizon's expanded native block system means more customization can be configured by a merchandiser or content-team member rather than requiring developer time, compared to a heavily custom Dawn theme.

We have a heavily customized Dawn theme — will migrating to Horizon actually reduce our custom code?

Possibly, and it's worth a genuine audit rather than assuming either way. Some functionality that required custom development under Dawn is natively supported under Horizon's expanded flexibility, which can be a net simplification once the audit identifies what can be retired.