Start with the current system, not the assumed design

Most businesses running legacy systems cannot afford to replace everything at once. Prioritisation is the process of deciding which system, component or workflow to address first, and which can wait. The challenge is that urgency and importance rarely align neatly: the system screaming loudest for attention is not always the one with the greatest long-term impact on the business.

Prioritisation sits between two related but distinct activities. A risk assessment identifies what could go wrong and how severely. Budgeting determines what you can afford to address. Prioritisation, by contrast, is about sequencing: given what you know about risk and what you have available to spend, where do you start to get the strongest return with the least exposure?

A useful starting frame is to evaluate each legacy component against four questions:

  • Business criticality. What happens to revenue, service delivery or compliance if this system fails or degrades further?
  • Operational pain. How much manual effort, workaround activity or error correction does this system force on staff each week?
  • Blocking effect. Is this system preventing other planned work, such as a new integration, a regulatory change or a product launch?
  • Supply-chain risk. Does the system depend on software versions, hardware, libraries or skills that are approaching end of life or becoming difficult to source?

No single factor should dictate the order. A system with low business criticality but extreme blocking effect might deserve earlier attention than a critical system that is stable and well supported. The purpose of prioritisation is to make these trade-offs explicit so that the business, not individual departments, sets the sequence.

Revenue-handling and compliance-critical systems

Systems that process transactions, manage client money or produce regulated reports usually warrant early attention even when they appear stable. The risk here is not day-to-day failure but the compounding cost of being unable to adapt. If a pricing change, a new tax rule or a reporting requirement arrives and the system cannot accommodate it without weeks of manual work, the modernisation case is already strong.

Systems that force manual workarounds

An internal portal that requires staff to re-key data into a spreadsheet, or a document workflow that relies on email attachments and manual filing, represents a different kind of priority. The business is not at immediate risk, but it is paying a recurring operational tax in wasted hours and avoidable errors. Quantifying that cost, even approximately, provides a basis for comparing this work against other candidates.

Systems blocking integrations or new capabilities

A CRM that cannot connect to a newer billing platform, or a legacy order-management system that cannot expose data via an API, can stall multiple downstream projects. In these cases, modernising the blocking system unlocks value elsewhere. The prioritisation logic is not about the system itself but about the portfolio of work it constrains.

Systems dependent on scarce skills or unsupported software

If only one person understands a system, or if it runs on a framework with no security patches, the clock is running regardless of business impact. Prioritisation here involves estimating how long the current support arrangement can realistically continue and what the cost of an unplanned failure would be. A system that is non-critical today but unmaintainable within twelve months may need to move up the list.

Low-priority candidates

Systems that are stable, lightly used, well understood and not blocking other work are often better left alone or addressed with minimal intervention, such as containerising an existing application rather than rebuilding it. The mistake is to modernise these first because they seem easy, while deferring the difficult systems that actually matter.

Prioritising by age rather than impact

There is a persistent assumption that the oldest system must be the worst. In practice, a ten-year-old system with a clean data model and a stable user base may be in better shape than a three-year-old one built with rapid prototyping tools and no documentation. Age is a signal, not a criterion. Evaluate what the system does and how it behaves, not when it was written.

Starting with the easiest target

Tackling a low-value system first can produce a quick win for the project team but does little for the business. It also consumes budget and time that could have reduced a more significant risk. If a quick win is needed for organisational confidence, treat it as a separate decision and be clear about what is being sacrificed.

Ignoring dependencies between systems

Modernising one system can break an integration with another. Before committing to a sequence, map the data flows and shared infrastructure between legacy components. If System A feeds System B, and both need work, the order matters: modernising B first may require building a temporary adapter to A, adding cost and complexity.

Treating modernisation as a purely technical decision

Operations managers, compliance staff and frontline users often know more about where the real pain lies than the development team. A prioritisation exercise that happens only within the technical function will miss operational context and may produce a sequence that looks rational on a diagram but causes disruption in practice.

Limitations of any prioritisation approach

No prioritisation method eliminates risk. It only sequences it. A well-prioritised programme can still encounter unexpected data-quality problems, supplier delays or regulatory changes that force a re-order. The value of the exercise is not a perfect plan but a shared understanding across the business of what is being addressed, why, and what has been deliberately deferred.

Key checks before committing to a sequence

  • Can you access the source code, databases, infrastructure credentials and deployment pipelines for each system under consideration? If not, resolve access before prioritising, because unknowns in these areas can change the effort estimate dramatically.
  • Has someone with operational responsibility validated the claimed pain points and blocking effects? Technical assumptions about what matters should be checked against the people who use the system daily.
  • Are there contractual constraints, such as a support agreement with a third party or a regulatory filing deadline, that impose a minimum or maximum timeline for certain work?
  • Is there a clear, documented rationale for why items lower on the list are being deferred, so that the decision can be revisited if circumstances change?

Turn the assessment into a controlled next step

Once the sequence is agreed, the next practical step is to understand what each piece of work will cost and how to structure a budget that accounts for the uncertainties inherent in legacy code. That is a separate exercise, but it depends on having a defensible prioritisation in place first.