Every year the same scene plays out in IT departments. In mid-November a “simple” fix is pushed to production, and three weeks later the CFO discovers that the stock reconciliation no longer adds up, right in the middle of year-end inventory preparation. Nobody did a bad job. The change was correct. It just landed at the worst possible moment.
An ERP change freeze is the answer to that problem. But a badly designed freeze produces the opposite of what you want: a backlog that explodes in January, teams working around the rules, and security patches put off. This guide is for CIOs, ERP application owners and CFOs of mid-market companies. It explains how to build a realistic freeze calendar, what to freeze and what to let through, how to handle exceptions and forced SaaS updates, and how to thaw cleanly.
Why Freeze: The Risks of Changing Production at Sensitive Times
A production change is never neutral. It is even less so when three conditions stack up: data is locked in by legal deadlines, users are under pressure, and the people who know how to fix things are on leave.
During inventory. Changing valuation settings, lot management or bin locations mid-count distorts the comparison between book stock and physical stock. For counting best practices, see our guide on initial inventory and cycle counting in your ERP.
During the close. The annual close chains together irreversible operations: depreciation, provisions, accrual entries, period locking, carry-forward of balances. Modifying a chart of accounts, a posting rule or a bank interface during that sequence creates variances that are hard to explain to your auditors. These steps are detailed in our year-end close checklist for cloud ERP.
During peak trading. For a distributor or an e-commerce business, year-end concentrates a large share of annual activity: sales, holidays, promotional campaigns. A few hours of downtime or a regression in price calculation costs far more than the same incident in March.
With reduced teams. Between leave, site closures and integrator unavailability, diagnostic capacity drops just as risk rises.
The purpose of a freeze is therefore not to stop your information system from evolving. It is to reduce the probability and impact of an incident in a window where the business cannot afford one.
Building the Freeze Calendar
A good calendar does not start from a date picked at random. You build it by overlaying three sets of constraints, then looking for the windows that are genuinely available.
Finance Constraints: Inventory, Close, Filings
Ask the CFO and the head of accounting for a calendar of the deadlines that depend on the system:
- the physical inventory date, per site if you have several;
- the start of interim period closes (November, December) and of the annual close;
- year-end tax and payroll filings (VAT, social charges and the like);
- audit milestones: interim audit visits, delivery of ledger files;
- period locking dates in the ERP.
These dates vary with the fiscal year. A company with an offset year-end (closing on 30 June or 31 March) will apply the same logic to a different period: the freeze follows the accounting calendar, not the calendar year.
Business Constraints: Sales, Holidays, Campaigns
Ask sales, logistics and e-commerce leaders about:
- year-end promotions and trading events;
- volume peaks in orders, shipments and returns;
- site or warehouse closures and leave periods;
- product launches or market openings that may justify a managed exception.
The goal is to find the period when an outage costs the most, which is not always the close. For a retailer it is often the trading peak. For a manufacturer it is the year-end shutdown and the restart in January.
Vendor Constraints: Release Waves and Forced Patches
With a SaaS ERP, part of the calendar is not yours. For each vendor and each satellite application, list the updates scheduled between November and February, any deferral rules and the contractual maintenance window. Release cadences and deferral options differ widely between vendors: our guide to SaaS ERP updates and release management compares them and shows how to build them into your annual plan. Always check your vendor’s official documentation before locking the calendar.
Sample 10-Week Calendar
The table below is illustrative. It assumes a calendar fiscal year, an inventory in early January and strong year-end trading. Adapt the dates to your own situation.
| Weeks | Phase | Change rule |
|---|---|---|
| W1 to W3 (mid-November to early December) | Pre-freeze | Last planned production releases; review of pending requests; new developments refused unless urgent |
| W4 (mid-December) | Strict freeze, part 1 | No configuration, development or interface changes; only approved exceptions go through |
| W5 to W6 (holidays) | Strict freeze, part 2 | Same regime, with a reduced on-call team and an updated hotfix procedure |
| W7 (early January) | Inventory and start of close | Freeze maintained on finance and stock scope |
| W8 | Annual close | Freeze maintained on accounting; progressive reopening of scopes unrelated to the close |
| W9 | Gradual thaw | Backlog released in waves, starting with fixes and low-risk changes |
| W10 | Back to normal rhythm | Freeze review, process adjusted for next year |
Note that the freeze is not the same for every scope. A point of sale in a store does not have the same constraints as financial consolidation. A calendar by functional domain (finance, supply chain, sales, HR) is almost always more realistic than a global freeze.
What to Freeze and What to Let Through
The “total freeze” is the classic first mistake: it is unrealistic, so it gets bypassed. Reason by change category and risk level.
| Category | Default position | Comment |
|---|---|---|
| Functional configuration (accounting, valuation, pricing) | Frozen | Direct impact on postings and prices; exception only for a blocking error |
| Custom developments and extensions | Frozen | No production releases; development continues in test environments |
| Interfaces and integrations (bank, EDI, marketplace, carrier) | Frozen, with monitoring | Including on the partner side: a change at a third party can break the exchange without you touching anything |
| Roles and permissions | Controlled | Joiners and leavers are still processed; no profile redesign; mind segregation of duties during the audit |
| Critical security patches | Allowed | Never frozen, but they go through the exception procedure with targeted testing |
| Blocking bug fixes | Allowed by exception | Criterion: business activity or a legal deadline is blocked |
| Master data (items, business partners) | Allowed | Routine operations; mass changes are treated as changes |
| Non-production environments | Free | Development, test and acceptance continue: this is what prepares the thaw |
Two points deserve particular attention. First, third-party interfaces, which are often forgotten. Your ERP can stay untouched while your bank, carrier or e-commerce platform changes its exchange format or API. Add these partners to your watch list and ask for their own freeze calendars. Second, privileged accounts. Reducing change access to production during the freeze is a simple measure that makes the freeze verifiable rather than merely declared.
Exception and Hotfix Procedure
A freeze with no exception mechanism does not hold. The first real emergency will blow it apart, and informal workarounds are worse than controlled exceptions. Define the procedure before the freeze starts.
Eligibility criteria. An exception is admissible only if at least one of these criteria is met:
- a legal, tax or contractual deadline is at risk;
- a critical security flaw is exploitable;
- business activity is blocked, or a significant financial loss is demonstrated;
- not changing would carry a higher risk than changing.
“The sales director wants it by Monday” is not a criterion. That belongs in the January backlog.
Minimum file. For each request: a description of the change, the reason for urgency, the impacted processes, test results, the rollback plan and the requester’s name.
Approvers. Plan for at least two sign-offs: the ERP application owner (technical feasibility) and the owner of the business process concerned (finance or supply chain, as applicable). For changes touching postings, involve the CFO. Name deputies for the holiday period.
Rollback plan. No exception without a precise answer to the question: “if this fails, how do we return to the previous state, how long does it take and who decides?” For a code fix, that may be a transport rollback. For a configuration or data change it is trickier: you must have exported the previous state. A change that cannot be undone requires a higher level of approval.
Traceability. Every exception is recorded in the change log with date, decision and outcome. This log feeds the post-freeze review and, where relevant, your auditors.
Handling Forced SaaS Updates During the Freeze
This is where freezing a SaaS ERP differs from freezing an on-premise one. The vendor can deploy an update during your sensitive period, and your change board has no say.
Four levers exist, to be confirmed with your vendor and in your contract:
- Request a deferral when possible. Some vendors let you postpone an update or choose a window. Plan ahead: deferral requests often have a cut-off date.
- Control the activation of new features. Even when the update installs, new functions can stay disabled by default. Keep them disabled during the freeze.
- Read the release notes before deployment. Spot the changes that touch finance, interfaces and the APIs you use. Updates that alter existing behaviour are the ones that threaten you.
- Target your regression tests. You do not have time to retest everything. Build a short suite covering the period’s critical processes: journal entries, stock valuation, invoicing, bank and EDI exchanges, order entry. To automate this core, see our article on AI-assisted ERP regression testing.
A forced update landing during the freeze should be handled as an emergency change to observe, not as an event you simply endure: run the targeted regression suite as soon as the update reaches your test or pre-production environment, then monitor production closely over the following days. Also record the update in the change log, like any other modification.
Communication and Governance
A freeze works when everyone knows what it covers and who to contact. A few simple rules are enough.
Announce early and clearly. Communicate the dates, scope and exception procedure at least six weeks before the freeze begins. Spell out what remains possible: this avoids the impression of a general blockade.
A tighter change board. During the freeze, a short board (fifteen to thirty minutes, once or twice a week) handles exception requests and reviews incidents. Outside those meetings, provide a single, well-known emergency channel.
An explicit RACI.
| Activity | CIO | ERP app owner | CFO | Business process owner | Integrator / AMS |
|---|---|---|---|---|---|
| Define the freeze calendar | A | R | C | C | I |
| Validate finance constraints | I | C | A/R | C | I |
| Assess an exception request | I | R | C | A | C |
| Approve a sensitive exception | A | R | R | C | I |
| Apply the hotfix and rollback | I | A | I | I | R |
| Track vendor updates | I | A/R | I | I | C |
| Review and thaw | A | R | C | C | C |
R: responsible, A: accountable, C: consulted, I: informed.
Involve your service providers. Align the application maintenance contract and the integrator’s commitments with the calendar: availability over the holidays, response time for exceptions, no deliveries without sign-off. Do the same with vendors of satellite applications (payroll, e-commerce, WMS).
The Thaw: January, Accumulated Backlog, Restart Order
A freeze mechanically builds a backlog. The thaw is the phase where many organisations reproduce the very incident they wanted to avoid: everything is delivered at once, in the first week of January, with teams just back from leave.
To avoid this:
- Wait for sensitive operations to finish. The finance scope thaws only after the close and period locking. Scopes unrelated to the close can reopen earlier.
- Triage the backlog. Sort the accumulated requests: fixes, regulatory changes, business enhancements, nice-to-haves. Legal obligations for the new year come first.
- Deliver in waves. One wave per week, with a limited scope and heightened monitoring. Do not mix a financial fix and a supply chain change in the same wave.
- Replay the regression suite before each wave, especially if a vendor update was absorbed during the freeze.
- Hold a review. How many exceptions? Which were justified? Which change caused an incident? Which request should have gone through before the freeze? This feedback feeds next year’s calendar.
Mistakes to Avoid
- The total freeze. If nothing can pass, everything will pass outside the process. Distinguish categories.
- No exception planned. The first emergency destroys the credibility of the whole scheme. The procedure must exist before the freeze.
- Forgetting third-party interfaces. Bank, carrier, marketplace, tax authority: their calendar matters as much as yours.
- A freeze decided by IT alone. Without the CFO and the business, the dates do not reflect the real constraints.
- An abrupt thaw. A backlog delivered in one block concentrates the risk in a single week.
- No review. Without lessons learned, next year’s freeze will repeat the same flaws.
Calendar Template and Checklist
Three phases to work through as a team, with one named person per line.
Before the freeze (at least six weeks ahead)
- Finance deadlines (inventory, close, filings, audit) collected from the CFO
- Business peaks and site closures identified
- Planned vendor updates listed, with deferral options
- Freeze calendar defined by functional domain and approved by IT, finance and the business
- Exception procedure, criteria, approvers and deputies documented
- Targeted regression suite up to date
- Partners (bank, carrier, integrator, vendors) have shared their own freezes
During the freeze
- Production change access restricted
- Change board meets at the planned rhythm
- Every exception logged with its rollback plan
- Vendor updates tested on the critical scope and tracked
- Third-party interfaces and overnight batch jobs monitored
At the thaw
- Close and period locking confirmed before reopening the finance scope
- Backlog triaged and planned in waves
- Regression replayed before each wave
- Freeze review shared and process adjusted
Going Further
To structure your change governance and your next vendor choice with method, download our ERP evaluation scorecard: 30 criteria across 100 points to benchmark three vendors side by side, including their ability to deliver a controlled release calendar.
