How do you plan a deployment window?
Planning a deployment window means fixing four things: when the change may run, given the change calendar, freeze periods and business cycles; how long it needs, measured from a rehearsal; who has to be available and for which hours; and the point at which you stop and revert. The window is then approved through change control and communicated with the outage times users will see.
Start with the constraints, not the date
A window is chosen out of what is left once the constraints are applied, which is usually a much smaller set of options than the calendar suggests.
- Business cycles. Month-end, quarter-end, payroll, billing runs, statutory reporting, peak trading. Each has days where an outage costs disproportionately.
- Change freezes. Periods where production changes are not permitted, whether formal or by convention.
- Other changes. What else is scheduled against the same systems, the same infrastructure or the same people.
- Third parties. Suppliers and hosting providers with their own change calendars and their own notice periods.
- People. Holidays, shift patterns, and whether the person who wrote the deployment script is reachable.
- Environment availability. Whether the environments needed for a final rehearsal are free in the run-up.
Gathering these early is unglamorous and it prevents the conversation where a date is announced and then withdrawn.
Get the duration from a rehearsal
The length of the window is the elapsed time of the critical path — the chain of steps that must run in sequence — plus verification and enough time to reverse. Those numbers come from running the sequence, not from adding up estimates. A rehearsal at production volume also produces the missing steps that only appear when someone tries to do the work.
The blocks that have to fit are the same for a deployment as for a full cutover: freeze and shutdown, backup, deployment and configuration, any data work, verification, contingency and a rollback allowance. The cutover plan guide covers how those blocks are sequenced, and the Cutover Runbook & Hypercare Pack holds the per-step durations the total is built from.
Fix the revert deadline before you fix the start time
Work backwards from the moment the business must be transacting. Subtract verification, subtract the rehearsed duration of the reverse sequence, and the result is the latest point at which a rollback can still be started and finished. That is the number the whole window is organised around, and it is the one people notice is missing only after they have passed it. The triggers that would cause it to be used belong in the plan too, which the rollback plan guide covers.
Staff it properly
A window needs a named person against each step, a coordinator who is the single point of truth for status, and a decision-maker who is awake and reachable. For anything long enough to need a handover, the rota needs shift boundaries that do not fall in the middle of a critical step, and a written handover format so the incoming shift knows what has been done, what deviated and what is outstanding.
Third-party cover is arranged rather than assumed. A support contract that provides next-business-day response is not cover for a Saturday night. Whoever needs to be on standby should know it in writing, with the hours and the number they will be called on.
Get it approved and recorded
Most organisations have a route for approving production change — a change record, a board, an approver, a notice period. The window goes through it with the same times that appear in the plan and in the communication to users. When those three documents disagree, the business plans around one set of hours and the team works to another.
The change record normally wants the same content the plan already contains: what is changing, the risk assessment, the test evidence, the backout procedure and the communications. It is worth writing the plan so that content can be lifted rather than rewritten. The Go/No-Go Checklist covers the readiness criteria the approval usually asks for.
Communicate the outage, not the change
Users need three facts: when the system will be unavailable, what to do during that time, and how to report a problem afterwards. Everything else is detail for a different audience. The message goes out with enough notice for people to plan around it, and again shortly before the window, and once more when the system is confirmed available.
Internally, the audiences are different: the service desk needs to know before the users do, so that the first call does not surprise them; adjacent teams need to know what will be unreachable; and anyone whose own schedule depends on the system needs the outage in their own calendar.
Plan the second window
The window that gets forgotten is the next one. If the change is reversed or stood down, when is the retry? Having a candidate date already checked against the same constraints turns a no-go from a crisis into a rescheduling. It also makes the no-go decision easier to take, which is the real benefit. The go-live checklist covers the surrounding readiness structure.
Questions
How much notice should users get?
Enough that they can move work around the outage, which depends on the business cycle rather than a standard number of days. The notice period your change process requires is a floor, not a target.
Should a deployment window include verification time?
Yes. A window that ends when the deployment finishes ends before anyone knows whether it worked, and the verification then happens with users already on the system.
What if the window overruns?
The revert deadline governs. Overrunning past it removes the rollback option, so an overrun is a decision point rather than something to work through quietly.
Do low-risk changes need this much planning?
No. The full structure earns its place where there is a business outage, several teams, or a change that cannot be simply reversed.