What starts a cloud repatriation conversation?
In our experience it is rarely the monthly bill on its own, because bills tend to creep and people get used to them. The trigger is usually an event that forces someone to look at three years in one go: a reserved capacity or enterprise agreement renewal, a refresh decision on the kit that stayed behind, or, for financial services and insurance clients, a regulator asking to see a credible exit plan.
The Prudential Regulation Authority (PRA) has expected the firms it regulates to have stressed exit plans for material outsourcing for some time. Since HM Treasury designated AWS, Google Cloud, Microsoft and Oracle as critical third parties to the UK financial system from 13 July 2026, boards have been asking a sharper question: if we had to leave, could we? That question, more than the invoice, is what opens the conversation. The Google Cloud London outage on 20 October 2026 has given it fresh urgency.
Which workloads should move, and which should stay?
The dividing line is predictability. Workloads that run flat out, around the clock, at a known size, with large volumes of data sitting next to them, are the candidates. In insurance and financial services that typically means core policy administration and claims databases, and large SQL Server instances where per-core licensing on cloud virtual machines quietly outstrips the compute.
What stays in the cloud is everything that earns its keep through elasticity, or through being someone else’s problem: Microsoft 365, identity, email security, backup and disaster recovery targets, customer-facing web services and anything seasonal. If a workload’s utilisation graph is a flat line, you are paying a premium for flexibility you never use.
What does cloud repatriation look like in practice?
In our experience, it is usually gradual rebalancing. Barclays’ CIO survey at the end of 2024 found more than 80 per cent of CIOs planning to move some workloads back to private cloud or on-premises. Yet IDC puts the share of organisations planning full-scale repatriation at only around 8 to 9 per cent. Most organisations are moving specific workloads rather than leaving public cloud.
What I see is a correction to the lift-and-shift decisions of 2019 to 2021, when servers were moved wholesale without anything being redesigned for the platform they landed on. In most cases, what is being reversed is those decisions rather than the cloud itself.
Who pushes for the move, and who pushes back?
The push usually starts in finance, when the CFO notices the line item growing faster than revenue. Engineering then makes the case workload by workload, and security has the final say on whether the risks are acceptable. Pushback comes from two places. Engineering teams worry, rightly, about losing the automation and managed services they have come to rely on, and about who handles the escalation at three in the morning. Boards worry that going back looks like retreat.
In our experience, what settles it is a three-year total cost comparison, workload by workload, that counts people and licences as well as hardware.
What makes the cloud bill hard to justify?
Three cost drivers come up again and again. First, licensing: Windows Server and SQL Server on cloud virtual machines, where the licence can dwarf the compute. The Competition and Markets Authority’s decision in March 2026 to open a strategic market status investigation into Microsoft’s business software, prompted by concerns about its cloud licensing, shows this is not a niche complaint.
Second, over-provisioning that nobody owns. Harness’s FinOps in Focus 2025 research, carried out by Coleman Parkes among 700 engineering leaders and developers in the US and UK, projected that 21 per cent of enterprise cloud infrastructure spend, some $44.5bn, would be wasted in 2025. Third, the lines that never appeared in the original business case: egress, premium storage tiers, backup retention and a logging bill that grew while nobody was looking.
The first two can be fixed without moving a single server. A licensing review and proper cost management often find the money a repatriation business case was counting on. A fair share of repatriation projects are really FinOps projects in disguise.
How have 2026 price changes altered the sums?
Not in the direction the headlines suggest. AWS raised prices for its EC2 Capacity Blocks for GPU instances by around 15 per cent in January 2026 and by around 20 per cent again from 1 July, which ends the comfortable assumption that cloud unit prices only ever fall.
The bigger shift is on the other side of the ledger. The AI build-out has starved conventional server memory, and TrendForce expects server DRAM contract prices to rise by a further 13 to 18 per cent quarter on quarter in the third quarter of 2026. Anyone running a repatriation model built on 2024 hardware quotes should rerun it. At the same time, Microsoft’s commitments to the CMA extend the free egress period for UK customers leaving Azure from 60 to 180 days, which makes an exit cheaper to carry out. The net effect is that clients are now reading contract terms as closely as price lists, and doing the sums in both directions.
When does owning hardware make financial sense?
Owning makes sense when three conditions hold together. The workload runs at a steady, high utilisation, which I would expect to be above 60 to 70 per cent most of the time. Its shape will stay stable for the life of the hardware, which is five years or more, not 18 months. And you have, or can buy through a managed service provider, the people to run it properly. Remove any one of those and the maths flips back towards the cloud. A business growing quickly, or about to make an acquisition, should not lock itself into capacity it has guessed at.
The costs people underestimate are rarely the servers. They are the people, because round-the-clock cover is five or six salaries, not one clever engineer; the security tooling and patching discipline that used to come with the platform; colocation and power, which have not become cheaper in the UK; and the refresh cycle you have just signed up for again. The cloud bill disappears, and a salary bill, a colocation contract and a 2031 hardware refresh arrive in its place. Managed infrastructure services can take on the first of those, but not the others.
Does AI change the repatriation calculation?
For the mid-market, the AI debate is more headline than hardware. Most organisations are not training foundation models. They are running inference, largely through Microsoft 365 Copilot and Azure OpenAI, and that kind of use rarely justifies buying GPU hardware.
It gets more interesting with steady, high-volume inference against sensitive data, such as document classification in claims handling, where a modest on-premises GPU server can pay for itself if it runs constantly. But GPU availability, the speed at which the hardware dates and the price of memory all pull the other way. My advice is to rent AI capacity until your usage graph flattens, then do the maths.
Is data sovereignty a reason to repatriate?
The questions have moved from cost to control, particularly in insurance and financial services. In June 2025, Microsoft France’s director of public and legal affairs told a French Senate inquiry under oath that he could not guarantee customer data would never be passed to US authorities. That admission still gets quoted in client meetings.
In practice, the real control problem is rarely where the data lives. It is who can see it. Copilot surfaces everything a user has permission to open, and most organisations’ permissions are a decade of accumulated generosity. Fix that first. For the genuinely sensitive cases, UK regions, customer-managed encryption keys and a private deployment usually satisfy the regulator long before anyone needs to buy hardware. In most cases sovereignty is a governance problem, and buying hardware does not solve it.
What happens when repatriation is done for the wrong reasons?
The journey is rarely a simple there and back. Earlier in my career I worked with an organisation that moved its estate out of its own data centre into a service provider’s private cloud, brought it back on-premises, and eventually landed in Azure. Three moves, three business cases, and each one paid again for the migration before it.
What went wrong was never really the platform. Each move was a reaction to the pain of the last one rather than a decision about which workloads belonged where. The business case counted the hardware and underplayed the operating model: the skills, the processes and the people needed to run it well. In our experience, repatriation decided workload by workload tends to last; a move made out of frustration with a bill often does not.
The question to ask before moving anything
For a CIO or CTO, the question to answer first is whether the problem is the platform or the way it is being used. Without evidence for that answer, meaning a three-year view of cost by workload that includes people, licensing and the cost of leaving, an organisation is not ready to move anything. When the numbers do say move, move the flat, heavy, predictable workloads, leave the rest where they are, and write the exit plan for the next move before you make this one.
If you are weighing up where your workloads should run, our cloud and Azure cloud management teams can help you build that workload-by-workload view. Get in touch to talk it through.