Replace, Replatform or Integrate? How to Decide the Future of a Legacy Government System

Across government and the wider public sector, some of the most important services still depend on technology that was designed for a very different world. These systems may process benefits, manage casework, hold regulatory records, support social care, administer licensing, coordinate emergency services or underpin interactions that millions of people depend on.

Calling them “legacy systems” can make the problem sound straightforward. Old technology is assumed to be bad technology, and modernisation is assumed to mean replacing it with something newer.

The reality is much more complicated.

A system can be decades old and continue to provide a reliable, well-understood and economically sensible service. A system implemented only a few years ago can already exhibit many of the characteristics associated with legacy technology: high supplier dependency, poor interoperability, inaccessible data, excessive customisation, fragile interfaces and an inability to respond quickly to changing policy or user needs.

The age of a system is therefore rarely the most useful factor when deciding its future.

The more important question is whether the technology continues to support the organisation’s ability to deliver, change and operate safely.

When the answer begins to become “no”, public sector organisations broadly have three choices. They can replace the system, replatform or progressively modernise it, or retain it while integrating it more effectively with the rest of the organisation’s technology estate.

Each approach can be correct. Each can also be disastrously wrong.

Replacing a system unnecessarily can introduce enormous programme risk, disrupt critical services and consume years of investment without materially improving outcomes. Replatforming a fundamentally unsuitable application can simply reproduce yesterday’s problems on newer infrastructure. Integrating around a deteriorating system can extend its useful life, but it can also create an increasingly elaborate architecture designed to protect something that should have been retired.

The important decision, therefore, is not which modernisation strategy sounds most ambitious. It is which approach creates the best balance between public value, service continuity, technical sustainability and future adaptability.

Legacy is a business condition, not simply a technology problem

The most useful way to think about legacy technology is not as a category of software but as a set of constraints.

A system becomes problematic when the organisation is increasingly forced to work around it.

That might appear technically. Changes that should take days require months of analysis and regression testing. Releases become infrequent because nobody is fully confident about the consequences of altering the application. Dependencies are poorly documented. Only a handful of people understand critical parts of the codebase. Security patches become difficult or impossible to apply. Hardware, operating systems or software components move out of support.

But the consequences are rarely confined to IT.

Operational teams may compensate with spreadsheets, manual reconciliation, duplicate data entry or additional checking processes. Contact centres may handle enquiries that should be resolved through digital self-service. Policy teams may discover that apparently modest rule changes require disproportionate technology programmes. Data teams may struggle to extract reliable information. New digital services may need to ask citizens for information the organisation already holds because the underlying system cannot expose it safely.

Over time, the organisation begins to absorb the limitations of the technology into its operating model.

This is one of the most dangerous characteristics of legacy estates because the true cost becomes difficult to see.

The system’s support contract may appear affordable when examined in isolation. Yet its total cost includes the staff required to operate inefficient processes, the additional applications built around it, specialist support contracts, manual work, reconciliation, duplicate data stores, delayed policy implementation, unavailable management information and opportunities that cannot be pursued because the technology cannot support them.

This is why decisions about legacy technology should begin with the service rather than the application.

Ask what the organisation is trying to achieve over the next five to ten years. How will citizen expectations change? What policy changes are plausible? Which processes should become more automated? Where will data need to move? Which services need to become joined up? How quickly must the organisation respond when circumstances change?

A system that works adequately for today’s process may still be a major strategic constraint if it prevents tomorrow’s service from being created.

Cyber security adds another dimension.

Older applications frequently depend on components that are difficult to patch, poorly understood integrations, unsupported software or infrastructure that cannot easily adopt modern security controls. Skills shortages can compound this problem as specialists familiar with particular technologies retire or leave the market.

But replacing an application is not automatically the safest response. Large-scale migration introduces its own security and operational risks. A stable system with known weaknesses and compensating controls may temporarily represent less risk than a rushed replacement involving significant data migration, unfamiliar technology and a new operating model.

Modernisation should therefore be based on an explicit understanding of risk rather than an assumption that new equals safe and old equals dangerous.

The same principle applies to suppliers.

