How long should a cutover window be?
The window is as long as the critical path through the cutover sequence, plus verification time and a rollback allowance. It is measured from a full-volume dry run rather than estimated. The ceiling is set by the business: how long the organisation can work without the system, and which day of the cycle causes least damage.
Three clocks decide the length
The first clock is technical. It is the elapsed time of the longest chain of dependent steps — the ones that cannot be run in parallel because each needs the previous one finished. Backups, data extracts, loads, index rebuilds, interface reconfiguration, smoke tests. The chain is what matters, not the total effort; twenty tasks running at once still take as long as the slowest one.
The second clock is the business. There is a period the organisation can operate without the system, and a period after which orders are lost, staff are idle or a regulatory deadline is missed. That tolerance varies by day and by point in the month. Warehouse systems, payroll and billing all have days where an outage costs far more than it does the week before.
The third clock is people. A window that runs for eighteen hours needs shift handovers, rest and cover; the same sequence executed by tired people in hour sixteen is not the same sequence. Long windows push work into the part of the night where mistakes cluster and where nobody is available to answer a question.
Measure it, do not estimate it
Estimates for cutover steps are consistently optimistic because the estimate is usually made against a test dataset. A dry run at production volume gives you the numbers that count: how long the extract really takes, how long the load takes when the table has ten years of history, how long the reconciliation report takes to produce and read.
Each rehearsal should update the timings in the sequence, and the gap between rehearsals should shrink. If the second dry run is materially slower than the first, that is a finding for the go/no-go discussion, not a rounding error. The Cutover Runbook & Hypercare Pack holds the per-step durations so the total is calculated from the steps rather than asserted.
What has to fit inside the window
| Block | What it covers |
|---|---|
| Freeze and shutdown | Stopping transactions, closing the old system, confirming no in-flight work |
| Backup and snapshot | The restore point the rollback depends on |
| Migration and configuration | Extract, transform, load, interface switch, environment changes |
| Reconciliation | Record counts, control totals, financial balances against agreed tolerances |
| Verification | Smoke tests and business process checks by the people who will use the system |
| Contingency | Unplanned time held back before the rollback decision point |
| Rollback allowance | Enough remaining time to reverse and be live on the old system by the deadline |
The last two rows are the ones squeezed when a date looks tight, and they are the ones that make the difference between a difficult night and a lost weekend. A window with no rollback allowance is not a window with a fallback; it is a window with a plan nobody can execute.
Working backwards from the deadline
A more useful question than "how long do we need" is "when must we be live". Fix the moment the business needs to transact — the first shift on Monday, the start of the billing run, the open of trading — then work backwards through verification, contingency and the sequence. That produces a start time, and it produces the point of no return as a by-product: the last moment at which a rollback can still finish before the deadline. Recording that point explicitly is part of the rollback plan, and it is the single most useful number in the window.
Shortening a window that will not fit
When the sequence is longer than the tolerance, the options are structural rather than a matter of working faster.
- Move work outside the window. Static and reference data can often be loaded days ahead, leaving only the delta for the night.
- Reduce the data scope. Migrating open transactions and a defined history period rather than everything, with the remainder available read-only from an archive.
- Phase the transition. Site by site, entity by entity, or module by module, so each window is shorter even though the programme is longer.
- Parallel run. Both systems live for a period, which removes the outage but adds double entry and a reconciliation burden.
Each of these has a cost that lands on someone. Phasing adds interim interfaces. Delta migration adds complexity to the load. A parallel run adds work for the business team who are also learning the new system. The data migration guide covers the load-sequence side of those choices.
Recording the decision
Whatever length is chosen, the window belongs in three places: the cutover plan, the change record raised with whoever governs production changes, and the communication that tells users when the system will be unavailable. Those three should say the same times. When they do not, the business plans around one set of hours and the team works to another. The cutover plan is where the authoritative version sits.
Questions
Should a cutover run over a weekend or overnight?
It depends on which hours cost the business least and whether the sequence fits. A weekend gives more contingency and more room to reverse; a weeknight limits the outage but leaves less margin.
How much contingency should be held back?
Enough that the point of no return still leaves time to complete a full rollback before the business needs the system. That is a calculation from the rollback timings, not a fixed percentage.
Can the window be extended on the night?
Only if the extension was agreed in advance with the business and the rollback still fits. An extension decided during execution usually consumes the rollback allowance without anyone noticing.
Does a phased cutover need a separate window each time?
Yes, and each phase needs its own criteria, verification and fallback. The later phases also inherit the defects from the earlier ones, which tends to lengthen them.