Writing

Replace constraints, not everything

I keep running into the same tension on modernization programs: the team responsible for replacing a legacy system still has to keep that system running. The old system cannot be switched off while the new one is being built. Support tickets still arrive, batches still run, and regulatory reports still go out on schedule. That operational reality shapes every decision about what to change first.

The default response is still often rip-and-replace. A large legacy estate gets treated as a problem to be cleared, as if the goal were to eliminate old technology rather than to improve how the business operates. That framing feels decisive, but it usually ignores the cost of doing the replacement while the old system remains in service. Rip-and-replace also assumes that the organization can absorb the disruption, which is rarely true when the system is critical.

Not every old system is a constraint. Some are just old. They may be unfashionable, hard to hire for, or inconvenient to maintain, but they still do their job. They process transactions, keep records, and support the business without measurably limiting it. Calling every old system a problem confuses age with harm.

The systems worth replacing are the ones that are actually limiting the business. The test should be concrete: where is speed a problem? Where is cost out of line? Where is risk becoming dangerous? If you can measure the constraint in one of those terms, you have a reason to modernize. If you can't, you probably have a preference, not a case.

Measurable does not mean perfectly quantified. It means you can point to a delay, a cost, or a failure that the business would recognize as a problem. If the argument for replacing a system rests on the phrase 'it's old,' that is not a constraint. It is an opinion about technology.

This is not a subtle argument for avoiding modernization. It is an argument for sequencing it around operational reality. A replacement program has to run alongside the system it is replacing. That means every change competes for people, budget, and attention with the work of keeping the old system healthy. Ignoring that competition is how modernization efforts fall behind.

When you treat modernization as triage, you make the hard choices earlier. You identify the few systems that genuinely hold the business back, and you leave the rest alone until the constraint shifts. Once the first constraint is removed, something else becomes the limiting factor, and the sequence continues. The order of work is driven by operational impact, not by age or personal preference.

That approach changes the conversation from 'which systems are old?' to 'which systems are blocking something measurable?' It also sets expectations: the goal is not a clean sweep. The goal is a smaller set of high-value replacements, delivered while the business keeps operating. That is easier to defend and easier to staff than a wholesale modernization program.

A recent piece titled 'Modernization without disruption: Rethinking the rip-and-replace mindset' makes a similar case. It reinforces the idea that the path through legacy modernization is not to ignore operational reality, but to plan around it. The title is a good summary: modernization without disruption, not modernization as disruption.

The core idea is simple enough to write down and hard enough to practice: replace constraints, not everything. If more modernization programs started there, they would spend less time arguing about which technology is modern and more time improving the business. That is the point of the exercise, and it is easy to lose.

Originally covered at cio.com ↗