Deployment Window
A deployment window is the agreed period during which a release may be installed, usually chosen for low business impact — a weekend, an overnight period, or a scheduled outage. It is bounded at both ends: by the time the system must be released to users, and by the last moment at which rollback can still complete.
What it contains
A window is defined by four times, not one. The start, when the freeze on transactions or the outage begins. The planned finish, when the system must be available to users. The rollback decision point — the latest moment at which reverting can still complete before the finish. And the contingency remaining between the planned finish and the absolute deadline.
Around those sit the agreements that make the window real: who has approved the outage, which business processes stop and which continue on manual workarounds, what the communications are to users and customers, and who is on call throughout. A window agreed with IT but not with the business is an outage waiting to be objected to.
The tasks inside the window are the runbook: every step, sequenced, timed, owned, with dependencies between them. Building that as a timed sequence rather than a checklist is the distinction covered in cutover plan versus runbook, and it is what the runbook workbook is structured around.
How it is used
Sizing the window is an evidence question. The total duration is the sum of the sequenced tasks plus contingency, and the task durations come from dry runs rather than estimates. Data loads in particular have to be timed at full volume, because a migration that takes eleven hours will not fit into an eight-hour window regardless of how carefully the rest is planned.
The window then constrains the plan rather than the other way round. If the sequence does not fit, something changes: scope reduces, the migration is split into pre-load and delta, more parallelism is engineered, or the window is extended by negotiating a longer outage. Discovering the mismatch during the final rehearsal is late but survivable; discovering it live is not.
During the window itself, progress is tracked against planned times, with checkpoints at defined moments. The go/no-go decision happens before the window opens; the checkpoints inside it are smaller decisions about whether to continue, and the rollback decision point is the last of them.
Where it goes wrong
The recurring failure is a window sized from optimism. Task durations are estimated, not measured, and there is no contingency, so the first delay consumes the buffer that was never there. Rehearsed timings are the only reliable input.
The second is a rollback decision point that was never calculated. The team runs past the moment when reverting was still possible, and then has no choice but to continue — which converts a controlled decision into a forced one.
The third is business availability assumed rather than booked. Reconciliation sign-off and business verification both need named people awake and available at three or four in the morning. Naming them, with contact details and a rota, belongs in the runbook.
The fourth is a window agreed without the dependent systems. Interfaces to third parties, batch schedules and downstream reporting all have their own timings, and a window that ignores them delivers a system that is technically live and operationally disconnected. Those interfaces are ordinary dependencies and belong on the register.
Related terms
Cutover is the full sequence executed within the window. Point of no return is the moment after which rollback can no longer complete in time. Freeze is the period during which changes and sometimes transactions are stopped. Outage is the business-facing unavailability the window creates. Contingency is the unallocated time held between the planned finish and the deadline.
Questions
How is the length of a deployment window decided?
By summing rehearsed task durations and adding contingency, then checking that total against the outage the business can accept. Estimated durations produce windows that overrun.
What is the point of no return?
The last moment at which a rollback could still complete before the system must be available. Past it, continuing is the only option, which is why the time is calculated in advance.
Why are weekends used for deployment windows?
Because transaction volumes are lower and a longer outage is tolerable. The trade-off is staff availability and slower access to third-party support.
What happens if the window overruns?
The runbook should define checkpoints and the rollback decision point in advance, so that overrun triggers a decision that was already agreed rather than an improvised one.