OPS · PERFORMANCE · SHOPIFY PLUS · 2 AUGUST 2026 · 7 MIN READ
The pre-peak code freeze, and what it should cover
A freeze that stops everything gets broken by the first urgent request and then means nothing. Freeze the things that cannot be undone from the admin, and leave the rest open.
Freeze structural change about four weeks before your peak begins and lift it once returns volume has settled — but freeze by category, not by calendar alone. What belongs inside the freeze is anything that cannot be reversed from the admin in minutes: theme architecture, app installs and removals, integration changes, checkout customisations, API version migrations and data model changes. What should stay open is everything a merchandiser can revert without a deploy — copy, images, prices, discounts, collection ordering, theme settings. A freeze that also stops merchandising is a freeze your commercial team will overrule in week one, and a rule that gets overruled once is not a rule.
IN SHORT
- Freeze by reversibility, not by file type: the test is whether a change can be undone from the admin in minutes without a deploy.
- Start the freeze around four weeks before your peak trading period begins, not the week before, because most incidents surface under load rather than at deploy time.
- Lift the freeze after returns and exchanges have settled, not on the Tuesday after Cyber Monday — January returns volume is part of peak.
- Shopify releases a new API version on the first day of each quarter, which puts a release on 1 October, inside most retail freeze windows.
- Shopify supports each stable version for a minimum of 12 months with at least nine months of overlap, so an API migration is never genuinely urgent in November.
- Shopify documents that when a version becomes inaccessible a request falls forward to the oldest accessible stable version, which is a silent behaviour change rather than an error.
- Write the exception process before the freeze starts, because the exception you have not planned is the one that gets waved through at 11pm.
Freeze by reversibility, not by category
The usual freeze policy is written as a list of forbidden activities, which is why it fails. Somebody needs a landing page, the page is technically a theme change, the freeze says no theme changes, and within a week the freeze has an unwritten list of exceptions that nobody agreed to.
The question that actually predicts risk is simpler: if this goes wrong at peak volume, how long does it take to undo, and who can do it? Sort your changes by that answer and the freeze writes itself.
A discount that turns out to be too generous is switched off in the admin in under a minute by whoever noticed. A theme setting that reveals a broken layout is unticked by a merchandiser. Those things do not need freezing, and freezing them costs you revenue for no risk reduction.
An app removed from the store, an integration repointed, a theme architecture change, a checkout customisation — each of those needs a developer, a deploy and in some cases a vendor, and the mean time to undo is measured in hours. Those are the freeze.
What goes inside the freeze
The list is shorter than most policies make it, and every item earns its place by being slow to reverse:
- App installs and removals. An app removal touches the theme, the order path, or both, and the failure often does not appear until a real order flows through it.
- Theme architecture. Section schemas, template structure, anything that changes the shape of settings a merchandiser relies on. New sections built additively and left disabled are a different matter — see below.
- Integration changes. Anything that touches the path an order takes to your ERP, WMS, 3PL or accounting system. These fail asymmetrically: the storefront looks fine and the orders quietly stop arriving.
- Checkout customisations. Highest revenue exposure per line of code on the whole site, and the hardest place to test under real conditions.
- API version migrations. Shopify releases a new version on the first day of each quarter, which means one lands on 1 October. Support is a minimum of 12 months with at least nine months of overlap, so nothing about a migration is urgent enough to do in November.
- Data model changes. Metafield definitions, metaobject schemas, product taxonomy. A rename is a small commit and a large blast radius.
- Anything requiring a third party to also be ready. If undoing your change depends on a vendor answering a support ticket, your rollback time is their SLA.
What should stay open, deliberately
The freeze exists so the store can trade. A policy that prevents trading has misunderstood itself. These stay open, and it is worth saying so explicitly in the policy rather than leaving it to be inferred:
- Prices, discounts, promotions and their scheduling.
- Copy, images, banners and anything set through a theme setting.
- Collection membership, sort order and merchandising rules.
- Inventory and availability, including hiding a product that has sold through.
- Content published through metaobjects, where the template already exists.
- New sections built additively and shipped disabled before the freeze starts, then enabled during it by a merchandiser — the code change happened in open season and the switch is a setting.
The exception process, written down in advance
Every freeze has exceptions. The difference between a functioning freeze and a decorative one is whether the exceptions were designed or improvised.
Three things need to exist before the freeze starts. A named person who can approve an exception — one person, not a committee, and a deputy for when they are asleep. A written bar for what qualifies — our default is that an exception must fix a revenue-affecting defect, not enable an opportunity, because "we could make more money if we shipped this" is an argument that is always available and always compelling. And a rollback plan attached to the exception itself, stating who reverts it, how, and what evidence triggers the decision.
The last one is the one that gets skipped, and it is the one that matters at 11pm when a change has gone out, something looks wrong, and the person who wrote it is not answering. An exception without a written rollback is not an exception; it is a deploy with extra paperwork.
Freezing is not the same as stopping
The freeze is a change in what ships, not a change in what the team does. Two months of a frozen storefront is two months of the most valuable observation window you will get all year, and teams that treat the freeze as downtime waste it.
What the time is for: watching. Error rates on integrations, checkout completion by device, the specific pages that slow down when traffic triples, the support queue by reason code, and the orders that needed manual intervention. All of that is evidence, it is only available under load, and by February nobody will be able to reconstruct it.
It is also the right time to prepare the work that lands the moment the freeze lifts. Branches built, reviewed and tested against a copy of the live theme, ready to ship in the first week of open season rather than the fourth. The teams who come out of peak fastest are the ones who spent the freeze with their hands off the deploy button and their eyes on the dashboards.
When to lift it
Later than most people do. The instinct is to reopen the moment the sales event ends, and that is roughly the worst moment available: order volume has peaked but fulfilment, delivery exceptions and the support queue are still working through it, and returns have not started.
A more honest boundary is when returns and exchanges have settled back to normal volume, which for most retailers means well into January. Until then the order path is still under unusual pressure — and the returns and exchange flow is the part of the order path least likely to have been load-tested, because nobody rehearses January.
One exception worth making: if a defect surfaced during peak that is costing revenue every day, fix it during the freeze under the exception process. A freeze is a risk management tool, not a penance.
The honest position
Most stores do not need a longer freeze. They need a shorter one that is actually observed, and ten months of the year spent making more of their changes reversible from the admin.
That is the real work, and it is not glamorous: moving hard-coded values into theme settings, replacing script-injecting apps with theme app extensions merchants can disable, building sections that ship disabled, and getting the integration monitoring in place so a problem announces itself rather than being discovered in a reconciliation. Every one of those shrinks the set of changes that need freezing at all, which is a better outcome than a stricter policy.
If you are reading this with peak approaching and none of that done, freeze the seven categories above, write the exception process this week, and put the rest on the list for January. The freeze will hold for one season. The list is what stops you needing the same conversation next year.
Questions this raises
When should an ecommerce code freeze start?
About four weeks before your peak trading period begins. The gap matters because most peak incidents surface under load rather than at deploy time, so a change made a week out has not yet been tested by the traffic that will break it. If your peak starts with early promotions in early November, count backwards from that, not from Black Friday.
What should a code freeze actually cover?
Anything that cannot be reversed from the admin in minutes without a deploy: app installs and removals, theme architecture, integration changes, checkout customisations, API version migrations, data model changes, and anything whose rollback depends on a third party. Merchandising — prices, copy, discounts, collections, theme settings — should stay open.
Can we still publish landing pages during a freeze?
Yes, and a policy that says otherwise will be ignored. If the sections a landing page needs already exist, building the page is merchandising and a merchandiser can revert it. The prerequisite is having shipped those sections before the freeze — which is a reason to build the section library in spring rather than a reason to freeze pages in November.
Should we migrate API versions before peak?
No. Shopify releases a version on the first day of each quarter, so one lands on 1 October, and each stable version is supported for a minimum of 12 months with at least nine months of overlap between consecutive versions. That overlap is deliberately long enough that no migration is ever urgent in Q4. Do it in Q1.
What happens if an integration is left on an unsupported API version?
Shopify documents that when a version becomes inaccessible, requests fall forward and are answered using the oldest accessible stable version. That is worth understanding precisely: your integration does not fail loudly, it starts receiving different behaviour. Audit which version each integration pins well before peak, because this is a silent failure mode.
When should the freeze be lifted?
When returns and exchanges are back to normal volume, which is usually well into January rather than the week after Cyber Monday. Fulfilment exceptions, support volume and the returns flow all keep the order path under pressure after the sales stop, and the returns path is the part least likely to have been rehearsed.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.