Change windows are the real constraint, not the technology

Ask a delivery team what limits a migration and you will hear about tooling, data volume or headcount. Ask the people who approve the change and you get a different answer: there are eleven hours a month when this system can move, and four of them are already spoken for.

Both answers are true. Only one of them is binding. Effort determines how much work there is; the window determines how much of it can be delivered at once, and no amount of additional engineering capacity widens a window that exists because a settlement run cannot be interrupted.

Plans costed against effort, run against a calendar

A plan built from effort estimates produces a smooth curve: so many weeks of work, so many people, a date at the end. A plan built from windows produces something lumpier and less reassuring — a sequence of small, awkwardly-shaped steps, each one sized to fit an opening that already exists.

The second plan looks worse in a steering pack and is far more likely to land. The first one usually survives until the first change advisory board meeting, at which point the smooth curve is replaced by whatever the calendar allows and everyone pretends the date has not moved.

The failure is not optimism about effort. It is that the window was never treated as an input. It arrived as a constraint to be negotiated afterwards, and by then the sequence had already been designed around the wrong thing.

What sequencing around windows actually looks like

Start from the calendar. List every opening the system genuinely has over the next two quarters, with the ones already committed to other work struck out. What remains is the real delivery capacity, and it is usually a fraction of what the effort model assumed.

Then decompose the work to fit. Not into phases, which are a project-management convenience, but into steps that are individually reversible inside a single window. A step that cannot be rolled back before the window closes is not a step; it is a commitment, and it needs to be recognised as one before it runs rather than after.

This is where most of the engineering judgement goes. Making a migration reversible in ninety minutes is a genuinely harder problem than making it work, and it is the problem that determines whether the programme is delivered on a Tuesday or over a weekend that consumes everyone.

The test

The practical test is simple. If your plan does not name the window each step runs in, and the owner who can roll it back inside that window, it is an estimate rather than a plan.

Estimates are useful. They are how the work gets funded. But they should not be confused with a sequence, and the moment an estimate is presented to an operations team as a schedule, the conversation stops being about engineering and starts being about credibility.