The Application Modernization Decision Tree: Why Six Systems Matter More Than Sixty

The steering committee approved the modernization programme eighteen months ago. Since then, three systems have been assessed, one has been partially re-platformed, the original vendor has been replaced, and the board wants to know why the costs are higher than the business case said they would be. The answer, almost always, is that the programme tried to move too much at once and never had a clear method for deciding what needed to move at all. Application modernization is not a programme. It is a decision, applied selectively, to the systems where it will actually matter.

That distinction sounds obvious. It rarely is in practice. When an organisation decides to modernize, the instinct is to build a list of everything that looks old, hand it to a systems integrator with a modernization practice, and begin. The list is usually long. The budget, once the real costs emerge, is usually not enough. And the systems that most needed attention are often the ones that get deferred because they are complicated, politically sensitive, or both.

The discipline that changes outcomes is a decision tree applied before a single line of architecture is drawn. It asks a small number of questions about each system, in order, and routes the system to one of four destinations: invest, re-platform, integrate, or leave it alone. Apply that tree honestly to a typical estate of sixty applications and you will find that modernization is the right answer for somewhere between four and eight of them. That is not a failure of ambition. It is what the evidence looks like when you stop letting the shape of a programme drive the conclusions.

What is application modernization, and what does it actually involve?

The word "modernization" carries a lot of freight. Vendors use it to mean anything from moving a workload to the cloud to rebuilding an application from scratch in a newer language. Those are genuinely different things with genuinely different cost profiles, risk profiles, and timelines. Conflating them is how a business case that looked reasonable at approval becomes a budget overrun by delivery.

A useful working definition has three parts. First, an inventory: what systems exist, what they do, who depends on them, and what it costs to keep them running. Second, a diagnosis: for each system, is the cost of change acceptable, is the system blocking something the business needs to do, and is the underlying architecture still supportable? Third, a routing decision: based on the diagnosis, the system goes to one of four destinations.

Invest means the system is strategically important, change is frequent, and it deserves proper engineering attention - better architecture, reduced coupling, more testability. Re-platform means the business logic is sound but the infrastructure is not - move it, do not rewrite it. Integrate means the system does something specific well and should be connected differently to the systems around it, rather than replaced. Leave it alone means none of the above conditions are met, and touching it creates more risk than value.

The fourth option, leaving it alone, is where most modernization programmes leave money on the table by ignoring it. A system that has not changed in four years, costs £40,000 a year to run, and has no active change requests is not a problem that needs solving. It is infrastructure. Modernizing it spends money, introduces risk, and produces a newer version of something nobody was asking for.

Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) has been used for application portfolio management since the mid-2000s and covers broadly the same logic. The specific labels matter less than the discipline of routing every system to exactly one of a fixed set of outcomes, explicitly, before any work begins.

Which systems in a typical estate genuinely need application modernization right now?

This number surprises people. The assumption, particularly in organisations that have been accumulating technical debt for a decade, is that everything needs to be fixed and the question is only about sequence. That assumption drives the kind of programme that runs for three years, spends twice the original budget, and delivers partial results that are hard to explain to anyone who was not inside the project.

The honest analysis starts by asking two questions about each system independently, then combining the answers.

The first question is about business criticality. Is this system in the path of something the business needs to do more of, faster, or differently? Not "is it important" in a general sense - almost every system someone built felt important at the time - but specifically: is a decision being deferred, a product being delayed, or a customer being failed because of what this system cannot do?

The second question is about architectural constraint. Is the system's current design preventing the change the business needs? This is different from the system being old. A system built fifteen years ago on stable, well-understood technology, with clean interfaces and a team that knows it well, is not constrained in any meaningful sense. A system built five years ago on a framework that has since been abandoned, with no test coverage and logic distributed across twelve dependent processes, is constrained even though it is recent.

Where both answers are yes - high criticality and genuine architectural constraint - modernization earns its cost. Everywhere else, one of the other three routes is correct.

