Change Freeze: How to Run a Freeze Period That Holds

A change freeze is a designated period during which changes to a system, an environment or a service are not permitted, or are permitted only with extra approval. Organisations use freezes to protect stability at moments when a failure would cost the most, and when the staff who could repair it are least available.

The idea is simple. The difficulty is in the details: what exactly is frozen, for whom, for how long, and what counts as an emergency. A freeze that is vague is argued about on the day, and a freeze that is easy to bypass is ignored.

When a freeze is justified

Freezes are best tied to predictable events whose cost of failure is high.

• Financial period ends, such as a year-end or quarter-end close, when finance systems must be stable.
• Peak trading or usage periods, for example a retail sales season or a registration deadline.
• Holiday periods when few engineers are available to respond.
• Major customer or public events, such as a launch, a conference or an audit.
• Periods of known instability, when an environment is already under investigation.

Define the scope precisely

State what is frozen. A freeze on Production deployments is a different policy from a freeze on all changes everywhere. Many teams freeze Production releases but allow work to continue in development and staging, so that the backlog of ready work does not become a flood when the freeze ends.

State the dates and the times, with a time zone. State which environments and which services are covered. Give the freeze a name and a reason that a newcomer would understand, because a freeze with no reason invites exceptions.

Atlas freeze windows carry exactly these fields: a start, an end, the environments covered and a reason. While one that covers Production is active, releasing to Production is refused and every open release shows the freeze as a blocker.

Plan for the work that piles up

A freeze does not remove the demand to ship. It defers it. The risk is a large number of changes released together on the first day after the freeze, which recreates the instability the freeze avoided. Plan the thaw: stagger releases over several days, release the lowest-risk changes first and keep a smaller number of changes per release.

Work done during the freeze can still reach the Ready state. A release that is complete and waiting for the freeze to end is a healthy outcome, and the calendar view of target days and freeze windows shows where the queue will fall.

Handle emergencies deliberately

A freeze needs an exception path, and the path must be harder than the normal one. Typical criteria are a defect that is causing material harm to customers, a security vulnerability under active exploitation, or a legal or regulatory obligation with a deadline. Convenience and schedule pressure are not emergencies.

Name who can approve an exception, require a written reason and require a rollback plan. The exception should be recorded with the release so that the next review can see how often the freeze was breached. In Atlas, only a workspace owner or administrator can release past a blocker, and they must record a reason of up to 500 characters, so every override is attributed and visible.

Communicate the calendar early

Publish freeze dates well before they begin. Teams plan their work around the calendar, and a freeze announced in the week before it starts forces them to rush changes out, which is the opposite of the intention. Place freeze windows where the team already looks, such as the release calendar, rather than in a document few people open.

Review each freeze

After the period ends, ask three questions. Were there incidents during the freeze, and were they related to older changes or to exceptions? How many exceptions were granted, and were they justified? What happened in the days after the thaw? The answers show whether the freeze is worth its cost and whether its scope was right.