Changing infrastructure that cannot simply stop

Most guidance on technical change assumes, at least implicitly, that there's a quiet window somewhere to do it in — a maintenance slot, a quiet weekend, a period where the system can tolerate being wrong for a while. Live, 24/7 operational environments don't reliably offer that. The system has to keep working throughout the change, not just before it and after it, and "it'll be back up in twenty minutes" isn't a plan, it's a risk you haven't priced yet.

I've spent a meaningful part of my career designing and delivering change inside environments like that — infrastructure and network transformation on estates that don't stop for anyone, because stopping isn't an option the business actually has. It changes how you have to think about almost every part of a project, from architecture through to the last cutover step.

The constraint comes first, not last

The instinctive order of operations for a lot of technical change is: design the target state, then work out how to migrate to it. In a live environment, that order needs to flip, at least partially. The migration path is as much a design constraint as the target architecture is — a technically elegant target state with no safe path to reach it isn't actually a usable design, it's a diagram.

That means asking "how do we get there without breaking anything on the way" at the same time as "what should this look like when we're done," not afterwards. Sometimes the honest answer changes the target design itself — a slightly less elegant architecture that can be migrated to safely, in controlled stages, beats a cleaner one that can only be reached by an unacceptable amount of risk in a single cutover.

Phased, reversible, and boring on purpose

The safest changes in an always-on environment tend to be the ones that are deliberately unremarkable: broken into small stages, each one independently testable, each one able to be rolled back without depending on the next stage also working. That's slower than a single big-bang cutover, and it's slower on purpose. The goal isn't to look impressive; it's to make sure that if something does go wrong, the blast radius is one stage, not the whole programme.

This has a practical effect on sequencing. Instead of asking "what's the most efficient order to do this in," the better question is often "what's the order that leaves us in a safe, working state after every single step, even if the next step gets delayed by a week." Efficiency that removes your ability to stop safely partway through isn't actually efficient — it's a bet, and it's usually not one worth making with a live system.

Testing has to mean something close to real

In a project with a genuine maintenance window, testing gaps get caught and fixed inside that window, mostly out of sight. Without one, the gap between "tested" and "tested under conditions close enough to production to mean anything" matters a lot more, because there's very little slack to absorb the difference when it shows up live.

That pushes toward testing that deliberately tries to resemble real operational conditions — realistic load, realistic failure scenarios, and wherever possible, validation with the people who'll actually be operating the result, not just the people who built it. It's more expensive than testing against a clean lab environment. It's also considerably cheaper than finding out the difference during a live cutover.

The people running it matter as much as the design

A migration plan is only as good as the team executing it understanding not just their own step, but what happens if their step goes wrong. In a live environment, that's not a nice-to-have; it's the difference between a contained issue and an incident. Clear rollback criteria, a genuinely obvious decision point for "we stop here and back out," and a team that's rehearsed what that looks like — not just been told it's the plan — make the difference between change that's actually safe and change that's safe on paper.

None of this is about heroics or unusual technical cleverness. If anything, the opposite: the best outcome in this kind of environment is almost always the least dramatic one, where nobody outside the delivery team noticed anything changed at all. That's a difficult standard to hit, but it's the right one — because in an environment that genuinely cannot stop, "nobody noticed" isn't a low bar. It's the entire point.