Before You Modernise, Decide What the System Is For Now
· Daniel Șotropa
Deciding what to keep is the first step of any build. An old system is not automatically a modernisation problem, and a technically healthy system may still support a role the organisation no longer needs.
That is why the first modernisation question should not be which framework, platform or architecture will replace the current one. It should be simpler: what must this system do for the organisation now?
Without a shared answer, technical evidence has nothing useful to attach to. Unsupported dependencies, slow releases and fragile integrations may all be real, but they do not tell a leadership team how much change is justified. They describe the system’s condition, not its future role.
The distinction matters because different roles deserve different investments. A system expected to carry a changing, commercially important capability needs a different route from one that must remain stable for three years while customers move elsewhere.
Age is a signal, not a decision
Modernisation discussions often begin with a list of weaknesses: old technology, scarce skills, manual deployment, rising support effort or a backlog that moves too slowly. Those signals deserve attention. They still do not make a rewrite inevitable.
The usual binary — replace it or continue living with it — hides several responsible options. A team might renew the parts that constrain delivery, contain a stable component behind a clear interface, replace a commodity capability, or retire a system in stages. More than one route may apply inside the same estate.
The wrong starting point turns a business decision into a technology programme before the organisation knows what outcome it is funding. Once a target architecture, supplier or delivery team has been selected, it becomes much harder to ask whether the work should exist at all.
Give the system a future role
A useful first step is to place the system — or each major capability within it — into one of four roles.
1. A strategic engine
The system supports a capability that differentiates the organisation or materially affects revenue, service quality or the ability to respond to change. It will need to evolve, and the current design makes that evolution slow or risky.
This role can justify substantial investment. Even then, the case is not “the technology is old”. The case is that an important capability cannot change at the pace or level of control the organisation needs.
2. An operational utility
The system performs necessary work, but that work is not a source of differentiation. Reliability, predictable cost and clear ownership matter more than rapid product evolution.
The smallest responsible answer may be stabilisation: improve tests at the boundaries, remove an urgent support risk, document recovery and reduce the cost of routine change. Replacing a dependable utility with a more fashionable platform can destroy value without improving the operation.
3. A transitional bridge
The system must keep part of the operation running while a product, process, acquisition or replacement platform develops around it. Its job is to preserve continuity and make the eventual exit safe.
Investment should serve that transition. Clear interfaces, reliable data movement and controlled coexistence may matter more than internal elegance. Incremental displacement patterns can help when old and new capabilities must operate side by side; Martin Fowler’s description of the Strangler Fig Application is one established example.
4. A retiring asset
The capability is disappearing, consolidating elsewhere or approaching a defined end. The priority is not modernisation but an orderly exit: protect required data, maintain essential access, reduce operational exposure and avoid adding dependencies that make retirement harder.
Some work may still be necessary. That does not make the system a candidate for renewal.
Establish the evidence before choosing the route
Naming the future role creates a hypothesis. The next step is to test it against the working system and the operation around it.
Five forms of evidence usually make the decision clearer:
- Change demand: Which capabilities change frequently, and which are largely stable?
- Delivery friction: Where do releases slow down, fail or require disproportionate coordination?
- Operational exposure: Which incidents, manual interventions or unsupported components create material risk?
- Dependencies and data: What must continue to integrate, reconcile, retain or report during the change?
- Team ownership: Who understands the system, who will operate the result and what change can the team realistically absorb?
This evidence does not need to become a year-long discovery exercise. It needs to be good enough to distinguish a systemic constraint from a local problem and a permanent need from a temporary one.
It may also show that the system has several futures. A frequently changed customer journey might deserve renewal while a stable calculation component is contained and a redundant reporting path is retired. Treating the estate as one indivisible object is often what makes modernisation appear too large to control.
Choose by constraint, not by age
Once the future role and evidence are visible, the delivery route becomes more defensible.
Renew incrementally when a valuable capability must keep changing and the current system prevents it. Start with one bounded slice that can prove the architecture, release path and adoption approach before expanding commitment.
Stabilise and contain when the capability remains necessary but change demand is limited. Protect the interface, test the behaviours others depend on and remove the risks that could interrupt the operation. Leave the rest alone deliberately.
Replace when the capability is necessary but not differentiating, and a proven product or service can meet the requirements with an acceptable ownership and transition model. The migration of data, process and accountability is part of the replacement decision, not an implementation detail.
Retire when the capability no longer deserves an ongoing system. Define the exit conditions, preserve what must remain accessible and stop investing in improvements that do not make retirement safer.
No route removes risk. The goal is to choose the risk that matches the system’s future rather than inherit the risk created by an undefined programme.
Sometimes the answer is not to modernise
If a system is stable, rarely changed and close to retirement, modernising it may consume more value than it creates. The responsible work may be better monitoring, one additional recovery test or a clearer boundary around who can change it.
The opposite is also true. Containment becomes neglect when the business expects substantial change but the team keeps postponing structural work. “Leave it alone” is defensible only when the future role, operating risk and revisit conditions are explicit.
Candour works in both directions: do not rebuild because the technology is old, and do not preserve it merely because replacement is difficult.
Write the decision before writing the programme
Before selecting a platform, supplier or migration pattern, complete this sentence:
Over the next planning horizon, this system exists to [support this capability]. It must continue to [protect this operation], and it does not need to [carry this responsibility].
If the leadership team cannot agree on that statement, an architecture workshop is premature. The next responsible step is to clarify the system’s role, the evidence that would change the decision and the smallest slice worth testing.
Once the role is written down, the work becomes concrete: a first useful version of whatever the system now needs to be, built alongside what must keep running. That build is the part Haiori takes on. If you are at the point of deciding what to keep, tell us about the system and we will start from there.