Can you migrate to Horizon during a code freeze?

Yes — a freeze prohibits publishing, not working.

A Shopify theme migration is one of the few substantial projects that can run through a retail code freeze, because the entire build happens on an unpublished duplicate theme and never touches the live store.

Most brands write off eight to ten weeks a year to freeze. Understanding what a freeze actually prohibits is usually enough to recover most of that time.

What is a retail code freeze, and what does it actually prohibit?

A retail code freeze is a period, usually spanning the peak trading season, during which a business stops deploying changes to its live storefront in order to protect revenue at the moment it matters most.

The rationale is sound. Peak trading concentrates a disproportionate share of annual revenue into a few weeks, and a bug introduced in that window costs far more than the same bug in March. Freezing deployment removes a category of risk at a time when the business has the least capacity to absorb it.

What a freeze prohibits, precisely, is changing what customers experience on the live storefront. It is not a prohibition on work. It is a prohibition on publishing.

That distinction is where the recoverable time is.

Why can a theme migration run through a freeze?

A theme migration can run during a freeze because Shopify allows an unlimited number of unpublished themes, and work on an unpublished theme has no effect whatsoever on the live storefront.

The sequence works like this. Horizon is added to the theme library as an unpublished theme. The build happens there. Your team reviews it in a preview environment. Nothing customers can see changes at any point during that process.

Publishing is a single action, taken at a moment you choose — which can be well after the freeze has lifted. The build and the publish are separate events, and only the second one is what a freeze exists to prevent.

This is genuinely different from most projects that get deferred to freeze. A checkout change, a new app, a pricing update or an infrastructure migration all touch production by their nature. A theme rebuild doesn’t.

What has to happen before the freeze starts?

The requirements phase has to be complete and signed off before the freeze begins, because it’s the one part of a migration that needs real attention from your team.

Requirements involve documenting exactly what your current storefront does, then having your team confirm it, correct it, and add the business rules that exist only in people’s heads. That takes a working session and a sign-off — a day or two if the store has already been assessed, longer if it hasn’t.

Attempting that conversation during peak trading does not work. Your ecommerce lead is not going to give two focused hours to a requirements review in the third week of November, and they shouldn’t be asked to.

More on which phases need your time →

What can’t happen during a freeze?

Three things in a migration need to sit outside the freeze window, and planning around them is what makes the rest work.

  • Requirements sign-off, for the reasons above. Before the freeze.
  • Publishing, obviously. After the freeze lifts.
  • Anything touching a system the freeze covers. If a migration requires a subscription platform version upgrade, a tag manager change, or an app reinstall on the live store, those are production changes and they belong outside the window. This is worth checking early, because it’s the most common reason a freeze-window migration turns out not to be one.

The sandbox review sits in a middle category. It doesn’t touch production, but it does need a few hours of your team’s attention. Early December, once the worst of peak has passed, is usually the practical slot.

When not to

When would this be a bad idea?

Three situations make a freeze-window migration the wrong call, and it’s worth being honest about them.

×
Your organization freezes bandwidth, not just code.

Some businesses have a blanket rule that no vendor projects run in Q4, regardless of production risk. That’s a legitimate operational choice and arguing with it wastes everyone’s time. January is the better window.

×
Your team genuinely has no capacity for requirements before the freeze.

If the pre-freeze weeks are already consumed by campaign preparation, the requirements session will be rushed, and a rushed specification produces a disappointing build no matter who does the work.

×
The migration depends on a production change.

If an app upgrade or a tag manager change has to happen first, and those are frozen, the project stalls halfway. Find this out during assessment rather than in week two.

What does the timeline look like working backward from January?

Working backward from a first-week-of-January launch, the sequence runs like this.

MilestoneTiming
Assessment and contractingSeptember to mid-October
Requirements sign-off — needs your teamMid to late October
Code freeze beginsEarly November
Build and reports — minimal team involvementNovember
Sandbox review — needs your teamEarly to mid December
Freeze liftsEarly January
PublishFirst week of January
Training and handoverJanuary

The binding constraint is the requirements session landing before the freeze. Working back from there, the practical deadline for starting an assessment is around the beginning of October.

What’s the argument for doing it this way?

The argument is that you recover a quarter of the year and come out of freeze on new footing rather than starting from where you left off.

A brand that starts planning a migration in January is typically live in late February or March, having spent the freeze period doing nothing on it. A brand that starts in October is live in the first week of January and spends the rest of Q1 using the thing rather than building it.

The work is the same. The difference is whether it happens during the weeks the business had already written off, or during the weeks it wanted to be shipping.

Should you migrate at all? The honest version →

Frequently asked questions

Can you change your Shopify theme during a code freeze?

You can build a new theme during a freeze, because the work happens on an unpublished theme that doesn’t affect the live storefront. Publishing it is a production change and normally waits until the freeze lifts.

What does a code freeze actually prohibit?

A code freeze prohibits changing what customers experience on the live storefront during peak trading. It doesn’t prohibit work — it prohibits deploying.

Does a Shopify theme migration take the site offline?

No. The build runs on an unpublished duplicate theme. The live store is unaffected until you publish, which is a single action taken at a time you choose.

When should we start if we want to be live in January?

Assessment and contracting from September to mid-October, with requirements sign-off completed before the freeze begins in early November. That makes early October the practical deadline for starting.

What if our company freezes all vendor work in Q4?

Then a freeze-window migration isn’t the right fit, and January is the better start. That’s an operational policy rather than a technical constraint, and it’s worth confirming early rather than midway through planning.

Find out whether your store is a candidate before the window closes.

Five days, a written assessment: what you have, what would break, what you’d gain, and whether a freeze-window migration makes sense for you. $2,500, credited in full against the migration.

Book a Readiness Audit

The fixed-price migration runs four weeks from requirements sign-off, which is what makes the January date reachable.