Legacy technology is easy to describe and difficult to define. Age alone is a poor test. A long-established system may be stable, understood and appropriate for the service it supports. A newer platform may already be expensive, brittle or hard to govern.

The useful definition is operational: a system has become a material legacy constraint when the cost and risk of maintaining its service increasingly limit the firm’s ability to meet customer, regulatory and strategic needs.

For a financial services leadership team, the important number is therefore wider than the infrastructure line in the technology budget. It includes manual control work, integration failure, compensating security measures, scarce expertise and the effect on important business services.

That total may support replacement. It may support containment, simplification or selective modernisation instead. The analysis should discover the answer rather than begin with it.

The keeping-the-lights-on trap

The source article captured a recurring leadership problem in one CTO’s description of having a multi-million-pound budget and only a small portion of real freedom. Whether or not that ratio applies elsewhere, the judgement behind it is valuable: a large technology budget can conceal very little capacity for change.

Measure committed expenditure and committed effort separately. The first includes licences, hosting, vendor support and contracted maintenance. The second includes internal work required for incidents, reconciliation, patches, access changes, regulatory requests and fragile deployments.

Then ask what drives the trend. Support prices may increase. A product may approach end of support. Knowledge may concentrate in a few people. Each new connection may add testing and failure modes. These are evidence-based reasons to expect cost growth. A generic claim that all legacy costs compound every year is not.

The trap appears when familiar, distributed costs are treated as safe while the visible cost of change receives all the scrutiny. Both positions have risk. Financial services firms need a comparison that covers the current estate, the transition and the target operating model.

Six cost categories for a financial services assessment

1. Maintenance labour and supplier cost

Map the people and contracts needed to keep the service available. Include specialist support, routine fixes, testing, monitoring, batch operation, release work and the management of obsolete components.

Avoid assuming every maintenance hour would disappear after modernisation. New platforms require operation, upgrades and specialist attention too. Compare current effort with a credible target-state support model.

Useful evidence includes invoices, time records, service tickets, change lead times and the proportion of planned capacity displaced by urgent work. Where records are poor, sample several representative periods instead of inventing an annual percentage.

2. Compliance and control workarounds

Some firms rely on people to move, reconcile or reformat information because systems cannot produce a reliable control or regulatory output. Those employees may be performing essential judgement as well as repetitive work, so a headcount total will overstate what automation can remove.

Document each workaround as a process: input, transformation, review, correction, approval and evidence retained. Measure volume, time, errors, rework and dependence on key individuals. Identify the control purpose before proposing automation. A faster process that weakens assurance is not a saving.

The relevant compliance, finance and risk specialists should determine what evidence and oversight must survive a system change.

3. Integration failure and data latency

Legacy costs often appear between systems. Batch schedules delay information needed by a customer service. Interfaces fail during a reporting period. Teams maintain spreadsheets because records disagree.

Build an integration register that records ownership, criticality, frequency, dependencies, incident history, recovery steps and the business service affected. Include the management time and downstream correction caused by failures, not merely the engineering fix.

Real-time integration is not automatically superior. Some processes are safer and more economical in controlled batches. The decision should follow the service need, tolerance for delay and failure behaviour.

4. Security and resilience controls

Unsupported software, difficult patching and weak observability can increase exposure. So can a rushed migration, a poorly configured cloud service or new supplier concentration. Ask security and operational-resilience specialists to assess both current and transition states.

The FCA describes operational resilience as the ability to prevent, adapt and respond to, recover and learn from disruption. Its current operational resilience material sets out requirements for firms in scope, including important business services, impact tolerances, mapping, testing and investment in remediation. Applicability varies, and the relevant rules and guidance should be checked for the firm.

Connect technical weakness to an important service and a tested scenario. “The platform is old” is weak risk evidence. “Recovery testing shows this dependency prevents the service returning within its impact tolerance” is actionable.

