Deployment Freeze
also called Change Freeze, Code Freeze
A period during which deployments are prohibited, intended to protect a high-stakes business window.
Freezes are the most common risk control in enterprise delivery and among the least examined. The reasoning is intuitive: peak trading week, regulatory filing, year-end. Do not touch anything.
The mechanism it ignores is that risk does not pause. Changes accumulate behind the freeze, and the batch released afterwards is larger, more entangled and harder to diagnose than any of the changes would have been alone — so the freeze converts many small independent risks into one large correlated one, positioned immediately after the window it was protecting. Teams also lose the muscle memory of routine deployment precisely before they may need an emergency fix.
The defensible version is narrow and specific: freeze the systems in the blast radius of the business event, for the shortest window that matters, with a documented emergency path that is practised rather than theoretical. Everything else keeps shipping.
The stronger position, available once progressive delivery is real: replace the freeze with a tightened risk posture — smaller batches, longer bake times, canary-only, automatic rollback armed. That protects the window without building the batch.