The Standish Group's CHAOS research is worth citing here, with the methodology stated clearly. The CHAOS reports measure project resolution (successful, challenged, or failed) against project size and complexity. The consistent finding across multiple editions is that larger projects fail at substantially higher rates than smaller, focused ones. The 2020 report found that projects classed as "large" had a success rate of approximately 11%, compared to around 62% for projects classed as "small". These are not controlled studies and the classification thresholds have shifted over time, but the directional finding is stable and matches what practitioners observe. Scope is the variable that most reliably predicts failure, and a modernization programme that takes on sixty systems is not more ambitious than one that takes on six - it is more likely to fail.

How does the modernization decision tree work in practice?

The tree is not complicated. Its power is in the discipline of applying it to every system before any modernization conversation begins, rather than starting with a list of "legacy" systems and working backwards to a justification.

Question one: Does this system still have a function the business actually uses? If the honest answer is no, the system should be retired. Not assessed, not re-platformed, not modernized. Retired. Organisations routinely run systems that serve fewer than a handful of active users, produce reports nobody reads, or support a process that has been replaced informally by a spreadsheet. The cost of these systems is not just the licence fee; it is the security patching, the access management, the occasional support call, the cognitive load of including them in every compliance review. Retiring them is not modernization. It is simpler than that.

Question two: Is the business logic inside the system worth keeping? Some systems do something genuinely specific that would be expensive to replicate. Others are running a process that has been superseded, or contain rules that nobody can explain and that may no longer apply. If the business logic is not worth keeping, retirement or replacement is the route. Re-platforming a system onto modern infrastructure when the underlying logic is wrong just makes the error faster and cheaper to run.

Question three: Is the problem the infrastructure or the architecture? These need separate answers because they have separate solutions. A system running on an unsupported operating system that is otherwise well-structured can often be re-platformed - moved to supported infrastructure, perhaps containerised - without touching the application code. That is a fraction of the cost and risk of a rebuild. If the architecture itself is the problem, with logic distributed across hard-to-change components, tight coupling, no testability, then re-platforming does not help. The rebuild conversation is then warranted, with eyes open about what that costs.

Question four: Is this system blocking something specific right now? Not "could it theoretically limit us" but is there a named capability, product, or process that cannot proceed because of what this system cannot do? If the answer is yes, that system belongs on the modernization shortlist. If the answer is no, invest the modernization budget in a system where it is.

The systems that clear all four gates form the shortlist. In a sixty-system estate with a decade of accumulated technical debt, that shortlist will typically contain somewhere between four and eight systems. The rest route to retirement, re-platform, integrate, or leave alone.

What do the strangler fig and other modernization patterns tell us about risk?

Martin Fowler's description of the strangler fig pattern is worth reading by any executive who has been told that a core system needs to be replaced. The name comes from a fig species that grows around an existing tree, gradually taking over its function until the original tree is no longer needed. The software equivalent builds new functionality alongside the old system, routes increasing traffic to the new components, and retires the old one when it has been fully displaced.

The appeal is obvious: you are never fully committed to the new system before it has proved itself, and you are never fully dependent on the old one after the new one is working. The risk of a big-bang replacement - where the new system goes live on a date and the old one is switched off - is spread across a longer period and many smaller decisions.

The pattern works when the existing system has clear, stable interfaces that can be intercepted. If a system exposes its data through a well-defined API, or if the interactions between it and the systems around it are well-documented and predictable, the strangler fig approach is practical. If the system is deeply entangled - shared databases, undocumented dependencies, processes that reach directly into its internals - the pattern is much harder to execute and the risk does not reduce as quickly as the theory suggests.

This is not an argument against the pattern. It is an argument for assessing the entanglement before choosing the approach. An organisation that selects a modernization pattern based on what is currently fashionable in engineering circles, rather than what the specific system's architecture makes viable, will often find that the pattern creates as many problems as it solves.

The other frequently cited pattern is the parallel run: running old and new systems simultaneously against the same inputs and comparing outputs. This works well for systems where correctness is easy to verify, such as financial calculations or report generation. It is expensive in infrastructure terms and requires discipline to wind down. It is not an approach that suits systems where the outputs are inherently variable or where the old system's behaviour is itself the question being investigated.

The honest observation is that the modernization approach only becomes a productive conversation after the modernization decision has been made, using the decision tree. Choosing a pattern before choosing which systems to modernize is putting implementation ahead of strategy, and that sequencing is one of the more reliable predictors of a programme that runs long and delivers less than it promised.