A legacy application supported by one long-standing supplier may create obvious dependency. However, replacing it with a heavily customised commercial platform, proprietary cloud environment or new managed service can simply exchange one form of lock-in for another.

The goal should not be to eliminate suppliers. Government will always rely on specialist technology providers. The goal is to retain sufficient organisational knowledge, contractual flexibility, technical visibility and control that the service remains manageable if the supplier relationship changes.

A useful test is surprisingly simple: if the current supplier disappeared tomorrow, how much would the organisation actually know about how the service works?

If the answer is “not enough”, supplier dependency is already part of the legacy problem.

Replace, replatform or integrate: what each option really means

Replacement is the option most commonly associated with legacy modernisation.

At its simplest, the existing application is retired and its functions are delivered by a new system. That might be a bespoke digital product, a commercial platform, a cloud service, a shared government capability or some combination of these.

Replacement becomes attractive when the problem is fundamental rather than superficial.

If the underlying data model no longer reflects the service, the architecture cannot support required levels of change, critical technology is unsupported, operating costs are escalating and the application is obstructing business transformation, incremental improvement may provide diminishing returns.

A well-designed replacement provides an opportunity to rethink the service rather than reproduce it.

That distinction matters.

One of the most expensive mistakes in public sector modernisation is using a replacement programme to rebuild every feature of the legacy application. Decades-old systems often contain functions that exist because of historical policies, obsolete processes, previous organisational structures or workarounds that became permanent.

Migrating all of that behaviour into a new platform can result in a technically newer system with almost exactly the same complexity.

The correct question is not “How do we rebuild this system?”

It is “Which capabilities does the service actually need now?”

That requires service design, policy, operations, data, technology and commercial thinking to happen together. A replacement led entirely as an IT exercise may successfully migrate software while leaving the underlying service largely unchanged.

Replacement also carries substantial transition risk.

Data must be understood, cleaned, mapped and migrated. Integrations must be recreated. Users must adapt to new processes. Operational teams need training. New support arrangements must become effective before old ones disappear. In highly critical environments, both systems may need to operate in parallel.

The final ten per cent of migration is often disproportionately difficult because it contains unusual cases, historical data, unresolved exceptions and the users whose circumstances do not fit the new model neatly.

A replacement programme should therefore be particularly cautious about the phrase “big bang”.

There are circumstances where a single cutover is necessary, but gradual migration is usually easier to observe, test and reverse. The ability to move one service, cohort, region, transaction type or capability at a time can dramatically reduce risk.

Replatforming sits between replacement and retention.

The term can mean different things, but the core principle is that significant elements of the existing service are retained while its technical foundations are modernised.

An application might move from ageing infrastructure into a supported cloud environment. Components might be containerised. A monolithic application might gradually be decomposed. Databases might be upgraded. Deployment processes might be automated. Authentication could be separated from the core application. New APIs might expose capabilities previously buried inside the system.

The attraction is clear: the organisation can reduce technical risk without attempting to transform everything simultaneously.

Replatforming is particularly appropriate when the underlying business capability remains valuable but the technology supporting it is becoming unsustainable.

However, replatforming has one significant trap: confusing infrastructure modernisation with service modernisation.

Moving an application into the cloud does not automatically make it cloud-native, scalable or easier to change. Putting a monolith inside containers does not remove the architectural coupling inside it. Migrating an old database to managed infrastructure does not improve the quality of the data.

There is nothing inherently wrong with these moves. They can significantly improve resilience, supportability and operational efficiency. The problem occurs when they are presented as solving constraints that they merely relocate.

A useful replatforming programme should therefore be explicit about which problems it is solving and which ones it is deliberately leaving for another day.

Integration is the third option and is sometimes underestimated because it sounds less transformational.

Rather than replacing the legacy application, the organisation reduces its influence by placing modern capabilities around it.

An integration or API layer can provide controlled access to data and functions. New citizen-facing services can interact with the legacy system without inheriting its user interface. Events can be published when important changes occur. Data can be made available for analytics. Identity, payments, notifications or document management can be handled by modern reusable components.

In effect, the organisation stops asking the legacy system to be everything.

This can be extremely powerful.

Many legacy applications were originally built as vertically integrated systems responsible for presentation, workflow, data, reporting, authentication and integrations. Modern architectures allow those responsibilities to be separated.

