After a decade of cloud mandates, the bills and the laws have caught up. Here is what the strategic reset actually demands – and where to start.
A techUK report published earlier this month gave formal language to something CIOs across the UK have been confronting in quarterly cost reviews for the past two years. “Cloud-first” strategies, it argues, are hitting “sovereignty and cost walls” – and the rethink that follows is not a minor adjustment. It is a structural question about where compute should happen, who controls the data it processes, and whether the architecture built over the last decade still serves the business.
“Repatriation” is appearing in more board-level conversations than it has since cloud migration became the default. Cloud bills are under genuine scrutiny. The UK Data Use and Access Act 2025 has made the legal geography of data storage a front-office concern rather than something quietly resolved between other priorities by the compliance team.
Cloud-first made sense when it was written. Agility, reduced capital expenditure, access to capabilities that would have taken years to build in-house – it was a reasonable trade. The problem is that the doctrine was designed for a world of experimentation, not one where AI systems run continuously on sensitive institutional data under strict legal and operational constraints. Those are different conditions. The architecture they require is different too.
The question for 2026 is no longer how much more to migrate. It is whether the architecture built around the assumption of infinite, cheap, sovereignty-agnostic cloud compute still fits the business it is supposed to serve.
The egress tax nobody planned for
Cloud economics were sold on a simple premise: compute and storage are cheap, so centralise everything and pay as you go. What the original mandates underestimated was the cost of moving data around.
Egress fees – the charges cloud providers levy when data leaves their environment – were an afterthought in early cloud contracts. They are a meaningful budget line in 2025. For organisations running analytics workloads, serving AI inference across environments, or simply trying to get data off a platform they no longer want to be locked into, those fees have become a structural drag on cost efficiency. Industry analysis puts the additional cost attributable to indiscriminate cloud-first architectures at around 15 per cent of total cloud spend, though the figure varies significantly by workload type and provider.
AI has compounded this considerably. Production AI systems do not query data once a day when a scheduled job triggers. They run continuously, at a volume that makes human-driven analytics pipelines look sedate. Egress costs that were manageable for batch workloads become a different proposition altogether when agents are querying at machine speed across environments. The invoice eventually reflects that difference.
It does not sound catastrophic until you apply it to a cloud bill that has grown year on year for a decade, and then ask which portion of that expenditure is genuinely buying capability that could not be delivered cheaper elsewhere. For a growing number of organisations, the honest answer is uncomfortable.
Sovereignty is no longer a legal team problem
The UK Data Use and Access Act 2025 formalised something that was already causing operational headaches – the idea that the legal jurisdiction under which data is held is a business decision, not a technical detail to be sorted after the architecture has been agreed.
For public sector organisations, this has always been a constraint. What has changed is the scope. Private sector firms handling health records, financial data, or personally identifiable information at scale are now navigating requirements that make “put it in the cloud” an inadequate default. The US CLOUD Act, which allows extraterritorial access to data held by US-domiciled cloud providers regardless of where the physical servers sit, has added a layer of complexity that even well-intentioned cloud strategies did not account for.
The result, as the techUK report describes it, is that organisations face three genuinely unattractive options for AI workloads. Move data to the cloud and absorb the cost and sovereignty risk. Keep it on-premises and lose access to modern AI tooling. Or manually orchestrate across environments and accumulate operational complexity that compounds over time. None of these scales cleanly. All three create debt that someone will have to pay off.
What makes the 2025 Act particularly significant is that it shifts the accountability question. Where previously a legal review might conclude that a given cloud arrangement was probably compliant, the legislation demands something more specific: documented evidence of where data sits, what it contains, and under whose jurisdiction it falls. That is not a one-time audit exercise. It requires architecture that surfaces that information continuously.
What “data-first” actually means
The shift being described as “data-first” is not simply a euphemism for cloud scepticism, nor a return to on-premises infrastructure as the default. The core claim is more precise: compute should move to where data resides, rather than data being moved to where compute is most convenient.
In practice, this means building a unified data layer – often called a data fabric – that spans on-premises infrastructure, cloud environments, and edge locations without treating any single tier as the canonical home for all workloads. Data stays where regulatory, cost, and latency considerations suggest it should. Compute is deployed to meet it there.
Organisations doing this well are not simply moving workloads back from the cloud. They are redesigning the question itself. Instead of asking “what is our default compute environment?”, they are asking “where does each workload make most sense to run, given the data it depends on, the regulation it falls under, and what it actually costs?” That is a harder problem to manage. It is also the more honest one.
According to Broadcom’s 2026 private cloud analysis, cloud repatriation has moved from ad-hoc cost cutting to a deliberate strategy for control, resilience, and sovereignty – with executive teams deciding which data, AI workloads, and control planes must sit on infrastructure they directly govern. That is a materially different conversation from the one that produced the cloud-first mandate.
Building the fabric without starting over
A data fabric is not a product. It is an architectural outcome, built using components that can include cross-environment storage platforms, data catalogue tooling that operates consistently across on-premises and cloud tiers, and governance frameworks that apply policy uniformly regardless of physical location. Assembling those components into something that actually functions as intended, without creating a new set of integration problems in the process, is where most implementations encounter difficulty.
The specific requirements are worth being direct about.
Governance must be environment-agnostic. Policy on access, classification, and retention cannot be applied thoroughly in the cloud tier and approximated everywhere else. It has to work consistently. Two parallel frameworks with informal bridges between them eventually create more cost than the problem they were meant to solve.
Metadata needs to travel with data. When a dataset moves from an on-premises store to a cloud environment for processing, its lineage, classification, and access policies should travel with it as a matter of design rather than manual re-entry. That is the difference between a governance model and a governance intention.
Storage infrastructure should not create new lock-in. Open table formats such as Apache Iceberg allow cross-environment querying without relocating data, which matters significantly when the alternative is paying egress fees every time analytics runs across environments. The format choice made now determines what rebalancing costs later.
Cost visibility needs to work at workload level. Total cloud spend figures are not granular enough to support repatriation decisions. The question is which specific pipelines are net positive at their current location, and which are paying a premium without measurable return. Without that granularity, any rebalancing exercise is guesswork with a business case attached to it.
What this does not mean
The data-first argument is sometimes misread as an instruction to pull everything back from hyperscale cloud. That is not what the evidence supports, and it is not what the better-run implementations look like.
Cloud infrastructure has genuine advantages for specific workloads. Compute-intensive model training, globally distributed applications requiring consistent low-latency access, and workloads that depend on managed services with no viable on-premises equivalent – these sit well in the cloud. The problem is not that cloud is wrong. It is that “cloud-first” as a blanket mandate, applied indiscriminately to workloads for which those advantages do not apply, has produced architectures carrying avoidable cost and complexity.
The shift is from a default to a decision. Where cloud is the right answer for a given workload, it remains the right answer. Where the data residency requirements, the economics, and the operational characteristics point elsewhere, the architecture should follow the evidence rather than the mandate.
The organisations finding the most meaningful cost reductions are not those performing wholesale repatriation. They are those with sufficient workload-level visibility to distinguish the justified cloud spend from the inertial cloud spend – and then acting on that distinction.
Q&A: Getting to grips with the data-first shift
Does adopting a data-first approach mean abandoning our cloud investments?
No. What it means is that cloud becomes one option in an architecture built around where data should sit, rather than the assumed destination for everything. Workloads that genuinely benefit from hyperscaler infrastructure – compute-intensive training, globally distributed applications, services requiring access to managed cloud tooling – remain well placed in the cloud. The candidates for review are the workloads that migrated under a blanket mandate and have been paying an ongoing premium without clear operational justification.
How do we identify which workloads are candidates for repatriation or rebalancing?
Start with cost at workload level, not total cloud spend. Workloads with high egress costs relative to compute value, or those processing data that faces residency requirements, are the first candidates to examine. A structured assessment of your current estate – mapping workload location against cost, regulatory status, and AI dependency – typically surfaces the majority of the opportunity within a few weeks. The difficulty is rarely in identifying the candidates once you have the data. It is in getting the data in the first place.
The UK Data Use and Access Act 2025 is already in force. What do we need to do differently?
The most immediate requirement is knowing where regulated data actually sits and under whose legal jurisdiction it falls. For organisations with data held by US-domiciled cloud providers, the question of CLOUD Act exposure deserves specific legal review alongside technical assessment. The governance layer of a data fabric – the part that tracks classification and residency at data level rather than infrastructure level – is what makes compliance manageable at scale rather than a per-workload exercise repeated across the estate.
What is the realistic starting point for building a unified data fabric?
The most common mistake is treating this as a migration project – deciding on the target architecture first and then planning a cutover. The more effective starting point is a current-state assessment that maps your data flows, identifies where cost and compliance risk are concentrated, and defines the governance model before touching infrastructure. The architecture should follow the data and the risk; it should not precede them. Starting with governance rather than infrastructure also means the work does not require a big-bang change to services currently in production.
Is this primarily a concern for large enterprises, or does it apply to mid-market organisations too?
The egress cost issue applies broadly, though the scale differs. The sovereignty questions are particularly acute for organisations in regulated sectors – financial services, healthcare, legal – regardless of size. What varies is the complexity of the solution: a mid-market firm may be able to address the core issues with targeted storage and governance changes rather than a full-scale fabric implementation. The principle that data placement should be a decision rather than a default applies at any scale.
Working through this with Vertex Agility
The shift from cloud-first to data-first is a genuine architectural rethink, not a vendor trend with a new name. The forces driving it – escalating egress costs, tightening data residency law, and the demands of production AI workloads – are structural. They do not reverse when the next platform announcement arrives.
What the shift asks of organisations is clarity: about where their data lives, what it costs to move it, and what legal obligations govern its location. That clarity is harder to achieve than the original cloud-first mandate, which had the virtue of simplicity. But the simplicity of “cloud-first” was part of the problem.
Vertex Agility’s Cloud Consultancy practice designs and implements scalable cloud architectures across AWS, Azure, and Google Cloud – and critically, the hybrid and multi-environment architectures that sit between them. Our Data Consultancy practice works with organisations to build the kind of scalable data infrastructure that a data-first approach requires: from current-state assessment and workload cost analysis through to data fabric design, unified governance models, and the pipeline architecture that makes cross-environment data access operationally manageable.
If your cloud bills have been growing while your confidence in where your regulated data sits has been shrinking, those two trends are connected. Getting control of both starts with understanding the current estate clearly before making any infrastructure changes.
Our AI Consultancy sits alongside this work. Production AI performance is directly tied to where data sits, how consistently it is governed, and whether the architecture around it was designed for continuous machine-speed access or for scheduled batch jobs written by humans. Getting the data architecture right is not a prerequisite that precedes AI strategy – it is part of the same programme.
If you want an independent view of where your current architecture stands, we offer a free AI Readiness Mini Audit on our website. For something more substantive, get in touch with us directly below.