Include the cost of compensating controls such as additional monitoring, manual review, restricted change windows or duplicated infrastructure. These costs may be justified. Their presence still belongs in the current-state model.

5. Scarce knowledge and talent concentration

The concern is wider than the age of the people maintaining a system. It is the concentration of critical knowledge, the availability of support and the organisation’s ability to recover when somebody leaves.

Measure bus-factor risk, documentation quality, recruitment time, contractor dependence, succession, on-call pressure and the extent to which skilled people spend their time on work the firm intends to continue. Interview the team. Some supposedly obsolete technologies have healthy ecosystems; some modern stacks are difficult to recruit for in a particular location or sector.

Do not treat all salary difference as a “legacy premium”. Role scope, scarcity, employment model and market conditions also affect cost.

6. Regulatory and customer consequence

Connect system constraints to outcomes: delayed access to funds or information, inaccurate reporting, poor complaint handling, inaccessible journeys, weak records, slow product change or difficulty meeting a new obligation.

Use incidents, near misses, control findings, customer research and operational data. Keep direct evidence separate from scenarios. Legal or regulatory exposure should be assessed by qualified specialists rather than inferred from the technology’s age.

This final category prevents the assessment from becoming a technology-maintenance exercise. The estate matters because of the services and obligations it supports.

Build a board case without borrowed percentages

Start with a current-state cost map. For every material system, show:

  • the business services and customer journeys it supports;
  • annual cash cost and internal effort;
  • critical integrations and manual workarounds;
  • security, resilience and compliance findings;
  • concentration and end-of-support risks;
  • expected changes over the decision period; and
  • evidence quality.

Next model credible options. These may include continuing with additional controls, reducing customisation, retiring a low-value service, isolating a fragile component, replacing one layer, introducing an interface around a stable core or moving to a new platform.

For each option, include transition cost and risk, dual running, data and control reconciliation, supplier due diligence, training, customer communication, decommissioning and the target support model. Modernisation benefits should be tied to a named change. A new platform will not remove a manual process whose underlying policy remains unchanged.

Use low, central and high estimates only where assumptions can be stated. Keep overlapping cost categories from being counted twice. For security and regulatory scenarios, show the basis and confidence rather than inserting a generic breach cost or enforcement probability.

Finally, show the cost of waiting for one, two or three decision periods. Some components may stay stable; others may reach a contract, support or resilience threshold. Model those events instead of applying an automatic escalation rate.

Phase around services and risk

“Replace everything” creates an understandable board objection. A phased path can reduce the amount of simultaneous change, though it may introduce interfaces, dual running and a longer period of transition. Those costs belong in the plan.

Select a phase using evidence:

  • the service whose impact tolerance is hardest to meet;
  • a component approaching a support or contract boundary;
  • a manual control with high volume and error consequence;
  • an integration whose failure repeatedly affects customers or reporting; or
  • a bounded area that can prove the target operating model.

Define the value released by the phase and decide where it goes. Savings do not automatically fund the next stage. Contracts, roles and budgets may need to change before cash or capacity becomes available.

At every boundary, retain a decision gate. Evidence may support continuing, changing sequence, extending the life of a stable component or stopping. A roadmap that assumes every legacy system must eventually be replaced can become as rigid as the estate it is meant to improve.

Start with the current cost, not a transformation slogan

The first step is a legacy cost assessment owned jointly by technology, operations, finance, risk and the relevant business-service leaders. The exercise should reveal where cost sits, which constraints matter and how confident the firm is in the evidence.

The Replatform Reckoning provides additional platform end-of-life context. Its figures and vendor timelines should be checked at the point of use because products, support policies and prices change.

Our downloadable legacy cost assessment framework covers maintenance labour, compliance workarounds, integration failure, security exposure, talent concentration and regulatory risk. Use it to compare options, including a managed decision to retain a system. The board’s question is not whether old technology is inherently bad. It is whether the current estate remains the best-supported way to deliver important services within the firm’s obligations and tolerances.