The legacy system may remain the authoritative system of record while gradually surrendering other responsibilities.

This creates an important fourth possibility hidden within the three options: integrate now, replace later.

A carefully designed integration strategy can create the architectural seams required for eventual replacement. New services communicate with stable interfaces rather than directly with legacy internals. Functions can then be replaced behind those interfaces one at a time.

Integration becomes dangerous, however, when it is used purely to postpone an unavoidable decision.

Another point-to-point interface is rarely a modernisation strategy. Neither is continuously adding middleware until nobody understands the end-to-end transaction.

When integration is chosen, the organisation needs an explicit view of whether the legacy system is being preserved indefinitely, progressively contained or prepared for retirement.

Without that destination, architecture accumulates rather than evolves.

The decision framework: how to choose the right route

The choice between replacement, replatforming and integration should not be made from a technology assessment alone.

A stronger approach is to assess the system across multiple dimensions and look at the pattern that emerges.

At minimum, government organisations should examine:

• Service criticality and continuity: What happens if the system becomes unavailable for an hour, a day or a week? Are payments stopped, statutory responsibilities affected or vulnerable users placed at risk?
• Technical sustainability: Are the operating system, database, languages, frameworks and infrastructure supported? Can security vulnerabilities be addressed? Is reliable monitoring possible?
• Changeability: How quickly and safely can new policy rules, service improvements and integrations be implemented?
• Data condition: Is important data accessible, well understood, sufficiently accurate and separable from the application itself?
• Interoperability: Can other systems consume and provide information through well-defined interfaces, or does every connection require bespoke engineering?
• Supplier dependency: Does the organisation understand the product sufficiently to operate, change or transition it through another supplier?
• Skills availability: Are the people needed to maintain the system available internally or from a healthy supplier market?
• Total cost of ownership: What is being spent not just on licences and support but on infrastructure, manual processes, duplicated functionality and technical workarounds?
• Strategic fit: Can the system support the organisation’s future operating model, service strategy, data ambitions and use of emerging technologies?
• Transition feasibility: How difficult would replacement actually be? What data, integrations, users, legal obligations and operational dependencies would need to move?

The result should not simply be converted into a numerical score and allowed to make the decision automatically.

Its purpose is to expose the nature of the problem.

Imagine, for example, a twenty-year-old case management platform. It is stable, well supported and familiar to operational staff. Its underlying data remains usable and the supplier continues to invest in the product. The principal limitation is that information is difficult to expose to new digital services.

Replacement may be an unnecessarily expensive response. A strong integration architecture could unlock data and capabilities while preserving a system that continues to perform its core function effectively.

Now consider another application with unsupported infrastructure, a declining skills base, undocumented business logic, expensive proprietary support, poor data quality and an inability to support policy change.

Building APIs around it may improve short-term connectivity while increasing long-term dependency. Replatforming could move the problem onto newer infrastructure without addressing the fundamental weaknesses.

Replacement is much more likely to be justified.

A third system may have good functional logic and valuable data but run on infrastructure approaching end of support. Its users do not need significant process transformation and its interfaces are reasonably well understood.

Replatforming could be exactly the right intervention.

This is why organisations should resist enterprise-wide rules such as “everything must move to the cloud”, “all legacy applications must be replaced” or “we should buy rather than build”.

Principles are valuable. Blanket solutions are not.

A government technology estate is a portfolio. Different systems should have different destinations.

Indeed, one of the most valuable outcomes of legacy discovery is not a single modernisation programme but a segmented estate: systems to tolerate, systems to stabilise, systems to integrate, systems to replatform and systems to retire.

That portfolio view also changes how investment should be prioritised.

The system with the oldest technology is not necessarily the system that should be modernised first.

A relatively stable thirty-year-old application might present less immediate risk than an eight-year-old platform with a failing supplier relationship, unsupported components and rapidly growing operational demand.

Priority should reflect the combination of impact and trajectory.

Ask not only how risky the system is today, but how quickly the risk is increasing.

Modernisation fails when organisations underestimate the transition

Choosing the target is only half the problem.

The route from the current state to the future state often presents more risk than the future technology itself.

