Modernise Without Downtime: Lower the Risk

You want to modernise without downtime. Treat that as a risk goal, not a promise that nobody will notice the switch. A small team can often move one slice while the current path keeps doing the work. Some changes still need a planned window. Decide which is which before anyone builds.

How to modernise without downtime, and when you cannot

The phrase does not mean the lights never flicker. It means you reduce the chance that a change stops today’s work.

Uptime is the plain measure: is the thing people rely on available when they need it? An SLA may already say what interruption is acceptable. If it does not, write down a number, and who must be told.

Reducing that risk is not the same as removing it. A quiet deployment of a brochure site is a different problem from moving the records invoices depend on.

Run the old path and the new path together

Parallel running means both paths see the same work for a period, and someone compares the results before the business depends on the new one.

Example, not a client result: staff still work from the spreadsheet while each enquiry is also copied into the new form. Someone checks names, dates, and statuses. Differences are investigated.

Thoughtworks describe a related idea, dual run: same inputs, then outputs that match, or sit inside a tolerance you agreed first. Running both is not free, and the overlap itself should not be expected to save money. If nobody owns the comparison, you are hoping. A parallel run with no end date becomes a second job.

Replace one piece, leave the rest alone

The strangler pattern, named by Martin Fowler after the strangler fig, is a plain idea. Do not rewrite the whole system and flip a switch. Build the new behaviour beside the old, move one job across, and leave the rest until that job is reliable.

Fowler is clear this does not make replacement easy. It makes cost and result visible in smaller steps. Much of the old behaviour is not wanted. Rebuilding it because it exists is how long programmes stall.

Example: the public pages move first. The booking calendar stays until the new path has taken real bookings for a listed set of cases, and you can turn it off. The join is temporary. Someone has to remove it.

GOV.UK’s service manual describes the same move: put the interface you want in front of the old system, then replace what sits behind it. Comparing answers before anyone relies on them is a test, not a launch. If you cannot name the slice in a sentence, it is not a slice.

Ship a slice, and keep the old path

A feature flag is a business control. You ship the new slice. A switch decides who sees it. Everyone else stays on the old path.

Pete Hodgson, writing on Martin Fowler’s site, separates deploying code from releasing it. Unproven behaviour can sit in production without being the path people use. Some flags can also be turned off without a new release. Start with one person, one client, or one product line.

Example: the new quote is on for the founder only. The team still sends the current one. If the new document misses a line, the switch goes off.

Release flags are meant to be temporary. A flag left on for months is a second system. Write down who may turn it off, and when the old path will be removed. If nobody owns that, the old path will stay.

Rollback is a decision you can carry out

Rollback is not a sentence in a plan. Before anyone depends on a new path, name four things.

Who can call it: one person on duty, and a deputy. What “wrong” looks like: a failed payment, a missing record, a page that will not load, or a total that does not match on the cases you listed. A feeling is not a trigger.

The action: flip the flag, point the form back, or restore the previous release. The person on duty should be able to do it without the builder. How you will know: logging shows which path a record took. Without that, a quiet failure looks like success until a customer asks.

If the only rollback is fixing it forward, you do not have one. Try the switch-back once, on a case that does not matter, before you need it.

What “good enough to switch” means

Good enough is a written bar, not a feeling after a demo.

The new path handles the cases you listed, including the awkward ones: the partial record, the duplicate, the late payer. Differences against the old path are explained, not merely spotted. The data quality checks you agreed are passing on real records. The person who does the work has used it, and can say what they would do if it failed. Rollback has been tried.

Matching every old screen is not the bar. Matching the outcomes the business still needs is. Write the bar before the build. A bar written on the day of the switch is a negotiation, not a test.

Some cutovers still need a window

Some changes cannot be made while the old system is taking live writes. Say that at the start.

Example: a payroll file with one source of truth for a pay run. A stock count. A domain that only one host can answer. A step that cannot be split without two answers to the same question. Designing a mainframe displacement, Thoughtworks found identity rules that could not run in both places without the records drifting. Those were planned as a single cutover, not a flag.

Book a window. Tell the people who will feel it. Rehearse. Keep rollback short enough to finish inside the window. A window is not a failure of the plan.

GOV.UK warns against a changeover date that sits on a contract ending. If the new path slips, you should not be forced to renew the old arrangement because you left no room.

Decide the sequence before you build

Fernside can help you decide the sequence: which slice moves first, what “good enough” means, and which steps still need a window. That is scoping, not a rebuild of the stack. Advisory is the right place for it.

If a slice is already scoped, we can build that slice and leave the old path in place. We do not run a live cutover and promise it will not interrupt you.

If the question is whether current tools can carry the next step, read when off-the-shelf is not enough. Once a new path is in use, monitoring is how you notice it drifting.

If you want the sequence decided before anyone builds, book a call.