Every organization I have worked in observed some version of a change freeze. The logic is straightforward: a peak trading window is coming, a product launch is imminent, the holiday season starts in two weeks, so you lock the environment and hold your breath.
The assumption underneath that decision is that the environment is stable and that stability is what you are protecting. That assumption is often wrong before the freeze begins.
Here is what a freeze actually does. It stops deliberate, reviewed, scheduled change. It does not stop the environment from drifting. Certificate expirations do not check the change calendar. License limits do not pause. A dependency that was quietly degrading before the freeze continues degrading during it. Vendor-pushed updates to shared infrastructure do not always wait for your release window to reopen. The freeze gives you the feeling of a stable surface while the substrate underneath keeps moving.
The second thing a freeze does is compress risk into the period immediately after it lifts. Every change that was held, every patch that was deferred, every configuration correction that was queued — all of it lines up at the gate on the same day. Teams are fatigued from the peak period they just navigated. Attention is lower. And now they are executing a backlog of changes in rapid succession, each one incrementally tested in isolation, none of them tested in combination. The two weeks after a freeze are frequently the most dangerous two weeks in the quarter, and they rarely get treated that way.
At Evernorth I watched this pattern play out around major program milestones. The instinct to freeze was understandable — these were high-visibility moments with real business consequences if something went wrong. But the freeze itself was rarely preceded by a serious audit of what the environment’s actual state was at the moment of locking. You cannot freeze your way out of a problem that existed before the freeze. You can only delay encountering it, and you can choose a worse moment to encounter it.
The discipline that a freeze is trying to buy is predictability. That is a legitimate goal. But predictability comes from knowing the state of what you are protecting, not from stopping activity. If you do not know whether your environment is healthy before you freeze it, you are locking in uncertainty, not stability.
A freeze also degrades your ability to respond. If something breaks mid-freeze — and it will, eventually — your change process is suspended. Emergency change procedures exist for exactly this reason, but they are typically under-rehearsed and, because they bypass normal review, they carry their own risk. The people approving emergency changes during a freeze are doing it under pressure, without the benefit of the normal assessment cycle, on an environment they have not touched in days or weeks. That is not a safe place to be making fast decisions.
None of this means a freeze is always the wrong call. There are environments where the risk of introducing change genuinely outweighs the risk of holding still, and where the pre-freeze state is well understood and documented. The problem is that most freezes are not preceded by that assessment. They are calendar events, not risk decisions.
If you are going to freeze, do the audit first. Know what is expiring, what is degraded, what deferred maintenance you are carrying into the locked period. Be explicit about what emergency change authority looks like, who holds it, and how it gets exercised without the normal committee. And build the post-freeze backlog into a deliberate, sequenced plan rather than a release of pressure.
A freeze treated as a risk management tool produces a false sense of control. A freeze treated as a specific trade — we are accepting these known exposures in exchange for reduced change velocity during this window — is something you can actually manage. The difference is whether someone did the accounting before the gate closed.