Whitepaper

The hidden cost of legacy data systems in UK public services

What the parliamentary record, government data and two decades of delivery experience reveal about the real price of standing still when it comes to legacy IT and data systems.

This whitepaper draws on primary sources including the UK Government's Roadmap for Modern Digital Government, the House of Commons Science, Innovation and Technology Committee's Rewiring the State: Delivering digital government report (2026), the State of Digital Government Review (2025) and McKinsey research on technical debt. It is intended for data leaders, transformation teams and technology decision-makers in the public sector and critical data organisations across the UK.

Download the PDFStart reading
28%

of central government IT classified as legacy - and rising

State of Digital Government Review, 2025
3–4×

more expensive to maintain legacy systems vs modern alternatives

Parliament SIT Committee, 2026
£20bn

committed by government to digital & technology modernisation over the Spending Review period

228

legacy IT systems identified across government departments as of March 2024

NAO / NCSC

Executive summary

Legacy technology is no longer a background concern for UK public sector organisations. It is front and centre in a major parliamentary inquiry, a formal government roadmap with named departmental targets, and a growing body of evidence linking outdated infrastructure to service failure, data breaches, and blocked AI ambitions.

The House of Commons Science, Innovation and Technology Committee published Rewiring the State in June 2026, concluding that legacy systems represent 'huge efficiency, cost and security risks', with a warning that the government still does not know the full scale of the problem. The State of Digital Government Review (January 2025) also found that 28% of central government IT is classified as legacy, that 22% of those systems are red-rated for imminent failure, and that the public sector invests around 30% less on technology than international benchmarks.

For organisations managing national-scale, citizen, or mission-critical data, this is not an abstract policy problem. It shapes how services are delivered today, how securely data is held, and how much of the substantial investment now flowing into AI and cloud platforms will actually deliver value.

This whitepaper by Butterfly Data sets out the scale of the challenge, the compounding costs of inaction, what good migration looks like in practice, and how we help organisations move from risk to future-ready - safely and without unnecessary disruption.

1. The policy landscape has changed

Something significant has shifted in the past 18 months. Legacy IT has moved from a perennial infrastructure concern to an explicit, named government priority with departmental targets, parliamentary scrutiny, and ringfenced funding.

1.1 The Government's formal commitment

The UK Government's Roadmap for Modern Digital Government sets a clear goal that most critical public services should no longer be dependent on outdated legacy technology. It is not an aspirational language. The roadmap lists specific departmental commitments with timelines:

DWP agrees plan to modernise priority legacy benefits and pension services

First services targeted include Severe Disablement Allowance, Widowed Parent's Allowance and Industrial Injuries Payment.

Home Office migrates police forces to the Law Enforcement Data Service

Replacing the legacy Police National Computer with a new, scalable central data service.

DEFRA to migrate 19 critical legacy applications to cloud

Decommissioning two legacy data centres and replacing key infrastructure contracts.

MoD begins development of Secret Community Cloud

A secure cloud environment for the national security community and wider public sector.

DWP to fully refactor the Severe Disablement Allowance service

Completing case migration and payments through a new, fully modernised codebase.

Home Office to fully digitise all life event records for England and Wales

Digitising all birth, death, marriage and civil partnership records into a secure System of Record.

These are not targets set by technologists for technologists. They are commitments made by departments to the government as part of a formal roadmap with political accountability. For the organisations in scope, and for those in adjacent or dependent sectors, they represent both a directive and a window of opportunity.

1.2 Parliamentary scrutiny: Rewiring the state

In June 2026, the House of Commons Science, Innovation and Technology Committee published Rewiring the State: Delivering Digital Government. This landmark report draws on two years of evidence-gathering and its conclusions on legacy systems are unambiguous.

"Legacy systems present huge efficiency, cost and security risks, and it is therefore deeply concerning that government still does not know the full scale of the problem. If legacy systems are not remediated, the government's digital transformation ambitions will struggle to succeed."House of Commons Science, Innovation and Technology Committee, Rewiring the State (June 2026)

