A change freeze is a period when changes to production are restricted or stopped, usually around a high-risk moment such as a holiday peak, an audit or a major migration. It lowers risk for the period and raises it afterwards unless it is run with care.
A change freeze, also called a code freeze or deployment freeze, is a defined period during which changes to a system are restricted or stopped. Teams use one around moments when a failure would cost the most: a holiday trading peak, a financial period end, an audit, or a major migration. Normal work resumes when it ends, and genuine emergencies follow a separate, recorded path.
The terms overlap, and organisations use them differently. A code freeze usually stops merging to a release branch. A deployment freeze stops releases reaching production while code may still be written. A change freeze is the widest, covering configuration and infrastructure as well. Say which one you mean, and what it covers.
When the cost of an incident in the window is much higher than the cost of delay: peak trading periods, regulatory reporting dates, a migration cut-over, or an audit window. A freeze that runs all the time stops being a freeze and becomes the delivery process.
A freeze lowers the risk of the period, and moves the risk to the end of it. Changes queue up and then ship together, in larger batches, with more dependencies between them. Plan the release after a freeze as a risky release, not a normal one.
A freeze that lives in a document is only advisory, and the pressure to ship does not read documents. When the exception path is slow or invisible, teams work around the freeze instead, and nobody can say afterwards what shipped inside it. A freeze that is checked at deploy time, with exceptions that are recorded, is a control rather than a request.
ArcRelease keeps freeze windows on the release calendar, includes a change-freeze check in every release preflight, and records any decision to ship past a failing check as a signed statement with evidence. It reads and records; it is never in the deploy path.
A code freeze usually stops merging code into a release or main branch. A change freeze is broader and covers production changes of every kind, including configuration and infrastructure. Organisations use the terms loosely, so define yours in writing.
Around periods where an incident would be unusually costly, such as holiday peaks, period-end financial close, an audit or a migration cut-over, and where the delay is acceptable. Keep it as short as the risk justifies.
Only through the exception path. A good freeze allows urgent fixes with a named approver and a recorded reason, and treats a hotfix as an emergency change that is reviewed afterwards.
Often fewer, because small, frequent, well-checked deploys carry less risk per change. Many still keep freezes for the moments that matter most, and rely on automated checks to hold them.
The backlog ships at once, in large batches with tangled dependencies, so the first release after a freeze is often the riskiest. Stage it, check the dependencies between the queued changes, and keep rollback ready.
Make it something the release process checks, not only something people remember: a freeze calendar the release checks read at deploy time, with exceptions that require a named approver and leave a record.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days