Staged Rollout Planner

Enter your own numbers. The planner holds no reference data at all — no assumed patch durations, no typical batch sizes, no benchmark soak periods — because every default of that kind would be a made-up figure that somebody eventually schedules against.

The model it is using

State it plainly, because a planner you cannot argue with is a planner you cannot correct.

A batch is a fixed number of hosts and only the last one may be short. Patching a full batch costs the time you entered; a short final batch costs that time scaled by how short it is, on the assumption that most of the work is per host rather than fixed setup. After every batch except the last there is a soak, and during the soak nothing else is touched.

Two different durations come out of that, and confusing them is the usual mistake. Continuous elapsed time is what the rollout would take if you could run it without interruption: every patch run, plus the soaks between them. It is the number people quote, and it is almost never the number that matters.

Days of window is what it actually takes, because the work is only permitted during a window. Each batch has to be applied and observed inside one window, so the unit that must fit is patch time plus soak. The planner fills each day greedily until the next batch will not fit, then starts a new day.

The failure it exists to catch

If one batch plus its soak is longer than the window, the rollout does not finish slowly. It does not finish at all. No number of additional days changes that, because every day hits the same wall — and yet the arithmetic that reveals it is a single subtraction that a planning meeting will happily skip.

That case is reported as infeasible rather than as a large number of days, on purpose. A planner that answered “sixty-one days” to a plan that can never reach batch two is worse than one that refuses to answer.

The four ways out are all visible in the inputs. Make the batch smaller so the patch run shortens. Shorten the soak, and be honest that you have shortened the evidence with it. Lengthen the window, which is usually a negotiation rather than an engineering task. Or decide the soak may run unattended outside the window, which is a real option but a different plan — the planner will not assume it for you.

What the batch count is really telling you

The batch count is also the number of decision points. Every boundary between batches is a place where somebody can look at what happened and choose to continue, pause or reverse. Ten batches is ten chances to stop; two batches is one. That is the actual trade being made when the batch size goes up, and it is worth seeing next to the elapsed time rather than instead of it.

The final partial batch deserves a glance too. A fleet of a thousand in batches of three hundred leaves a hundred hosts in a fourth run, and those hundred are frequently the leftovers — the odd builds, the hosts nobody could classify, the ones that failed the first three attempts. They are the batch most likely to misbehave and the one usually planned with the least care.

Limits worth knowing

The arithmetic assumes batches are the same shape and that patch time scales with host count. Real fleets are lumpier: one batch contains the database cluster and takes four times as long as its size suggests. Split those out and plan them separately rather than averaging them in.

It also assumes windows are the same length every day and that you get one per day. Neither is true in a shared change calendar, where the window is contended by every other project in the organisation. Treat the day count as a floor.