The Committee recommended the creation of a Legacy Systems Taskforce empowered to mandate action by departments. It welcomed GDS's commitment to work with HM Treasury to ringfence funding for legacy remediation. And it was direct about what inaction means: the digitisation agenda, the AI ambitions, the planned digital ID - none of them can succeed on a foundation of legacy infrastructure.

1.3 The state of digital government review

The State of Digital Government Review published by DSIT in January 2025 provides the most comprehensive picture yet of the challenge. Key findings relevant to legacy migration:

  • On average 28% of central government IT estates are classified as legacy - up from 26% in 2023, moving in the wrong direction.
  • 22% of legacy systems are red-rated, indicating known security vulnerabilities, lack of vendor support, or inability to meet current requirements.
  • Legacy estates run from 10% to 70% across police forces, and 10% to 50% across NHS trusts - with around 15% of organisations unable to estimate their legacy estate at all.
  • Maintaining legacy systems typically costs three to four times more than maintaining modern alternatives.
  • In 2024, 25% of surveyed organisations suffered critical outages - with 123 in NHS England alone. Some of these outages were linked directly to patient harm.
  • At least 228 legacy IT systems were identified across government departments as of March 2024 (National Audit Office / NCSC).
  • The government spends approximately 30% less on technology than international benchmark comparisons - a structural underfunding that has allowed legacy to accumulate for decades.

2. The compounding cost of delay

The case for delay always sounds reasonable at budget time. Legacy systems are still working. Teams are busy. The investment required looks large relative to the uncertain benefit. So another cycle passes, technical debt quietly compounds, and the eventual migration becomes both more expensive and more complex than it would have been.

The parliamentary committee was direct about why this logic fails over time. It identified three mechanisms by which delay makes things progressively worse - all of which are compounding, not linear.

2.1 The cost spiral

McKinsey's research on technical debt estimates that CIOs put technical debt at 20–40% of the total value of their entire technology estate. More immediately, 10–20% of the technology budget nominally allocated to new products is diverted to servicing existing debt. High-debt organisations are 40% more likely to have incomplete or cancelled modernisation projects.

The parliamentary committee's evidence base reinforced this at a public sector scale: legacy maintenance costs three to four times more than maintaining modern equivalents, and there is a structural bias towards capital spend on new projects at the expense of maintaining existing systems. The result is that underfunding of legacy maintenance drives faster accumulation of legacy risk - a compounding dynamic rather than a stable steady state.

The numbers at stake

The government has committed £20 billion over the current Spending Review period to digital, data and technology modernisation. The DSIT State of Digital Government Review estimates that full digitisation of public sector services could unlock £45 billion in annual productivity savings. Both figures are contingent on successfully remediating the legacy estate that currently prevents them from being realised.

2.2 The security risk

The National Cyber Security Centre has stated that having a strategy to address technical legacy is 'a foundational precursor to engineering resilience'. That assessment has been tested repeatedly in recent years.

The NCSC managed 430 cyber incidents between September 2023 and August 2024, with 89 classified as nationally significant. The Government Cyber Resilience Report identified legacy systems as a prominent feature of security vulnerability. Of the 228 identified legacy systems across departments, many carry known vulnerabilities that cannot be patched because the vendor no longer supports the platform.

The data breach risk is not hypothetical. A 2023 Information Security Review - whose existence was kept secret until the SIT Committee's intervention - examined ten public sector data breaches and found common themes: insufficient controls over data exports, wrong-recipient email releases, and hidden personal data in published spreadsheets. The Rewiring the State report concluded that 'major cultural transformation is required to prevent mass data breaches from happening in the future' - and that modernised infrastructure is a prerequisite.

2.3 The knowledge concentration risk

This risk does not appear in most migration business cases. It should be the first item on the register.

Anyone who has read The Phoenix Project, the IT operations novel by Gene Kim, Kevin Behr and George Spafford, will remember Brent Geller, the lead engineer through whom almost every fix, change and outage has to pass, because so much of how the systems really work exists only in his head. Most legacy environments have a Brent, and often more than one. In public sector organisations it is common to find that the operational knowledge of a critical platform, such as its undocumented logic, its workarounds and its integration quirks, resides with two or three individuals who have worked with it for a decade or more. When those individuals retire or move on, organisations frequently discover that the documentation does not describe how the system actually works in practice.

