Black Friday is five weeks away, and the feature freeze on your calendar still has no fixed date. Before deployments stop, you need a plan for what ships now and what waits until January. A feature freeze protects revenue, but it also stops almost everything a development team normally does for four to ten weeks. This guide sets out the dates retailers actually use, the checklist to clear beforehand, and how to handle a genuine emergency once the freeze is on.
What a feature freeze actually locks down
A feature freeze is a fixed window when a team stops releasing new customer-facing changes to a live product. Teams typically set their own deployment freezes, running one to two weeks around Black Friday and another one to two weeks around Christmas and New Year. Shopify treats the two freezes as separate stages. On a normal day the company ships around 40 new versions of itself, then narrows that cadence down through a feature freeze followed by a code freeze in the weeks before BFCM. During the feature freeze stage, work continues but most user-facing features stay untouched so nothing new surprises customers. Once the code freeze starts, only critical fixes reach production.
A freeze has a real limit worth knowing before you rely on one. It does not protect a site from the release shipped in September; it only protects the version last tested, by stopping any further changes. Anything already deployed, including a change from the previous month that never saw peak traffic, stays in place through the freeze. A slow database query from October ships straight into December unless someone catches it first.
Setting your freeze and thaw dates
Salesforce's holiday preparation guide tells retailers to set a code freeze by 1 November as a safe default, and to limit changes through the start of January. A 2026 planning table built on that guidance lays out four clear stages. A feature freeze on Friday 30 October stops new customer-facing work, a full freeze on Friday 13 November locks code, configuration, tags and templates, peak week from 23 to 30 November allows exceptions only with senior sign-off, and a gradual thaw from 1 December releases the backlog in small batches.
Some vendors publish their schedule rather than leaving merchants to guess. Searchspring's 2025 freeze began on 3 November, paused publishing entirely from 17 November, held through Black Friday on 28 November and Cyber Monday on 1 December, thawed briefly for critical updates, then froze again from 19 December until normal operations resumed on 6 January. Not every company starts that early. OneSignal ran a shorter production freeze from Friday 30 October through Wednesday 4 November, with room to extend it if needed.
The checklist to clear before the freeze
Ecommerce businesses often earn 40 to 60 percent of their annual revenue in November and December alone, which is why the site needs to be in good shape well before the freeze starts. Teams usually clear high-impact projects first: site speed, site inventory, the checkout flow, gift wrapping options, value proposition messaging, and wish list or abandonment programs.
Inventory data matters most of all; it should always show real stock levels and accurate delivery timing, since nobody wants a gift that arrives after the holiday. Working backward from the freeze date beats counting weeks. Set the freeze date first, write it down, then count backward in test cycles rather than calendar weeks; the first week of November is the typical target. Between now and early November, fix the three highest-revenue pages rather than trying to touch all of them.
Handling exceptions without breaking the freeze
A change earns an exception only if it fixes something actively losing money or blocking customers, can be fully smoke-tested on production right after deployment, and has a named stakeholder willing to own the risk. Everything else, meaning new features, refactors and non-urgent fixes, waits until after peak. The cost logic behind that rule is simple. A bug shipped on 15 December, when shoppers are buying last-minute gifts, can cost a retailer triple or quadruple what the same outage would cost in July.
Not everyone agrees a blanket freeze is the right tool for every team. Quantum Metric argues that full freezes conflict with Agile and CI/CD practices, create artificial deadlines, and complicate the releases that follow. Its suggested middle ground allows low-risk HTML and CSS changes while reserving the freeze for mission-critical systems like payments, shipping and fraud detection. Tommy Tynjä, a senior engineering manager at Spotify, goes further and calls the full freeze an anti-pattern that reduces neither risk nor instability on its own.
Feature flags offer a practical middle path between these positions. They let a team decouple code deploys from feature releases, shipping code early but keeping the functionality switched off until the freeze lifts. LaunchDarkly's free Developer tier gives unlimited seats and production-ready flags across multiple environments at no cost, which covers most of what a small team needs for a staged rollout like this.
What to ship first, what can wait
Fix site speed and inventory accuracy first, since both affect every page a shopper sees during peak traffic. Set the freeze date in writing before planning anything else, then count backward in test cycles rather than weeks. Save new features, redesigns and non-urgent refactors for January, and route anything that cannot wait through a named stakeholder and a production smoke test. A short freeze that everyone actually respects beats a long one nobody follows.
