Cloud migration has been a feature of NHS digital strategy conversations for several years. What has changed in 2025 and 2026 is the urgency. A combination of national policy direction, the acceleration of EPR and FDP programmes across NHS Trusts, mounting technical debt in on-premises environments, and the practical requirements of AI and advanced analytics has brought cloud-first data strategy from a medium-term consideration to an immediate one.

This is not an argument for cloud for its own sake. Cloud migration done without a clear strategy, sound architecture, and proper governance produces its own set of problems. But the case for NHS Trusts to develop and commit to a cloud-first data strategy now, rather than deferring it until after the next programme or the next financial year, is stronger than it has ever been. This article sets out why.

The National Direction Is Unambiguous

NHS England's cloud strategy is explicit. The position is cloud-first and internet-first, with the aim of moving away from what the organisation itself has described as increasingly costly infrastructure proliferation that has hindered the NHS's ability to modernise. The 10 Year Health Plan published in July 2025 reinforces technology and data as central to the NHS's future operating model, with digital transformation embedded throughout its ambitions for shifting care closer to communities and improving population health management.

The Federated Data Platform represents a direct national investment in cloud-native data infrastructure. With over 100 NHS organisations engaged and deployment continuing through 2026 and beyond, the FDP is establishing cloud as the default layer for operational and analytical data at national level. Trusts that do not have a coherent local cloud data strategy are increasingly finding that they cannot connect meaningfully to national infrastructure, or that the connections they make are degraded by the quality of the local data environment feeding into them.

NHS England's Cloud Centre of Excellence provides direct support to NHS organisations through their cloud journey. The infrastructure to support adoption is in place nationally. What many Trusts still lack is the local strategic commitment and architectural clarity to make use of it.

The national direction has been set. The question for Trust digital leaders is no longer whether to move to cloud, but how to do it in a way that is sequenced, governed, and grounded in the realities of their current estate.

The On-Premises Estate Is Not Sustainable

The typical NHS acute Trust is running a data environment that has accumulated over decades of procurement decisions, organisational changes, and system implementations, each of which added to the estate without retiring anything that came before. The result is an environment defined by fragmentation: hundreds of clinical and operational systems, dozens of on-premises SQL Server instances spanning multiple versions, integration engines configured inconsistently across sites, and substantial amounts of data held in undocumented local databases and legacy applications.

Maintaining this environment is expensive, not just financially but in terms of the internal capacity it consumes. Engineers who could be working on transformation are managing hardware refresh cycles, patching unsupported software, and troubleshooting integrations between systems that were never designed to work together. Every year that passes without structural change, the estate grows more complex and the migration path becomes harder.

The SQL Server End-of-Support Timeline

SQL Server version support is a concrete forcing function that makes this urgency tangible. SQL Server 2016 reaches end of extended support in July 2026. For NHS Trusts running instances of SQL Server 2016, and many are running versions considerably older than that, this represents an active security and compliance risk. Once Microsoft withdraws support, vulnerabilities identified after that date receive no patches. The NHS Data Security Standard 8 requires active management of unsupported systems, including SIRO-level risk acceptance for those that cannot be immediately remediated.

A Trust with over a hundred on-premises SQL Server instances spanning a range of versions cannot remediate each individually on a reactive basis. A cloud-first data strategy provides the structural framework within which SQL rationalisation and migration can be sequenced and delivered as a programme rather than a series of disconnected firefights.

The Cost of Delay Compounds

On-premises infrastructure proliferation does not stabilise. It grows. Cloud-native applications and databases are being deployed alongside the existing on-premises estate, adding complexity rather than replacing it, in the absence of a governing architecture. The longer a Trust defers a cloud-first strategy, the larger the estate it will eventually need to migrate, the more dependencies it will need to untangle, and the more the migration itself will cost.

NHS Shared Business Services launched a £2.5 billion Digital Workplace Solutions framework in October 2025 specifically to support the overhaul of ageing legacy infrastructure across the NHS and wider public sector. The framing from that programme is direct: legacy systems do not have the processing power or data handling capabilities to support modern workloads including AI and IoT, and unsupported infrastructure introduces significant security risks. These are not aspirational concerns. They are the operational reality for many NHS Trusts today.

The EPR and FDP Programmes Require It

The two most significant infrastructure programmes running across NHS Trusts right now, EPR implementation and FDP adoption, both assume a capable local data environment. Neither delivers its potential value if the surrounding data architecture is fragmented and undocumented.

EPR as a Trigger, Not a Destination

EPR go-live is often treated as the end point of a digital transformation programme. In practice it is closer to the beginning of the data architecture challenge. An EPR consolidates clinical data capture and creates a system of record for patient activity. What it does not do is solve the analytical data problem, rationalise the legacy estate running alongside it, or connect clinical data to operational and corporate systems in a governed way.

The EPR that goes live into an unconstructed surrounding data architecture will, over time, become another data silo. Better than what it replaced, but still isolated from the analytical, population health, and operational intelligence capabilities that were part of the original business case. Trusts that invest in cloud data architecture in parallel with EPR implementation, defining the roles and data flows between the EPR, the FDP, and a Trust-managed analytical layer before go-live, are the ones that extract the full value of the EPR investment.

FDP Value Depends on Local Data Foundations

The NHS Federated Data Platform delivers operational tools for waiting list management, theatre optimisation, discharge planning, and population health. Early adopters have reported meaningful improvements: measurable increases in surgical throughput, better theatre utilisation, and reductions in patients with extended lengths of stay. These outcomes are real, but they are not automatic.