The window in which experienced staff can support a structured migration and knowledge transfer is finite. Every year of delay narrows it. This is particularly acute in the public sector, where salary constraints mean that specialist technical staff are disproportionately likely to leave for better-paid private sector roles.

2.4 The blocked opportunity cost

Perhaps the least visible cost of legacy is what it prevents. The UK Government's ambition to deploy AI across public services, improve data sharing, and deliver joined-up digital services all assume data that is accessible, well-governed, and in modern formats. None of that is compatible with data trapped in legacy proprietary formats, undocumented schemas, and siloed systems that were never designed for integration.

The SIT Committee was explicit: "Failure to address [legacy] siloization will hamper delivery of the government's vision and put citizens' data increasingly at risk." The consequence in practice is that AI and analytics projects built on legacy foundations are almost always more expensive, slower, and ultimately deliver less than they should.

3. What the landscape actually looks like

Understanding the scale and nature of legacy dependency in UK public sector organisations requires moving beyond aggregate statistics. The parliamentary committee's report and supporting evidence from multiple departments paint a specific picture.

Legacy share of technology estate across central government organisations10% to 60%

As part of the Central Government, DWP operates some of the UK's most consequential data systems - supporting pension payments, welfare assessments, and benefits administration for millions of citizens. The June 2025 commitment to modernise priority legacy benefits services is significant because it represents the first time DWP has set out a phased plan with public milestones rather than a general aspiration.

The situation across departments is highly uneven. The review found that legacy estates range from 10% to 60% of the technology estate across central government organisations. A number of departments could not estimate their legacy exposure at all.

Legacy dependency across police forces10% to 70%

The Police National Computer - the central database underpinning UK law enforcement - was one of the highest-profile legacy migration commitments in the roadmap, with the Home Office beginning the transition to the Law Enforcement Data Service in September 2025. The PNC migration is significant not just for policing but as a proof point for large-scale public sector migration: it involves highly sensitive personal data, real-time operational dependency, and access requirements for dozens of forces and agencies simultaneously.

Across police forces more broadly, the SIT Committee's evidence base found legacy dependency ranging from 10–70%. Some forces have modernised substantially; others remain heavily dependent on systems that are decades old.

Cloud adoption across NHS trustsaround 5% to over 90%

The NHS presents perhaps the most complex legacy landscape of any sector. 123 major system failures were recorded in NHS England in 2024 alone, with some of these linked to patient harm. The eVisa system, which is based on over 90 separate systems, many of them legacy, was described in parliamentary evidence as producing an 'unacceptably high number of errors' despite eight years of operation. Cloud adoption across NHS trusts ranges from around 5% to over 90% of the estate.

The NHS Federated Data Platform, the Single Patient Record, and other major NHS data infrastructure projects all depend on the same prerequisite: a modernised, accessible, well-governed data estate. The parliamentary committee's concern about vendor lock-in in NHS data infrastructure, particularly regarding proprietary platform dependencies, adds an additional dimension to the migration challenge.

Councils with dedicated budgets for new digital systems39%

The State of Digital Government Review found that a large proportion of local government workloads and data remain on-premise. Only 39% of councils have dedicated budgets for new digital systems. The review noted that cloud adoption is inconsistent, with Crown Hosting Data Centres - the Cabinet Office joint venture specifically designed to support public sector bodies migrating from on-premises facilities - being underutilised.

4. Security, compliance and sovereignty

The parliamentary committee's Rewiring the State report addressed legacy migration not just as an efficiency or cost issue but as a strategic security and sovereignty concern. These dimensions are increasingly important for organisations considering their migration approach.

4.1 Data security and GDPR

Legacy systems create data security risk in ways that are difficult to fully mitigate without migration. Known vulnerabilities cannot be patched on unsupported platforms. Access controls cannot be brought into line with modern zero-trust principles. And data cannot always be classified and protected in accordance with the Government Security Classifications without fundamental architectural change.