This is especially important in government because critical systems rarely exist in isolation.

A case management application may connect to identity services, payments, document repositories, data warehouses, external agencies, third-party suppliers and dozens of downstream reporting processes. Files may be exchanged overnight through processes that nobody considers an “integration” because they have operated quietly for fifteen years.

Operational procedures can be even harder to discover.

Staff may maintain manual workarounds that are absent from formal process documentation. Particular spreadsheet columns may have become essential to monthly reporting. Experienced caseworkers may know that one field is technically optional but operationally indispensable.

A modernisation programme that discovers these facts during migration has started too late.

The first phase should therefore focus on understanding the system as it actually operates rather than as architecture diagrams say it operates.

That means tracing real transactions from beginning to end. Following the data. Identifying upstream and downstream dependencies. Understanding exception cases. Observing operational staff. Reviewing support incidents. Analysing change histories. Mapping contractual dependencies. Identifying where undocumented knowledge sits.

This work can feel slow compared with starting development, but it is usually far cheaper than discovering hidden dependencies during cutover.

Data deserves particular attention.

Many replacement programmes are described as application migrations when the greater challenge is actually data archaeology.

Legacy data may contain multiple representations of the same concept. Validation standards may have changed over decades. Historical records may not meet current rules. Free-text fields may contain information that newer structured models expect to separate. Duplicate records may be tolerated by the old application but rejected by the new one.

There is a temptation to regard these issues as defects to be cleaned before migration.

Sometimes they are. Sometimes they reflect legitimate complexity in the real world.

Government data frequently describes people, businesses and situations that do not fit simple models. Treating every unusual record as poor data risks designing services that work perfectly for the majority while failing precisely where complexity matters most.

Migration should therefore preserve meaning, not merely fields.

Another critical principle is to separate service modernisation from data migration wherever practical.

If a programme simultaneously redesigns the operating model, replaces the application, cleans all historical data, changes suppliers, moves to cloud infrastructure and launches a new public-facing service, almost every major risk becomes coupled.

When something goes wrong, diagnosis becomes difficult because too many variables changed at once.

Sequencing can be far more effective.

An organisation might first stabilise the existing service and improve observability. It could then introduce a modern integration layer, extract data into a more accessible platform, migrate selected capabilities, and progressively retire parts of the old application.

This is closely related to the strangler pattern, but the deeper principle is organisational: create reversibility.

Good transformation programmes make important changes without repeatedly placing the entire service at risk.

That requires coexistence to be designed deliberately.

For a period, old and new systems may both exist. The programme needs clear rules about which system owns which data, how updates are synchronised, how discrepancies are resolved and how users move between states.

Without these rules, “temporary” integration architecture can quickly become permanent complexity.

The retirement plan should therefore exist from the beginning.

What conditions must be true before the old application can be switched off? Which records must be migrated? Which information can be archived instead? Which integrations must disappear? How long must historical data remain accessible? Which contracts can then be terminated? Which operational procedures will change?

Decommissioning is not a technical footnote. It is where a large proportion of the economic value of legacy modernisation is finally realised.

If the new service goes live but the organisation continues paying for the old application, infrastructure, licences, supplier support and parallel processes for years afterwards, modernisation has added another system rather than removed a legacy one.

The goal is not modern technology; it is an organisation that can change

The most successful legacy modernisation programmes are unlikely to be remembered for the technology they selected.

They will be successful because the organisation becomes easier to change.

A genuinely modern service should make future decisions less consequential.

New policy should not routinely require major programmes. Data should not be trapped inside applications. Interfaces should be clear enough for new services to consume them safely. Infrastructure should be replaceable without redesigning the whole service. Suppliers should be interchangeable where reasonable. Operational knowledge should belong to the organisation rather than exist exclusively inside a contract.

This means the architecture after modernisation matters just as much as the migration itself.

A replacement that creates another tightly coupled system may simply restart the legacy clock.

The same is true of excessive customisation.

Commercial platforms can provide enormous value where public sector organisations have needs that are common across many organisations. But a product that has been customised until its upgrade path becomes unique may eventually become more difficult to maintain than the system it replaced.

