Cutting over a monolith without a maintenance window

Why maintenance windows stopped being acceptable

A retail estate that closes for four hours on a Sunday loses a Sunday. A payments platform that closes for four hours loses trust. Somewhere in the last decade the maintenance window went from a normal operational cost to a thing the business will not sign off on — and migration plans had to change with it.

The technique is not new. Traffic shadowing, dual writes, and progressive cutover have been in the literature for years. What has changed is that they are now the default expectation rather than the premium option, and that shifts the shape of the plan: most of the work happens before anything moves.

Rehearsal is the deliverable. The cutover itself should be the least interesting hour of the project.

The rehearsal loop

We run the same four stages on every estate, however small. Each one has an exit condition that is measured, not asserted.

If shadow traffic disagrees with production on more than a handful of requests, the cutover date moves. That rule has saved more weekends than any tool we use.

The switch we hope never to flip

Every cutover ships with a rollback path that is tested in the same rehearsal, on the same data volume. Untested rollback is not a rollback — it is a hope with a runbook attached.

The switch stays available for a full business cycle after the move. Only when a complete week has passed on the new platform — including the month-end run, if there is one — do we decommission the old estate.