Organisations processing personal data are required to conduct Data Protection Impact Assessments when undertaking migration. The ICO's guidance on UK GDPR is clear that legacy environments which cannot meet current data protection standards represent an ongoing compliance risk, not a deferred one.

4.2 Vendor lock-in as a migration risk

The SIT Committee devoted substantial attention to vendor lock-in and identified it as a major barrier to the government's digital transformation agenda. AWS and Microsoft together hold an estimated 60–80% of the UK cloud infrastructure market. The Competition and Markets Authority opened an investigation in March 2026 into Microsoft's use of software licensing practices reducing competition in the cloud.

For organisations planning migration, this is directly relevant. A migration that moves data from one legacy lock-in to a different proprietary lock-in has not solved the underlying structural problem. The parliamentary committee's recommendation to prioritise open-source tools and technology, and to develop sovereign alternatives to incumbent providers, reflects a shift in how the government is thinking about the migration destination - not just the journey.

The good news is that cloud platforms including AWS, Azure and Google Cloud all support open-standards approaches when properly architected. The difference lies in how landing zones are designed, how data is structured, and whether migration processes create new dependencies or eliminate existing ones.

4.3 Security-cleared delivery

For organisations handling data at SC, DV or NPPV3 classification levels, including central government departments, policing, intelligence and defence, delivery team vetting is not optional. The UK Government Cloud Security Principles and the NCSC's security guidance both require that access to classified systems and data is limited to appropriately cleared personnel.

This means that the discovery phase of any migration, which requires access to the systems, documentation, and data necessary to understand the full scope, must be staffed accordingly. Butterfly Data's team of consultants is vetted and has operated within classified environments across HMRC, the Home Office, DWP, FCDO and policing for more than two decades.

5. What good migration actually requires

Migration has a poor reputation in the UK public sector because many projects have failed, or succeeded only partially. The National Programme for IT in the NHS, GOV.UK Verify, and numerous departmental modernisation projects are cited by the SIT Committee as examples of initiatives that overspent, under-delivered or both.

The common failure modes are well-documented: insufficient discovery investment, unrealistic timelines, platform selection before strategy, conflicting requirements when systems are consolidated, data quality issues that surface mid-migration, poorly managed cutover of live services, and change management that treats users as an afterthought. What follows is a framework for avoiding them.

5.1Discovery first (without shortcuts)

The most common cause of migration failure is insufficient investment in discovery. Organisations underestimate the complexity and interdependency of their existing environment, make assumptions that turn out to be wrong, and encounter unexpected problems at the point of maximum cost.

Discovery in a complex public sector environment requires: systematic mapping of applications, data stores, and dependencies; engagement with the people who carry undocumented operational knowledge; assessment of data quality, compliance posture and security risk; and an honest inventory of what is actually in use versus what is assumed to be in use. For estates where around 15% of organisations cannot estimate their legacy exposure, this last point is not a formality.

This matters because discovery should come before any credible modernisation decision. The common '6 Rs methodology' for choosing how to approach modernisation follows one of six paths - rehost, replatform, refactor, rebuild, retire or retain. Each path assumes you know a system's complexity, dependencies and remaining business value. Without discovery, organisations tend to default to rehosting everything as the cheapest-looking option, then find mid-migration that a supposedly self-contained system is load-bearing for other processes, or that a system marked for retirement is still in daily use by a team nobody consulted.

The 6 Rs should sit downstream of discovery, rather than alongside it. A rehost-or-retire decision against an unverified inventory is a guess dressed up as a strategy, and with around 15% of organisations unable to estimate their legacy exposure, a meaningful share of modernisation projects are making these calls without the information the framework assumes they have.

5.2Strategy before platform

A sound migration strategy begins with the organisation's objectives and constraints, including continuity requirements, compliance obligations, classification levels, AI and analytics ambitions, and risk tolerance. Platform selection follows from strategy. It does not precede it.

This is directly relevant to the parliamentary committee's concern about vendor lock-in. Choosing a platform before defining what sovereignty, portability and interoperability requirements mean for this specific migration creates exactly the dependencies that the Rewiring the State report warns against.