Bespoke software creates a different responsibility. Government organisations need sufficient product ownership, engineering oversight and operational capability to prevent the codebase from becoming dependent on one delivery team or supplier.

In both cases, maintainability should be treated as an outcome.

The organisation should understand its architecture. Decisions should be recorded. Interfaces should use open standards where appropriate. Source code should be accessible and reusable wherever possible. Data should have clear ownership. Components should be observable. Deployment should be repeatable. Exit routes should be considered before they are needed.

This is also why legacy modernisation and interoperability are increasingly inseparable.

The future public sector technology estate is unlikely to consist of a handful of giant applications performing every function for an organisation.

Citizens increasingly expect services to feel joined up even when responsibility crosses organisational boundaries. Staff need information from multiple systems. Government wants greater reuse of common capabilities. Artificial intelligence creates new demand for reliable, governed access to organisational data.

In that environment, the most important property of a system may not be how modern its internal technology is but how effectively it can participate in a wider ecosystem.

A well-contained legacy application with dependable APIs may therefore be strategically more useful than a brand-new platform that creates another proprietary silo.

This leads to perhaps the most important principle when deciding whether to replace, replatform or integrate:

Do not optimise for the appearance of modernisation. Optimise for optionality.

Optionality means being able to change suppliers without rebuilding the service.

It means being able to introduce a new user interface without replacing the system of record.

It means being able to adopt a shared government component rather than duplicating functionality.

It means being able to expose trusted data to analytics or AI services without creating uncontrolled copies.

It means being able to replace one component without destabilising everything around it.

And it means being able to respond to a new policy requirement without launching another multi-year transformation programme.

For some systems, replacement will be the only credible path to that position.

For others, a carefully managed replatforming programme can remove the most urgent technology risks while protecting valuable functionality.

And for many, strategic integration can unlock new services and reduce dependence on the legacy application long before wholesale replacement would be affordable or safe.

There is also no reason these approaches must be mutually exclusive.

Some of the strongest strategies combine them.

An organisation might first integrate a legacy application to create stable interfaces. It can then replatform parts of the estate that present immediate infrastructure or cyber risks. Individual functions can subsequently be replaced behind those interfaces. Data ownership can move gradually. The original application becomes smaller until, eventually, there is nothing important left inside it and decommissioning becomes relatively uneventful.

That is often a better outcome than trying to cross the entire gap between old and new in one programme.

Legacy modernisation is ultimately an exercise in managing uncertainty.

Nobody can perfectly predict the policies, user expectations, security threats, technologies or organisational structures that a government service will face over the next decade.

The answer is therefore not to design the perfect replacement for today’s requirements.

It is to create an environment that can accommodate tomorrow’s requirements without another crisis.

Before approving a legacy transformation programme, senior leaders should be able to answer a final set of questions:

• Are we solving a genuine service and organisational problem, or simply responding to the age of the technology?
• Do we understand the true operational, technical, data, security, commercial and supplier dependencies of the existing system?
• Have we considered replacement, replatforming and integration seriously rather than beginning with a predetermined answer?
• Can we explain what capability will improve for users, staff and the organisation as a result of the investment?
• Does the proposed architecture reduce dependency and increase our ability to change?
• Have we designed the transition, coexistence and eventual decommissioning with the same care as the target system?
• Will the organisation own enough knowledge and capability to avoid creating the next legacy problem?

If those questions cannot yet be answered, choosing a technology is probably premature.

The most important decision in legacy modernisation is not whether the future system runs in the cloud, uses a particular platform or adopts the latest architectural pattern.

It is deciding what should remain stable, what genuinely needs to change, and how the organisation can move between those states without putting the public service at unnecessary risk.

Replace when the existing system fundamentally prevents the service from becoming what it needs to be.

Replatform when the capability remains valuable but its technical foundations are becoming unsafe or unsustainable.

Integrate when the system can continue doing a useful job but needs to become part of a more flexible, connected architecture.

And where the answer is uncertain, resist the pressure to begin with a solution.

Begin with the service, the data, the risks, the dependencies and the future capabilities the organisation needs.

The objective is not to eradicate everything labelled “legacy”.

It is to ensure that yesterday’s technology no longer determines what government is able to do tomorrow.