When is the right answer to leave the system alone?

This is the recommendation that advisory relationships built on "we will also build the replacement" find difficult to make. If a firm's revenue comes from modernization projects, the finding that most systems should not be modernized is commercially inconvenient. That structural conflict of interest is not a character flaw; it is simply what the incentive structure produces. It is worth understanding it before you commission the assessment.

For a genuinely independent assessment, "leave it alone" should appear as a formal recommendation for a substantial proportion of the estate. What that proportion looks like depends on the organisation, but in a fifty-system estate that has not been systematically reviewed, it is not unusual for twenty to thirty systems to receive that recommendation. Some will be candidates for retirement. A smaller number will be candidates for re-platforming. The modernization candidates are the minority.

The case for documenting the "leave it alone" recommendation explicitly, rather than simply not mentioning certain systems, is straightforward. It creates a dated record of a deliberate decision. It prevents the systems from being swept into future modernization conversations on the basis of their age rather than their condition. And it establishes a review trigger - the recommendation stands until one of the four gate questions changes its answer, at which point the system is reassessed.

A modernization programme that documents what it will not do is more credible than one that promises to fix everything. The board has usually seen the promise-everything version before. The selective, reasoned, documented version is harder to dismiss.

Konnectedly's work is built on the premise that the most useful thing an adviser can do is tell an organisation which systems to leave alone, alongside which ones genuinely need attention - and that this recommendation is only credible when the adviser has nothing to sell on the back of a "modernize everything" conclusion.

Frequently Asked Questions

What is application modernization?

Application modernization is the process of evaluating what a system currently does, what it costs to run and maintain, and deciding whether to rebuild it on current technology, re-platform it onto different infrastructure, integrate it differently with surrounding systems, or leave it alone. The decision precedes any technical work. Most programmes falter because the decision is skipped and the build begins.

How do you decide which systems to modernize first?

Identify the systems where cost of change is high, business criticality is high, and the current architecture is actively blocking something the business needs to do. That intersection is small. In a typical estate of sixty applications, rarely more than five or six systems sit at that crossroads at any given time. Start there, and route everything else to a different outcome.

How long does an application modernization assessment take?

A focused assessment of an estate - cataloguing systems, scoring them against cost, criticality, and change frequency - typically takes four to eight weeks for an estate of thirty to eighty applications. Larger estates with poor documentation take longer, but the first useful output, the shortlist of systems that actually need a decision now, can usually be produced within three weeks.

What does application modernization cost?

The assessment itself, done by an independent adviser, typically costs between £30,000 and £120,000 depending on estate size and documentation quality. The modernization work that follows varies widely: re-platforming a mid-tier system might cost £200,000 to £800,000; rebuilding a core transaction system can run into the millions. The assessment exists to ensure that money goes to the right system.

What is the difference between application modernization and application rationalization?

Rationalization asks how many systems you need and which ones to retire. Modernization asks how the systems you are keeping should be rebuilt or re-platformed. Both are part of the same portfolio review, but they answer different questions. Rationalization often comes first: there is no point modernizing a system that should be switched off.

Why do most application modernization programmes fail?

The most commonly cited reason is scope. Programmes that attempt to move an entire estate simultaneously almost always stall, overspend, or deliver something that does not match what the business needed by the time it arrives. The Standish Group's CHAOS research consistently shows that larger IT projects fail at higher rates than smaller, focused ones. Limiting modernization to the systems that genuinely need it is not a compromise - it is the success condition.

Should every old system be modernized?

No. A system that is stable, well-understood, cheap to run, and not blocking anything does not need to be touched. The age of a system is not a decision criterion on its own. Some fifteen-year-old systems are running cleanly on supportable infrastructure with no meaningful change demand. The honest recommendation for those systems is to leave them alone, stated explicitly and reviewed on a schedule.

What is a strangler fig pattern in application modernization?

The strangler fig pattern, described by Martin Fowler, involves building new functionality alongside an existing system and gradually routing traffic away from the old one until it can be retired. It reduces the risk of full replacement by making the transition incremental. It works well when the old system has clear, stable interfaces. It works poorly when the system is deeply entangled with the architecture around it.