5.3Resolution of conflicting requirements

Migration of systems is quite often an opportunity to consolidate systems by decommissioning 2 or more systems, combining their functions and then paying for one system instead of multiple. Whilst the financial case of this is strong, consolidation adds an extra layer of complexity to migration that can be underestimated.

When each system that is retired was originally built to serve a particular user set, those users sometimes do not want the same things. For example, one group of users might require a process that is fast and flexible, whilst the other may need the system to be tightly controlled and auditable. Both of these requirements are legitimate and could potentially end up in the specification for works without the contradiction being noticed.

This is where a business analytics process adds its value. By undertaking structured requirements gathering, the role surfaces conflicting prerequisites early on, makes trade-offs more visible and helps get sign-off from the people with the authority to make it, prior to the conflicts being built into the system design. The analysis also tests whether requirements are a genuine business need or simply how the old system used to work. This same principle applies to the data, whereby 2 or more systems being combined will often hold different definitions of the same terms as covered in section 5.4.

5.4Effective management of switchover

For organisations managing critical services, big-bang migrations are rarely appropriate and UK Government guidance recommends iterative and phased approaches. Switching over an operational system is one of the hardest parts of any migration to arrange. The service has to keep running throughout and it can be extremely challenging to find a moment that suits everyone. Stakeholders often have different priorities - for example, operational teams want minimal disruption, finance wants to stop paying for the old system and compliance wants assurance before anything is switched off. Agreeing the cutover approach early can stop these tensions surfacing at the last minute.

A phased cutover moves workloads, users or sites across in sequenced tranches, with validation at each stage. This limits the impact of any single problem but means old and new systems coexist for longer. Parallel running keeps both systems live so outputs can be compared and there is a fallback if problems emerge, at the cost of running two environments. Either way, pilot migrations are essential for validating the approach before it matters the most.

Keeping data synchronised during transition needs to be designed. If records can be updated in both environments, there must be clear rules on which system is the master for each data set at each stage and also a reliable mechanism for keeping them aligned. A tested rollback plan is essential where downtime has real consequences, like it does in public services.

5.5Data quality as a deliverable

Legacy systems invariably contain data quality issues. A migration that moves poor-quality data into a modern environment has not solved the problem. The Data Management Association's (DAMA) Body of Knowledge (DMBOK) provides a recognised structure for source-to-target mapping and data quality work. This is where much of the actual value of migration is created: the improvement in data governance that makes the target environment genuinely more useful than the one it replaced, and that makes AI and analytics investments viable rather than aspirational.

This is also where the case for a thorough discovery phase becomes clear. Data quality discovery often doesn't stay a technical exercise for long because it quickly raises the question of what the data is supposed to mean. A data quality rule can only be applied once people agree on what the rule is. For example, some we have seen are: what counts as an "active" customer when each department applies its own definition? Is a record marked "Paused" the same as one marked "On-hold"? And is a value of 250 recorded in pence or pounds? Legacy systems sometimes encode different answers to these questions in different places and teams that have worked around the inconsistencies for years may not realise they exist until a migration exposes them.

Resolving these differences in data definitions can take time because it requires other stakeholders such as business owners, not just technical teams, to reach a decision together. Once a definition is agreed, there are two broad routes to applying it, which are cleansing the data at source before migration or building transformation steps into the migration itself. Cleansing at source means the legacy system is corrected before anything moves, usually for issues that are understood and contained. Transformation during migration suits issues that are systemic or would be impractical to fix in the old environment but needs to be documented carefully so the logic is transparent and auditable afterwards. In practice, often migrations use a combination of both, but either way, the work is far more effective to scope during discovery than to discover halfway through delivery.

5.6Security and compliance by design

Cloud landing zones for public sector organisations must be designed in alignment with the UK Government Cloud Security Principles from the outset. The NCSC Cloud Security Guidance and the Technology Code of Practice set the framework. Butterfly Data designs environments with zero-trust identity and access management, role-based access control, and data classification handling as first-class constraints - not post-deployment additions.