As the BCS has noted, data quality must be assured at the EPR and local system level before data flows into the FDP. The FDP amplifies the capability of Trusts that have sound local data foundations. It surfaces the gaps in Trusts that do not. A cloud-first local data strategy is what ensures a Trust's FDP participation produces insight rather than noise.

AI and Analytics Cannot Run on Legacy Infrastructure

The NHS's ambitions for AI-assisted clinical decision-making, predictive analytics, population health management, and operational forecasting all share a common dependency: a data environment that is accessible, consistent, structured, and governed. Legacy on-premises environments, by their nature, are not built for this. Data is siloed by system and site. There is no unified analytical layer. Access to data for analytical purposes requires bespoke engineering that is expensive and brittle.

Cloud data platforms, by contrast, are designed for analytics at scale. Azure Data Lake, Microsoft Fabric, Google BigQuery, and their equivalents provide scalable, queryable, integrated data environments with built-in governance, access control, and audit capabilities. The shift from on-premises to cloud is not just a matter of where data is stored. It is a shift in what can be done with it.

NHS Trusts that are investing in AI pilots and data science capabilities without first establishing a cloud data foundation are consistently finding that the bottleneck is the data environment, not the analytical tools. The tools work. The data cannot be accessed, integrated, or trusted at the quality required to make them work in production.

Cloud infrastructure is not a destination for data that already works well. It is the foundation that makes a new class of capability possible.

What Cloud-First Means in Practice

Cloud-first is a design principle, not a mandate for immediate wholesale migration. In the NHS context, it means that new systems and capabilities are designed for cloud deployment by default, and that existing on-premises systems are migrated according to a sequenced, risk-based roadmap rather than maintained indefinitely.

For most NHS Trusts, the practical shape of a cloud-first data strategy involves three tiers. A Trust-managed cloud data repository, built on Azure, Google Cloud, or an equivalent platform, serves as the primary analytical and operational data layer for locally generated insight and research. The NHS FDP serves as the national analytics and population health layer, receiving structured data feeds from the Trust's own systems. The EPR serves as the system of record for clinical data, with defined integration standards, preferably FHIR R4, governing data flows between these platforms.

Getting to this state from a fragmented on-premises starting point requires a structured transition. That means starting with discovery: understanding what the current data estate actually consists of, how data flows between systems, where the quality and governance gaps are, and what dependencies exist that will affect migration sequencing. It means designing the target architecture before beginning migration, not discovering the architecture incrementally as work proceeds. And it means building the governance framework, data ownership, retention schedules, access controls, in parallel with the technical work, so that what is migrated to cloud is governed, not simply moved.

The Hybrid Phase Is Inevitable: Plan for It

No NHS Trust of any meaningful scale will move from its current on-premises environment to a fully cloud-native data estate in a single programme. The transition will be phased, spanning multiple years, and will necessarily involve a period during which on-premises and cloud environments coexist.

Planning for this hybrid phase, rather than treating it as a transitional inconvenience, is one of the most important design decisions in a cloud-first strategy. Data flows between on-premises and cloud environments need to be defined and governed. On-premises systems that cannot be immediately migrated need to be secured and managed as first-class components of the estate, not neglected while attention focuses on the cloud build.

The hybrid phase is also where the most significant risks to EPR and FDP value reside. If on-premises data sources are not feeding cloud platforms with clean, timely, structured data, the analytical capabilities built on those platforms will underperform. A well-designed hybrid architecture acknowledges this dependency and addresses it directly.

Where to Start

For NHS digital leaders who recognise the case for a cloud-first data strategy but are uncertain where to begin, the sequence is relatively consistent across Trusts of different sizes and starting points.

1. Conduct a current-state discovery first. A cloud-first strategy that is not grounded in a clear understanding of the existing estate, its systems, data flows, quality characteristics, and governance gaps, will produce a target architecture that cannot be reached from where the Trust actually is.

2. Define the target architecture before committing to platform decisions. The choice of cloud platforms, integration standards, and data services should follow from a clear understanding of what the Trust needs the architecture to do: which analytical capabilities, which national integrations, which operational tools.

3. Align the cloud strategy with the EPR programme from the outset. If an EPR is in procurement or implementation, the surrounding cloud data architecture needs to be designed in parallel, not after go-live. The boundaries between EPR, FDP, and Trust-managed platforms need to be defined before each programme makes decisions that close off architectural options.

4. Sequence migration by risk and value, not by technical simplicity. The on-premises systems that present the highest security and compliance risk, unsupported SQL Server versions, legacy integration engines, undocumented local databases, should be prioritised in the migration roadmap regardless of how complex they are to move.

5. Build governance into the architecture, not onto it. Data ownership, retention schedules, access controls, and DSPT compliance requirements need to be embedded in how the cloud environment is designed, not applied retrospectively after data has been migrated.

Where VE3 Can Help

VE3 works with NHS Trusts to develop and deliver cloud-first enterprise data architecture strategies, from initial discovery of the current-state estate through target architecture design, EPR and FDP alignment, governance framework development, and phased transition roadmap planning.

Our approach is grounded in the realities of NHS data environments: the complexity of multi-site estates, the dependencies of concurrent EPR and FDP programmes, the information governance obligations that shape every architectural decision, and the practical workforce and capability constraints that determine what is deliverable. If your Trust is developing or reviewing its data strategy and wants a clear, evidence-based view of where to start and how to sequence the work, we would welcome the conversation.