Why AI Launch Dates Must Respect Customer Change Freezes

You agreed on a go-live date, and the sponsor has already told their boss. Then the customer's infrastructure lead answers your change request with one line: "That's inside our freeze." Customer change freezes are the calendar entries that overrule every launch plan written without them.

A change freeze is a window when the customer blocks production changes or lets only emergencies through. Quarter-end close, holiday trading peaks, audits and big migrations are the usual causes. These enterprise release windows come from customer policy, so derive the go-live date from them instead of negotiating against them later.

Why customer change freezes break AI go-lives

A normal app release is one change request. An AI go-live is a bundle: firewall rules to reach a model endpoint, a service account with IAM roles, secrets for API keys, access to the retrieval data source, and monitoring agents. Each can be its own ticket, judged separately against the freeze. Your code can be ready while half the prerequisites sit behind a locked gate.

The freeze that hurts most is the one after launch. The first weeks of a new AI system produce fixes: prompt changes, retrieval tweaks, sometimes a model version bump. If a freeze starts ten days after go-live, you have shipped a system you are not allowed to repair.

What happens when the date ignores the freeze

Either the launch slips as a late surprise, or it gets pushed through on an exception. The exception path needs senior approvers in the weeks when they are most nervous about change and your reviewers are on leave or buried in close. Google's SRE book says roughly 70% of outages are due to changes in a live system. A launch inside a freeze takes that risk when the customer is least willing to absorb it and least staffed to catch it.

Ask for the change freeze calendar at kickoff

Ask the customer's change manager in week one, not the week before launch:

1. What are the freeze windows for the next 12 months, and who owns the calendar?
2. What does each freeze block: everything, only infrastructure, only high-risk changes? Are pre-approved standard changes still allowed?
3. What is the exception path, who approves it, and how much lead time does it need?
4. How many days does a normal change request take, including security and architecture review?

Record the answers in a file next to the project plan:

customer: <customer-name>
calendar_owner: <name, role>
calendar_confirmed_on: <yyyy-mm-dd>
freezes:
  - name: <e.g. quarter-end close>
    start: <yyyy-mm-dd>
    end: <yyyy-mm-dd>
    blocks: <everything | infrastructure only | high-risk only>
    exception_path: <approver, lead time in days>
planning_rules:
  change_request_lead_time_days: <days the customer needs per request>
  hypercare_business_days: <days of post-launch fixing you need>
  buffer_business_days: <slack for one rejected request>

The three planning rules turn the calendar into a date. Hypercare is the stretch after launch when you are on call fixing things. Keep the calendar owner's name on it, because a freeze date from a hallway chat is not a freeze date.

Now the go-live date becomes arithmetic instead of hope. Work backwards from the next freeze start:

from datetime import date, timedelta


def subtract_business_days(d: date, n: int) -> date:
    while n > 0:
        d -= timedelta(days=1)
        if d.weekday() < 5:  # Monday to Friday
            n -= 1
    return d


freeze_start = date(2026, 12, 14)  # from the customer's calendar
hypercare_days = 10                # business days of post-launch fixes
buffer_days = 3                    # slack for one rejected change request

latest_go_live = subtract_business_days(freeze_start, hypercare_days + buffer_days)
print(latest_go_live)  # 2026-11-25

The dates are illustrative, and the function ignores public holidays, so subtract those using the customer's own calendar. Then subtract the change request lead time from latest_go_live to get the date your prerequisite tickets must be filed. If latest_go_live is earlier than the date the sponsor wants, you now have a number to take to them instead of a feeling.

The strongest objection: freezes kill momentum

The fair complaint is that AI pilots decay, sponsors lose interest, and a freeze can eat weeks. Sometimes asking for an exception is the right call, for example when the system fixes something already costing the customer money every day.

But an exception should be a trade you chose on purpose, not a rescue from a date nobody checked. A freeze is also not dead time. It is the best window for work that touches no production: evals, runbooks, user training, a rehearsed rollback, and handover docs. Some freezes block less than people assume, which is why question two matters.

First step: check your go-live date this week

Open the project plan, find the go-live date, and send the customer's change manager the four questions above. If the date lands inside a freeze, or leaves no room for hypercare before the next one, you have just avoided a very awkward conversation later.

A production AI system you cannot patch because the customer's freeze started on day ten is a liability, so the freeze calendar belongs in the plan before the model does.