Recognised cloud architecture frameworks - the AWS Well-Architected Framework, Azure Architecture Framework and Google Cloud Architecture Framework - provide technical guardrails. Compliance with GDPR and the Data Protection Act 2018 must be built into migration design, not reviewed at the end.

5.7Bringing people with the change

A new system can only deliver value to an organisation if people use it effectively. Technical success doesn't equal a successful migration - projects resulting in working technology can still fail because the people expected to use it were not brought along as part of the process.

Change management needs to start early, rather than when a new or modernised system goes live. Users need to understand why the change is happening, how it impacts their day-to-day work and what support they will have moving forward. Retraining should be planned for as part of the project and timed so that people are confident before they are expected to rely on the new system. Staff who have used a legacy system for many years will often have built efficient workarounds, so it is reasonable for them to worry that a new system will make their job harder or even make parts of it redundant. Those concerns should be listened to and addressed honestly rather than dismissed.

Involving users in design, testing and pilot phases is one of the most effective ways to build support. People who have helped shape a system are more likely to champion it and they are also likely to spot practical user problems that technical teams can miss. This matters particularly for the long-serving staff described in section 2.3. They hold much of the knowledge a migration depends on and they are well placed to become advocates for the new system if they are engaged as part of the process, rather than treated as a source of information to be captured before they leave.

6. Common legacy platforms and migration realities

Different legacy platforms present substantially different migration challenges. Understanding what each actually involves prevents the most common failure mode, which is underestimating what has to be done before a workload can be moved.

SAS 9.x / Viya 3.x

The right route depends on the strategy. Options include moving to SAS Viya 4, re-platforming to open-source tools such as Python or retaining SAS on new infrastructure. The main difficulty in every case is proprietary functionality. SAS datasets, macro libraries, custom procedures and user-written functions often have no direct equivalent elsewhere and even Viya 4 is a significant architectural change rather than an upgrade. Everything needs a careful translation and re-testing and QA requirements for risk-critical analytics are substantial. Lifting and shifting a 9.4 environment onto new hardware or cloud infrastructure is possible, but it carries the same limitations across and achieves little of the benefit. Deep SAS expertise is essential whichever route is chosen.

SAP ERP (on-premise)

High interdependency with finance, HR and operational processes means scope is typically larger than initial assessment suggests. Data extraction complexity, integration with cloud target, and end-user change management all require parallel workstreams.

Legacy Oracle / SQL Server

Rehosting to cloud virtual machines is quick but retains much of the existing licensing and maintenance overhead. Moving to managed or open-source databases requires careful translation of schemas, proprietary SQL dialects and stored procedures, and performance tuning in the target environment is non-trivial. The opportunity to improve data model quality during migration is real but must be planned for explicitly.

MS Access, Crystal reports, Qlikview

These tools are often widespread and poorly inventoried, with many built by end users outside formal IT governance, so discovery is critical to understand what exists and what is still used. Migration to a modern reporting platform such as Power BI is not usually a like-for-like. Access databases usually combine data storage, forms and reporting, so the data needs a proper home before reporting can move. Crystal Reports' fixed-layout outputs need a paginated reporting tool rather than standard dashboards and QlikView load scripts and data models need rebuilding in the target platform. Many legacy reports turn out to be duplicated or no longer needed, so rationalisation is a real opportunity.

Bespoke on-premise builds

Often the hardest cases. Undocumented behaviour, knowledge concentration in a small number of individuals, no commercial migration tooling. Discovery investment is the most critical phase and the most commonly underestimated.

Legacy ETL platforms (SSIS, DataStage)

Complex dependency mapping required before any workload can move. Workflow recreation in modern tooling - Databricks, dbt, Informatica IDMC - requires parallel validation. Premature decommissioning of legacy ETL is a common and costly mistake.

On-premise data warehouses

Significant opportunity for consolidation and data quality improvement. Migration to Snowflake, Azure Synapse, BigQuery or similar requires source-to-target mapping that treats data quality as a deliverable, not a downstream concern.

