A holiday code freeze is an agreed period when your team ships no new features and no risky fixes, because sales and stability come first. For a shop it usually covers the weeks around Black Friday and Christmas. A date in the calendar is not enough: you need a freeze mode, work finished earlier, a definition of an emergency fix and a place for ideas that return in January.
This guide is for a small team, sometimes working with an outside agency. Testing the promotion page and preparing support have their own guides on checking your Black Friday promotion page and getting support ready for Black Friday. Here you set the rules for code and configuration changes.
Soft or hard freeze: choose the mode
A hard freeze means nobody deploys code changes, except an emergency fix approved through an agreed procedure. A soft freeze allows specific, named kinds of change, such as CMS content or prices. The choice depends on what an hour of downtime costs and how fast you can undo a change. A rehearsed, quick rollback makes a soft freeze reasonable; restoring a backup by hand calls for a hard one.
Scroll the table sideways to see all columns.
| Mode | What is allowed | When it fits |
|---|---|---|
| Hard freeze | Only an approved emergency fix | One environment and no rehearsed rollback |
| Soft freeze | Content, prices, banners and other exceptions listed in advance | A test environment and a fast return to the previous version |
| Gradual slowdown | Smaller releases with extra checks, less and less often | A few weeks before the freeze, as a transition |
The exception list in a soft freeze must be closed. "Small fixes" is a loophole for a new plugin or template change, not an exception. Be specific: banner copy, a price update, a new product photo. Everything else is an emergency fix or waits for January.
Fullstory describes three variants: a hard freeze, where developers lose deployment access; a soft freeze, an agreement not to change code with some exceptions; and the most lenient "code frost", where a team reduces changes rather than halting them. It also warns that the deadline invites rushed, weaker code. It does not say which variant suits your business: Fullstory on the pros and cons of a code freeze.
Dates and scope: what exactly you freeze
Put the start, the end and a review day in the calendar. Do not start the freeze on launch day, or the first problems will appear at peak traffic with no time for a calm fix. Below is the schedule of a fictional tea shop, as an example rather than a recommended length.
- Six weeks before
Candidate list and a sprint for the riskiest work
- One week before Black Friday
Last release, then observation only
- Peak season
Listed exceptions and emergency fixes only
- First week of January
Review of workarounds and the backlog, then the first sprint
- Theme or template code and your own scripts.
- Plugin, module and platform updates, with a separate decision on security patches.
- The purchase path: cart, shipping, payment and contact forms.
- Third-party scripts: chat, analytics, consent banner, ad pixels.
- Server, domain and redirect configuration.
- The person who approves exceptions, plus a deputy for days off.
The freeze applies to contractors too. Send your agency the dates, the scope and the approver's contact, and ask whether they pause work themselves during that period.
The pre-freeze sprint: risky work first
Use the last weeks before the freeze for work that is hardest to check and easiest to break: a new shipping option, a payment gateway switch, a rebuilt form. Each needs time for observation after release. The rule: the higher the risk, the earlier in the sprint.
- Collect candidates.List every change someone wants to "get in before the holidays", with its effect on customers and its rollback.
- Drop what can wait.If the work does not affect seasonal sales or remove a known problem, move it to January straight away.
- Order by risk.Purchase path and forms first, then content and design. End the sprint with a few release-free days for observation.
- Hand changes to support.Every released change gets a short note for the people who answer customers, before the season starts.
For a larger rebuild, protect your measurement first; the checklist is in our guide on what a website redesign breaks in measurement. Write the team note following the guide on handing a change to the support team. In Meetlead Projects a sprint has a name, a goal and dates, and on completion unfinished issues move to the backlog or the next sprint.
Emergency fix: the definition and who approves it
An emergency fix is a change without which customers cannot do something important, where waiting until January costs more than the release risk. Write the criteria down before the freeze, while nobody is under pressure from a key customer or the sales team.
- Blocked purchase pathCustomers cannot add a product, pay, choose shipping or send a form.
- Wrong customer informationThe site shows a wrong price, delivery date or terms that could mislead.
- SecurityYour platform or plugin vendor publishes a security patch, or you see an abuse attempt.
- Not an emergencyA new idea, a colour change, an extra filter or a feature request, even from a large customer.
Name one approver and a deputy, usually the owner or the sales lead. The developer assesses risk and rollback but never approves their own change, and after the release someone else walks the fixed path as a customer. To judge urgency for a bug that affects only some visitors, see how bug priority differs from severity.
What is broken: customers choosing parcel locker delivery cannot reach payment. Since when and for whom: since 10:40, on phones, two chat reports. Cost of waiting: lost orders with that delivery option. Change: restore the previous shipping module version. Rollback: return to the current version. Approver: full name of the person on the list.
Atlassian's documentation describes an emergency change as one that must be assessed and implemented as quickly as possible, skipping some workflow steps, and lets you add freeze windows to a change calendar. It describes a tool for IT departments, not a ready procedure for a small shop: Atlassian on managing changes.
Customer ideas: into the January backlog, with context
In season there are more requests too: an extra filter, another delivery option, clearer dispatch dates. The worst reply is "we'll note it" with nothing left behind. First decide whether it is a defect or a new need, using our guide on bug or feature request. A defect that blocks purchases follows the emergency criteria; an idea goes to the backlog.
A backlog entry should let you return to the case without questioning the customer again, so record the need in their words and the situation it came from. In Projects you can link the issue to the ticket, a session recording and other issues, mark similar requests as duplicates and set priority during the January review. Projects requires an account, an eligible plan and the app active on the site.
Reply honestly: "Thank you, we have logged this request for review after the season. We are not changing the website until early January, so we cannot give a decision or a date yet." Do not promise delivery just to close the conversation.
January: review and the first post-freeze sprint
Do not start January by releasing everything that waited. First review the season's emergency fixes: some were workarounds that need a proper solution. Then go through the backlog, merge duplicates and set priorities based on the number of linked tickets and the effect on sales. Only then choose the scope of the first sprint.
If an agency runs your site, January is a good time to organise how requests come in; see our guide on customer requests after a website launch. Also note whether the exception list was enough, how many emergency fixes there were and whether anyone bypassed the rules.
Questions about a code freeze
Can I change content and prices during the freeze? Yes, in a soft freeze, if those changes are on the exception list. Content can break things too, such as a link to a deleted page, so decide who checks it after publishing. A template, plugin or script change is never a content change.
Do security patches wait until January as well? Not automatically. Treat them as an emergency fix: assess the risk, prepare a rollback, get approval and walk the purchase path after installing. If the update also adds features, ask the vendor for a patch-only version.
