The most popular advice on legacy system replacement is to build a complete inventory, choose a single migration roadmap, and work through it in order. Large venues and transit operators rarely have that luxury. Their estates are fragmented, dependencies are poorly documented, capital is constrained, and the systems that look least modern aren't always the ones creating the greatest operational risk.

The practical question is narrower and harder: what should be replaced first when everything cannot be replaced at once? The answer should reflect service continuity, accessibility impact, cyber exposure, data dependencies, and the maintenance burden carried by the existing platform. For a stadium, railway, shopping centre, airport, campus, or hospital, that decision model is more useful than a broad promise to “modernise”.

Why Legacy System Replacement Is a Risk Problem Not a Tech Problem

A legacy platform becomes a board-level concern when its failure affects people, not merely architecture diagrams. A ticketing service that cannot process transactions, a passenger-information feed that cannot publish changes, or a wayfinding layer that leaves people unable to find an accessible entrance can turn technical debt into an operational incident.

The UK Government Digital Handbook defines legacy systems as systems that are impossible to update, too expensive or no longer cost-effective, or at the end of their supported life. It also warns that they can sit at the centre of cyber-breach incidents because they may not support standards such as Cyber Essentials. That makes replacement a question of risk allocation, not just technology preference. The UK Government Digital Handbook's guidance on legacy systems provides the useful test: assess whether the platform can still be updated, secured, supported, and operated at a defensible cost.

The public-sector evidence shows why a clean inventory cannot be assumed. A 2025 UK Parliament briefing said risky legacy IT represented 28% of the public sector's IT estate, while the government did not know the full number of legacy systems. By January 2025, 319 legacy systems had been identified and around 25% were red-rated for both high likelihood and high impact of risk. The UK Parliament briefing on cyber threats and government defences shows that the first management task is often discovery and prioritisation, not procurement.

Build a case finance can challenge

A credible business case should put each asset into an operational risk register with four questions:

• What fails if this system stops? Record affected services, staff processes, passenger flows, venue access, and contractual obligations.
• Who is disproportionately affected? Include disabled visitors, people with limited English, older passengers, and anyone relying on real-time information.
• What does the platform consume while it remains in service? Include specialist staff time, licences, support contracts, physical hardware, testing effort, and dual-running costs.
• What decision can the organisation afford? Distinguish urgent remediation from full replacement, and identify what can be isolated, wrapped, retired, or deferred.

This is also where reliability commitments matter. A replacement programme should state the service level it must protect, the rollback route, and the evidence required before cutover. Waymap's uptime guarantee is a useful example of how reliability can be treated as an explicit service requirement rather than an informal expectation.

Practical rule: rank systems by the consequence of failure and the difficulty of safe recovery, not by age alone.

For Waymap's audience, that approach changes the conversation. An operator may not be able to replace every control system, database, or staff tool, but it can identify the assets that directly affect safety, continuity, accessibility, and public confidence. The replacement queue then becomes a funding decision the board can understand.

The Hidden Costs of Keeping Legacy Systems Running

Legacy costs rarely appear on one invoice. They are distributed across support teams, security remediation, procurement renewals, manual workarounds, delayed releases, and the operational effort required to keep old and new services connected.

UK central government data estimated that legacy technology accounted for about 28% of systems in 2024, up from 26% in 2023, and associated lost productivity at 4% to 7% of annual public-sector spending. The Register's report on UK government legacy technology also describes data as the biggest barrier to replacement. Organisations commonly underestimate the work required to find authoritative sources, remove duplication, and identify every dependent service.

Measure the cost that never reaches the project ledger

A finance director needs more than a replacement price. The baseline should include:

• Run costs: support contracts, licensing, hosting, specialist engineering, patching, and physical infrastructure.
• Delay costs: manual reconciliation, slow change approval, repeated testing, and postponed service improvements.
• Risk costs: exposure created by unsupported components, weak audit trails, and systems that cannot meet required controls.
• Transition costs: data cleansing, integration work, training, parallel operation, and decommissioning.

The National Audit Office has warned that poor migration paths can force old and new systems to run side by side. That arrangement increases licensing costs, complicates processes, and makes it harder to create a unified view of clients or services. The National Audit Office reporting on legacy ICT risks supports a simple modelling principle: dual-running is a planned cost, not an exception.

Treat security, compliance, and AI as connected costs

The UK Government's 2025 digital review said underinvestment increases long-term costs and that maintaining legacy systems can cost three to four times as much as modern alternatives. A late-2025 UK survey reported that 61% of organisations said legacy Windows systems were blocking AI adoption, 84% found AI integration with their legacy stack challenging, and 48% had faced compliance issues during audits. The UK coverage of legacy systems blocking AI and compliance progress places these issues together: old systems can restrict innovation while making evidence, controls, and audit responses harder to manage.