For public sector organisations, SAS environments warrant particular attention. Many central government departments and NHS bodies built critical analytical services on SAS 9.4 during the 2000s and 2010s - fraud risk modelling, clinical analytics, welfare assessment, policing intelligence. These environments now face a strategic decision, whether to move to SAS Viya 4, re-platform to open-source alternatives, or retain SAS in a modernised environment, and each route requires a clear view of what the existing code and outputs actually depend on. Butterfly Data holds SAS Gold Partner status and has directly supported these migrations in live government environments, including a critical risking service operating under extreme demand.

7. Butterfly Data's migration approach

Butterfly Data has vast experience working with public sector and critical data organisations across the UK. Our approach to migration is holistic, drawing on the POPIT model used in BCS business analysis practice, which considers the impact of change across People, Organisation, Process, Information and Technology. In practice, this means the people who will use the new system are considered from discovery onwards, with training, communication and engagement planned into delivery rather than left until go-live.

Phase 1

Discovery and assessment

We begin by mapping the landscape in detail: applications, data stores, dependencies, performance constraints, data quality issues and technical limitations. This includes structured engagement with stakeholders, review of existing documentation, and operational data analysis where available. Crucially, it includes direct engagement with the people who carry institutional knowledge of how systems actually work, rather than just how they are documented. Discovery also assesses the impact of change on users, teams and ways of working.

For organisations where legacy dependency is only partially understood - which the State of Digital Government Review suggests describes a significant proportion - this phase delivers value in its own right, independent of any migration project that follows.

Phase 2

Migration strategy and planning

Based on discovery findings, we define a tailored migration strategy covering platform selection, migration sequencing, risk mitigation, and delivery phasing. Success criteria are established against the organisation's objectives - not against project management convenience. Compliance requirements, classification levels, continuity obligations and AI/analytics ambitions all inform strategy before any platform discussion begins. The strategy also includes a change and engagement plan covering how users will be informed, trained and supported through the transition.

Where systems are being consolidated, requirements from each user group are captured and reconciled at this stage, so conflicts are resolved before design begins.

Phase 3

Data exploration and source-to-target design

We carry out detailed data exploration to understand legacy data structures, relationships and quality issues. Source-to-target mappings document existing and required data structures, transformations and business rules. This is where data quality issues surface and are resolved - creating the blueprint that makes migration a quality improvement, not just a transfer.

Phase 4

Migration development and execution

We design and implement structured data migration processes using automated extract, transform, filter and load workflows. Secure transfer mechanisms protect data integrity throughout. Migration processes are designed for repeatability, traceability and auditability - essential in regulated, audited and classified environments

Phase 5

Validation, testing and pilot migration

Comprehensive testing validates data integrity, quality and usability in the target environment. Pilot migrations demonstrate that the approach works in practice before any production commitment. Parallel testing of data feeds ensures that migrated outputs match legacy outputs - and that the comparison is documented for audit purposes. No critical system should be decommissioned without this stage having been completed.

Users are involved in testing and pilot phases, which builds familiarity and confidence and surfaces practical issues that technical testing can miss.

Phase 6

Production migration and transition

We support controlled deployment to production, coordinating cutover activities to minimise downtime and operational risk. Where appropriate, we assist with the controlled decommissioning of legacy systems - reducing ongoing maintenance overhead and eliminating the cost of running parallel environments longer than necessary.

The cutover approach, whether parallel running, phased transition or a combination, is agreed with stakeholders in advance, with clear rules for data synchronisation and a tested rollback plan.

Communication and training are timed so users are prepared and confident before they are expected to rely on the new system.

Phase 7

Post-migration support and optimisation

Following migration, we provide stabilisation support to address early issues and optimise performance. This includes supporting integration with modern platforms, refining processes, and preparing the environment for the analytics and AI capabilities that justify the investment. Knowledge transfer to internal teams, and ongoing support for users as new ways of working bed in, is embedded throughout delivery, not bolted on at the end.

8. Proven impact

Supporting a Critical Government Fraud-Risking Service

A UK central government department engaged Butterfly Data to support a critical analytical risking service built on SAS Managed Cloud - combining SAS 9.4 and SAS Viya hosted within a private AWS environment. The service had been developed to replace ageing legacy systems, with multiple controlled environments supporting a structured route to live.

