Change freeze: useful for a fortnight, harmful for a quarter

A change freeze is a defined period during which changes to production systems are not permitted, imposed around a time when failure would be unusually costly: a retail peak, a financial close, a migration, a major public event. It is one of the oldest operational controls and one of the least examined.

Its logic is sound over short periods. If nothing changes, nothing new breaks, and the team can focus on running the system rather than altering it. What is less often acknowledged is that a freeze does not reduce the amount of change — it batches it. Everything held back arrives together the day the freeze lifts, in the single largest and least individually reviewed release of the period.

Making a change freeze work

• Announce it early, with exact start and end times and time zones, so teams plan around it rather than discovering it.
• Define what is frozen: application deploys, infrastructure, configuration, data changes, third-party updates, certificate rotations. Ambiguity here produces arguments during the freeze.
• State what is explicitly allowed — security patches at a stated severity, incident remediation, and anything needed to keep the service running.
• Publish the exception route: who approves, how quickly, and what evidence is needed. An exception process that takes a day is a freeze without exceptions.
• Plan the unfreeze: stagger what ships afterwards rather than releasing everything at once, and put extra monitoring around the first days.

The things that expire during a freeze

Freezes catch out teams on scheduled work that is not a change in the ordinary sense: certificates due for renewal, credentials due for rotation, licences that lapse, scheduled maintenance the provider will perform whether or not you have frozen. Check the calendar for those before setting the window, and grant explicit exceptions in advance rather than discovering an expiry at two in the morning during the period you were protecting.

Long freezes are usually a symptom. A team that cannot ship safely during its busiest period is describing a deployment process it does not trust, and the durable fix is smaller, reversible, better-monitored releases rather than longer periods of prohibition.

Communicate outward, not only inward

Customers, partners and internal stakeholders plan around your release schedule more than teams expect. A freeze that blocks a customer-committed fix for six weeks is a commercial decision, not an operational one, and it should be made with the people who own those commitments. Publishing the freeze calendar in advance also prevents the recurring conversation where sales has promised delivery inside a window nobody told them about.

Keeping the calendar and the exceptions

Ettex Docs holds the freeze policy with its scope and exception route, version-controlled so what applied during a given period is recoverable; Ettex Records keeps the exceptions granted with their justification; and the body that normally authorises changes is covered in change advisory board.

Plainly: this is documents and records, not a deployment platform. Enforcement belongs in the pipeline; what this covers is defining the freeze precisely enough that people can follow it and honestly enough that it does not simply relocate the risk.