Freeze Period
A freeze period is a defined window during which changes to named systems, data, configuration or environments are not permitted. It records what is frozen, when it starts and ends, who approves exceptions, and who enforces it. Freezes are used around cutovers and high-risk periods so that what is deployed matches what was tested.
A freeze protects a known state. Between the point where testing finishes and the point where the new system is live, any change to the source systems, the reference data or the configuration invalidates part of what was tested. The freeze is the mechanism that holds that state still for long enough to complete the transition.
What it contains
| Field | What it defines |
|---|---|
| Scope | The systems, environments, code branches, configuration and data objects covered |
| Out of scope | What continues as normal, stated explicitly so it is not assumed |
| Start and end | Dates and times, including when the freeze lifts after go-live |
| Type | Full freeze, or partial — for example code frozen but data maintenance continuing |
| Business impact | What users cannot do during the window: new master data, price changes, new starters, period close |
| Exceptions process | How an urgent change is requested, who assesses it, who approves it and how it is re-tested |
| Approver | The named person who can grant an exception, usually one individual rather than a forum |
| Enforcement | Who checks compliance and how — access restriction, branch locks, change advisory controls |
| Communications | Who is told, when, and what workaround is offered for what they cannot do |
Exceptions are the part that needs a record. Each one carries the request, the assessment of what it affects, the approval and the re-test, so that after the transition it is possible to say exactly what differed from the tested state. The Change Request Log (Excel) is the usual place that record lives.
How it is used
Freeze dates are set backwards from the transition: the final data extract determines when data maintenance has to stop, and the last regression test determines when code has to stop moving. The dates are communicated well ahead, because a freeze imposes real cost on the business — deals not entered, staff not onboarded, prices not updated — and that cost has to be planned around rather than discovered.
Freezes are also used outside cutovers, around trading peaks, financial year end and regulatory deadlines, on the same principle: stability is worth more than throughput for a bounded period. The cutover plan guide covers where the freeze sits in relation to the rest of the sequence.
Where it goes wrong
Unenforced freezes are the standard failure. Everyone agrees to it, one team continues to make configuration changes because their work is "not really a change", and the reconciliation break turns up at two in the morning with no obvious cause.
The second is a freeze announced without a business impact statement, so the first anyone hears is when they cannot create a customer record. The third is an exceptions route with no assessment step, which makes the freeze a formality. The fourth is forgetting to define when the freeze lifts, leaving normal change suspended for weeks after go-live because nobody said it had ended.
The fifth is a freeze that starts too early. A window measured in weeks rather than days creates a backlog of held changes, all of which are released at once after go-live into a system that is still being stabilised. The pressure to keep the freeze short is a real constraint on the plan rather than an inconvenience, and it is one of the reasons the sequence is timed rather than estimated.
Related terms
See also cutover, cutover plan and dress rehearsal.
Questions
What is the difference between a code freeze and a data freeze?
A code freeze stops changes to the application and its configuration; a data freeze stops changes to the records being migrated. They usually start at different times, driven by the last regression test and the final extract.
How long should a freeze last?
As short as the sequence allows. The length is determined by the time between the last tested state and the point the new system is verified, plus whatever contingency the plan holds.
Can changes be made during a freeze?
Only through the stated exceptions route: a request, an impact assessment, a named approver and a re-test. Each exception is recorded so the deviation from the tested state is known.
Who enforces a freeze?
Whoever controls access to the systems in scope — release management, the platform team or the vendor. A freeze with no enforcement mechanism relies on memory.