During platform build, the department faced an unexpected surge in demand driven by emergency economic support measures - requiring a live SAS-based service to be stood up at pace. An existing pre-production environment was rapidly repurposed into a multi-tenant SAS Viya platform, enabling parallel operation of a live fraud-risking service alongside ongoing development.

Butterfly Data supported live service operation, incident response, data engineering and governance processes - ensuring analytics continued to deliver timely, reliable risk insights under extreme operational pressure. The engagement later evolved into migration and integration of legacy SAS analytics into a consolidated enterprise risk platform.

"The invaluable work that Butterfly Data have undertaken with a key collaborator of mine will feed directly into my work, making it both simpler and faster and enabling me to better identify data gaps. Incredibly useful."
Home Office

9. Making the internal case

For many organisations, the most significant barrier to migration is not technical, but is making the internal case for investment in systems that are still, technically, working. The costs of action are visible. The costs of inaction are diffuse, compound gradually, and resist the kind of precise quantification that business cases typically demand.

Three framings have consistently proved effective in organisations that have successfully made this case.

Frame it as risk management, not modernisation

Technology modernisation competes with every other organisational priority. Risk management does not. The question is not 'can we afford to modernise?' but 'what is the risk profile of not modernising?' - against a backdrop of parliamentary scrutiny, named departmental targets, and NCSC guidance that treats legacy remediation as foundational to cyber resilience.

The parliamentary committee's conclusion makes this case ready-made: legacy systems present 'huge efficiency, cost and security risks'. The State of Digital Government Review provides the statistics. The knowledge concentration risk, described in section 2, is often the most compelling element of the case - because it has a visible, finite window that gets shorter every year.

Start with discovery, not a migration project

A full migration project is large, complex, and difficult to justify before the scope is clear. A structured discovery engagement is far easier to fund, far less disruptive to initiate, and produces the evidence base for a credible migration business case. It also surfaces the knowledge transfer risk and the compliance gap - which are often the elements that convert a hesitant budget holder.

Align to existing strategic commitments

Most organisations with legacy exposure have existing commitments to cloud adoption, data governance improvement, and AI readiness - commitments consistent with the UK Government's Roadmap for Modern Digital Government and the Government Cloud Strategy. Legacy migration is not a separate initiative from those projects. It is a prerequisite for them. Framing migration as unblocking existing strategic priorities - rather than as a standalone infrastructure investment - consistently makes the case more tractable.

Procurement route: G-Cloud 15

Butterfly Data's legacy migration services are available through G-Cloud 15 (Lot 3) as well as other GCA frameworks and the Home Office ACE project. Public sector organisations can procure directly through these routes without a full competitive tender process, which significantly reduces procurement overhead and time-to-engagement.

10. Getting started

The right starting point is not a migration project. It is a structured discovery engagement that delivers clarity about what the organisation actually has, where the real risks sit, and what a realistic path forward looks like.

Butterfly Data's discovery engagement delivers:

  • A comprehensive inventory of legacy systems, data flows and dependencies - including the undocumented operational knowledge that inventories typically miss.
  • Assessment of data quality, compliance posture, classification requirements and security risk.
  • Identification of knowledge concentration risks and the transfer window available.
  • A prioritised, risk-calibrated migration roadmap with honest cost and timeline estimates.
  • A business case framework aligned to the organisation's existing strategic commitments.

Discovery engagements can be scoped to specific systems, specific data domains, or the full estate - depending on where uncertainty is greatest and risk is most acute. For organisations in scope of the formal government legacy remediation project, the discovery phase should be treated as urgent: the window for structured, knowledge-supported migration is not indefinitely open.

Book a free discovery call

Find out how Butterfly Data can help your organisation understand its legacy risk and build a credible path to modernisation.

Book a discovery call

Email

hello@butterflydata.co.uk

Phone

+44 29 212 00140

Web

butterflydata.co.uk
Download the whitepaper

Get the full report as a PDF

The complete whitepaper, including the full evidence base, platform guidance and key sources, to share with your team or use in your business case.

Form embed goes here