"Cloud-first" is settled NHS policy. What's rarely settled is what it means on a Tuesday morning for the team that actually runs a hundred-plus on-premises SQL Servers, a thousand-odd databases, and well over 100TB of data accumulated across a decade of mergers, projects, and good intentions. The strategy says cloud. The estate says not so fast.

The gap between policy and reality is where cloud-migration programmes go wrong. Treat it as a big-bang lift to the cloud and you'll either stall under the weight of the estate or move your problems wholesale - paying cloud prices for on-prem mess. Treat it as "later" and you carry rising data-centre costs, ageing hardware, and unsupported software versions indefinitely. This post sets out the pragmatic middle path: a phased, evidence-led migration that honours the NHS cloud-first ambition without betting the trust on a single risky cutover.

Cloud-first does not mean cloud-only

Start by retiring the most damaging misconception. The NHS Cloud Centre of Excellence is explicit that cloud-first does not require the entirety of an on-premises data centre to be migrated. There can be sound reasons to keep certain workloads on-premises - for example where cloud cannot meet specific regulatory or latency requirements.

That single point changes the whole conversation. The goal is not "empty the data centre by a deadline." It's to make a deliberate placement decision for every workload, based on its characteristics, and to move first what benefits most. Cloud-first is a default and a direction of travel, not an absolute. Naming that openly takes the fear out of the programme and makes the difficult cases (the genuinely cloud-resistant workloads) defensible rather than embarrassing.

You can't migrate what you haven't assessed

Every credible migration begins with discovery and assessment, not procurement. Before deciding where anything should run, you need an accurate inventory: which servers and databases exist, their SQL versions, size, performance profile, dependencies, the data they hold, and how business-critical they are.

Two things make NHS estates harder than the generic enterprise case, and both must be surfaced in assessment:

• Version sprawl and support risk. A large estate routinely runs several different SQL Server versions simultaneously, some out of mainstream support. Consolidating to a smaller set of supported versions is often a stronger early win than any cloud move - it reduces security and licensing risk immediately.

• The shadow estate. The hundreds of ungoverned databases and spreadsheet-grade tools that feed real workflows but appear in no inventory. (We've written separately about getting a grip on the shadow Access estate; the same discovery discipline applies here.)

The assessment output is a classified portfolio: every workload tagged with a migration decision. The widely used "Rs" framework gives you the vocabulary - retire, retain, re-host, re-platform, re-purchase, re-architect - and the NHS CCoE recommends scoring each application on technical, business, security, and compliance characteristics to choose between them.

Choosing the right "R" for each workload

The art is matching effort to value. Not everything deserves re-architecting, and not everything can simply be lifted and shifted.

• Retire the redundant. The cheapest migration is the one you don't do. A meaningful share of any large estate is duplicated, abandoned, or superseded data that should be securely decommissioned under the NHS Records Management Code, not moved.

• Retain the genuinely cloud-resistant - for now. Where latency, regulation, or a hard dependency makes cloud unsuitable, document the decision and revisit it later. Honest retention beats a forced migration that fails.

• Re-host (lift and shift) the straightforward. Stable databases with no pressing need for optimisation can move with minimal change to establish momentum and free up data-centre capacity.

• Re-platform (lift and reshape) the good candidates. Moving an on-prem SQL Server to a managed cloud database service removes the burden of managing underlying infrastructure and is often the NHS sweet spot - real cloud benefit, moderate effort.

• Re-architect only where it pays. Reserve the highest-effort, highest-cost option for the workloads where cloud-native characteristics genuinely transform performance or capability.

The discipline of assigning one "R" per workload - with the rationale recorded - is what turns an intimidating 100TB into a sequenced, governable plan.

Sequence by risk, not by size

A common instinct is to migrate the biggest databases first to "get them out of the way." Resist it. The CCoE's own guidance is to begin with low-risk applications, so the organisation can absorb the impact of any mistakes without jeopardising the whole initiative.

A sensible wave sequence looks like this:

1. Wave 0 - rationalise. Retire redundant data and consolidate unsupported SQL versions to a supported baseline. Much of this can happen before any cloud move and de-risks everything after it.

2. Wave 1 - low-risk, high-learning. Migrate non-critical, well-understood workloads first. The objective is as much to mature your cloud landing zone, security controls, and team confidence as it is to move data.

3. Wave 2 - the bulk. With patterns proven, migrate the main body of re-host and re-platform candidates in managed batches.

4. Wave 3 - critical and complex. Tackle the high-stakes, heavily integrated systems last, when your tooling, runbooks, and team are battle-tested.

Each wave should leave behind reusable patterns - a landing-zone blueprint, a tested migration runbook, a rollback plan - so the programme accelerates rather than reinventing itself every time.

Hybrid is the operating reality, not a failure state

Because cloud-first isn't cloud-only, and because you migrate in waves, your estate will be hybrid for a meaningful period - and some of it possibly forever. That is normal and should be designed for deliberately, not treated as an awkward transitional embarrassment.

Designing for hybrid means: secure, performant connectivity between on-prem and cloud; clear data-residency and governance rules that hold across both; and a cloud landing zone built to NHS security expectations from day one rather than retrofitted. It also connects directly to your wider data architecture - your cloud-first data layer is where bespoke analytics, research workloads, and data-quality assurance increasingly belong, and where data is readied before it flows up into national platforms. (That division of labour between your local layer, the EPR, and the FDP is the subject of our piece on drawing the three boundaries.)

The cost conversation, handled honestly

Cloud migration is sold on savings, and the savings can be real - on-premises data-centre costs are rising year on year, and shifting from capital-heavy hardware refresh cycles to a consumption model is genuinely attractive to NHS finance. But the honest version includes the caveat: lift-and-shift without rationalisation and right-sizing can simply relocate cost, not reduce it. The savings come from retiring what you don't need, right-sizing what you keep, and using managed services to cut operational overhead - which is exactly why the assessment and rationalisation work up front matters so much. Promising board-level savings without doing that groundwork is how cloud programmes lose credibility in year two.

It also helps to frame the business case beyond pure cost, because a like-for-like cost comparison rarely tells the whole story. The stronger case for an acute trust combines several strands: removing the security and support risk of unsupported software; freeing scarce technical staff from infrastructure babysitting to higher-value work; gaining the elasticity to stand up analytics or research environments in days rather than procurement cycles; and reducing the carbon footprint of an ageing on-premises estate, which increasingly features in NHS sustainability commitments. Present cloud-first as a risk, capability, and sustainability decision as well as a cost one, and it becomes far more defensible to a board than a savings figure that may or may not materialise.

A practical first step: five questions before you migrate anything

1. Do we have an accurate inventory of every SQL Server, database, version, and dependency - including the shadow estate?

2. What can we retire or consolidate first, before any cloud move, to cut risk and cost immediately?

3. Have we assigned a migration strategy (an "R") to each workload, with the rationale recorded?

4. Are we sequencing by risk - low-risk, high-learning workloads first - rather than by size?

5. Have we designed deliberately for a hybrid period, with secure connectivity and governance spanning both environments?

Answer those five with evidence and you'll have something most "cloud-first" programmes lack at the outset: a plan that respects both the ambition and the estate.

At VE3, we help NHS acute trusts turn cloud-first policy into a pragmatic, phased migration - assessing and rationalising large legacy SQL estates, sequencing the move by risk, and designing a secure hybrid landing zone aligned to the NHS Cloud Centre of Excellence framework. If you'd like our cloud-migration readiness checklist, get in touch.