The point isn't that every organisation should replace legacy technology to pursue AI. It is that the business case should state what the existing platform prevents the organisation from doing, whether that means updating accessibility information, integrating a new service, producing reliable audit evidence, or responding to cyber risk.

The UK Government's Blueprint for Modern Digital Government adds a further warning. The number of highest-risk and most critical systems increased by 26% from 2023 to 2024, indicating that remediation has not kept pace with risk. A replacement case should therefore show both the cost of action and the cost of leaving the exposure in place.

How to Prioritise Which Legacy Systems to Replace First

Start with dependency mapping, not vendor demonstrations. The UK evidence base says organisations often underestimate the work needed to discover authoritative data, duplication, and dependent services. If the team doesn't know which passenger-information feed, access-control database, or venue map supplies another service, a replacement sequence can create failures that weren't visible in the original plan.

Use a simple decision model with three core dimensions. Score each asset consistently, then add a dependency modifier for systems that sit beneath many other services.

Score operational consequence

Ask what happens during an outage and how quickly the organisation can recover. A payment service may stop revenue collection, while a staff scheduling tool may create administrative pressure without immediately stopping public access. A passenger-information platform can sit between those examples if inaccurate or missing updates affect journeys, connections, and confidence.

Score accessibility and compliance impact

Accessibility should not be treated as a final acceptance test. Under the Equality Act 2010, service providers have duties relating to disabled people, and built-environment decisions are informed by standards including BS 8300 and BS EN 17210. The relevant question is practical: if this system fails or remains inflexible, can people find entrances, platforms, toilets, lifts, assistance points, and other destinations with equivalent confidence?

For a venue or transit operator, a static sign replacement may be less urgent than a digital information layer that cannot be updated when routes, entrances, or facilities change. Infrastructure-free navigation can be relevant where installing and maintaining beacons or other hardware across a high-footfall estate would create another legacy burden. Waymap uses device-native motion sensors and dead reckoning, rather than GPS, Wi-Fi, or installed hardware, to provide indoor, outdoor, and underground guidance. Its platform is designed to guide users to precise doors, platforms, and points of interest, including in environments where signal coverage is limited.

Score maintenance burden

Count the effort required to keep the asset operational. Include obsolete skills, difficult testing, manual data updates, hardware visits, supplier dependence, and the consequences of each change window. A system with moderate service risk but extreme maintenance burden may deserve earlier attention than a visibly old system that remains stable and well supported.

The matrix isn't a substitute for engineering discovery. It gives budget holders a transparent reason for sequencing decisions and creates a record of why one asset moved ahead of another. For the people and adoption dimension, Waymap's change-management strategy offers a relevant reference point for involving operational teams rather than treating migration as an IT-only event.

Choosing Between Wrap Replace and Modernise Strategies

There are three practical routes through a legacy estate: wrap, replace, or modernise incrementally. None is universally correct. The choice depends on the system's risk, the quality of its interfaces, the available maintenance windows, and whether the organisation can tolerate a prolonged transition.

Wrap the old system when time matters

Wrapping adds an interface, API, reporting layer, or user experience around an existing platform. It can make sense when the core system remains reliable, data access is understood, and the immediate problem is poor usability or integration. For a venue, a wrapper might expose existing information through a more accessible channel while the underlying system remains in service.

The risk is concealment. A wrapper doesn't remove weak security, brittle dependencies, poor data quality, or expensive support. It can also create another component that the team must maintain. Use it as a controlled bridge with an expiry condition, not as permission to postpone the underlying decision indefinitely.

Replace the system when its foundations are unsafe

Full replacement is appropriate when the platform cannot meet security requirements, cannot support necessary integrations, has no credible support path, or creates unacceptable continuity risk. It offers a clearer target architecture, but it demands the strongest discovery and migration controls.

Large venues and transit operators should be cautious about big-bang cutovers. The National Audit Office evidence cited earlier shows how poor migration paths can create costly parallel operation. A full replacement still needs staged data migration, rehearsed rollback, operational training, and a defined period in which the old service remains available.

Modernise incrementally when the estate is too connected to switch

Incremental modernisation changes selected components while preserving stable parts of the existing service. Teams can re-platform a database, expose a controlled interface, refactor a high-risk module, or replace one workflow at a time. This approach suits 24-hour operations where maintenance windows are short and dependencies are numerous.

A useful overview of the broader options is Refact's guide to modernization strategies for founders, particularly its comparison of replacement, re-platforming, re-hosting, and other migration paths. The key is to select the least disruptive route that removes the specific risk being funded.

Waymap's discussion of reliability, scalability, and maintenance for infrastructure-free wayfinding is relevant when a venue is deciding whether to add physical navigation hardware or adopt an updateable digital layer. Removing hardware from the replacement scope can reduce installation and maintenance dependencies, but it doesn't remove the need for accurate mapping, accessibility testing, data governance, and operational ownership.

Executing the Migration Without Breaking Operations

A sound strategy fails if procurement, frontline adoption, testing, and cutover are handled as separate workstreams. The programme needs one operating plan that connects them. Every requirement should answer three questions: who owns it, what evidence proves it works, and what happens if it doesn't.

Put procurement controls around the future exit

Contracts should require documented interfaces, exportable data, transparent service levels, security evidence, accessibility conformance, and practical exit assistance. Avoid replacing one opaque dependency with another. Ask suppliers to explain how the organisation will retrieve data, operate during degradation, and transfer knowledge if the relationship ends.

Data migration needs its own acceptance criteria. Waymap's data migration process identifies the operational sequence that matters for venues and transit: discover the source estate, profile data quality and dependencies, map source to target, cleanse and deduplicate, run dry tests, validate, plan cutover, and retire the old system only after the target is stable.

Test the service, not just the software

Technical testing should include interfaces, permissions, data reconciliation, failure modes, accessibility workflows, and realistic peak operating conditions. Frontline staff should test the tasks they perform, not merely confirm that a screen loads. Blind and partially sighted users should be involved in navigation and information testing where those services affect their journeys.

Unions, control-room staff, station teams, visitor-services colleagues, and contractors can identify risks that project documentation misses. Give them a route to report defects, explain which changes are fixed, and publish the operating procedure before cutover. Training should cover normal work, degraded service, escalation, and rollback.

For teams dealing with document stores and collaboration platforms, Ollo's guide to SharePoint migration from legacy platforms is a useful example of why content ownership, permissions, metadata, and validation need explicit treatment rather than a simple copy exercise.

The migration should include a rehearsed rollback plan, named decision-makers, and a defined point at which the team will stop cutover. Keep parallel operation as short as the risk evidence allows, because it protects continuity but increases cost and process complexity.

A practical cutover pack should contain:

• Operational readiness: trained staff, updated procedures, contact routes, and support coverage.
• Data confidence: reconciliation results, exception logs, and signed acceptance from service owners.
• Accessibility assurance: tested journeys, accessible content, alternative channels, and defect ownership.
• Rollback authority: clear thresholds, named approvers, preserved legacy access, and communications for users.

Measuring Success Beyond Cost Savings

A replacement project that only reports reduced licences has undercounted its value. The stronger measurement framework connects operational performance, accessibility, and environmental impact to the original risk case.

Operational measures should show whether the new service is easier to run. Track incident patterns, manual interventions, change effort, data-quality exceptions, recovery procedures, and the duration of any dual-running period. These measures tell the board whether the organisation has reduced dependence on fragile processes or moved them elsewhere.

Accessibility measures should be specific to real journeys. Record whether users can locate accessible entrances, lifts, platforms, toilets, assistance points, and service counters using current information. Test with disabled people, document defects, and link each result to the relevant duty or standard, including the Equality Act 2010, BS 8300, and BS EN 17210. Compliance is stronger when it is demonstrated through usable journeys rather than a statement that a system is technically accessible.

ESG measurement should also reflect what the project changed physically and operationally. If replacement removes installed hardware, reduce the maintenance visits, replacement parts, and estate-management tasks associated with that equipment. If it reduces duplicated infrastructure or paper-based processes, record the change through the organisation's existing sustainability method rather than claiming an unverified carbon saving.

Waymap's user retention metrics provide a useful reminder that adoption and continued use are part of service value. A navigation or information service isn't successful merely because it went live. People need to find it, trust it, and use it when they need assistance.

The final business case should therefore report four outcomes: risk reduced, service improved, access strengthened, and maintenance simplified. Cost savings remain important, but they shouldn't be the only evidence used to secure the next phase of funding.

Waymap provides infrastructure-free indoor, outdoor, and underground navigation using smartphone motion sensors and detailed maps, helping venues and transit operators guide people to precise doors, platforms, and points of interest without GPS, Wi-Fi, or installed hardware. Visit Waymap to assess how a dynamic, updateable wayfinding layer could fit into your phased legacy replacement plan.