Half of organisations spent more on public cloud than they had planned for last year. According to IDC research, reported by ITPro, 59% expect the same to happen again this year. That gap between what businesses expect to spend and what they actually spend is usually what starts the repatriation conversation. It is also where the next miscalculation begins.
Most businesses compare two numbers: what they spend on public cloud now, and what a private cloud, colocation or other UK-hosted setup would cost instead. But by the time repatriation is on the table, the workload is rarely the same one that first moved into public cloud. Data volumes have grown, integrations have multiplied, security controls have become embedded, and teams have built processes around the current platform.
That can still leave a strong case for moving some workloads back to UK infrastructure, particularly where demand is predictable or data location matters. The mistake is assuming the saving starts when the decision is made. Before any long-term saving appears, the business has to pay for the exit, rebuild what needs to change, redesign the network and keep services running while the move happens.
Here, Mark Lewis, Chief Marketing Officer at Pulsant, offers his insights.
The cost of getting out
Moving data out of the public cloud is usually the first cost that catches businesses out. AWS’s own guidance confirms that sending data out is charged by service and by region. Azure’s pricing works the same way once you go over the free monthly limit. For a business holding years of backups, analytics data or AI datasets, that single charge can become one of the largest line items in the whole project.
Most businesses don’t know how much data needs to move, how often it moves, or which systems depend on it, and that gap matters more than the price per gigabyte they’ve been quoted. A storage estate that looks simple on a slide often turns into a much bigger financial job once you count the transfer volumes and the duplicate environments needed during the move.
The Competition and Markets Authority has flagged data egress fees as a genuine barrier to switching providers across the UK market. Egress fees limit how easily a business can change its mind later, which is exactly why the exit cost needs pricing into the plan from day one, before the decision has already been made.
Mark Lewis, Chief Marketing Officer at Pulsant, says: “Egress is often the first cost that makes businesses go back and check their numbers. It’s rarely the whole story, but it’s usually the moment a simple repatriation plan starts to look more complicated.”
What changes once workloads move
The bigger bill usually sits inside the applications themselves. A workload that started life as a straightforward lift-and-shift often picks up new dependencies over time: managed databases, monitoring tools, identity services, security controls built specifically for that platform. Moving it back means replacing all of that, rewriting the connections between systems, and testing it properly under real demand. None of that work shows up in a simple comparison between two hosting bills.
A team that has spent years mastering one cloud provider’s tools won’t automatically have the same depth in private cloud, colocation or hybrid network design. Some businesses already have that expertise in-house. Others need outside help, or time to build it themselves. Either way, it must be priced into the plan, rather than assume it will sort itself out.
A workload can leave the public cloud and still depend on SaaS tools, APIs or cloud-hosted data, so connectivity needs just as much planning as the rest of the move. Get the network design wrong and the business ends up with new latency problems, higher traffic costs, or weaker resilience. Bandwidth, private connections, backup paths and security all need designing before the move happens, before something breaks and forces the issue.
Downtime is the hardest cost to put a number on, but it’s often the most expensive one. A safe move usually means running the old and new systems in parallel for a while, testing thoroughly, and rolling out in stages rather than all at once. All of that protects the business, but it also takes time and budget that early estimates tend to leave out.
Mark says: “The saving businesses expect from repatriation can disappear entirely if they only compare monthly hosting costs. Data movement, application changes, connectivity, testing and downtime all need to be part of the business case from day one.”
How to keep the move under control
A better plan starts with an audit of every workload before anything moves. Each one gets assessed against the same criteria:
-
Data volume and movement: how much data it holds, how often it moves, and what egress charges apply.
-
Application dependencies: which databases, monitoring tools, identity services, security controls and integrations it relies on.
-
Compliance requirements: what rules apply around data location, access, resilience and auditability.
-
Operational importance: how critical it is to customers, staff, production or reporting.
That assessment then decides the order of the move. Predictable workloads, large storage systems and applications with limited platform-specific dependency tend to be safer early candidates. Complex systems tied deeply into one provider’s services are usually better left until later, once the easier moves have given the business real evidence to work from.
Cost control means tracking three numbers separately:
-
The cost of leaving the old platform
-
The temporary cost of running both environments side by side
-
The ongoing cost once the workload has settled into its new home
Without all three, a repatriation project can look far cheaper on paper than it feels once the work is under way.
Placing workloads instead of repatriating everything
Most successful repatriation plans are selective rather than sweeping. IDC’s own research found that only eight to nine per cent of companies plan to repatriate a workload completely. Most move specific pieces instead: things like production data, backup processes or specific compute jobs. Lewis sees the same pattern: “Cloud repatriation should start with the workload. Trying to pull everything out of the public cloud at once is usually where projects lose control of the numbers. The saving comes from knowing which applications belong where, and what they’ll cost to run once they get there.”
For UK businesses, where you move to matters as much as the decision to move. UK-hosted private infrastructure and colocation can give a business clearer control over cost, data location and performance than simply shifting the same problem to a different cloud provider. That’s especially true where a dedicated repatriation service is available to help plan the move around each workload, rather than around the destination alone.
Handled well, repatriation lowers spend and gives a business real control over its infrastructure, rather than swapping one uncontrolled bill for another. The businesses that get it right price the exit honestly and plan the destination with the same care. Then they decide, one workload at a time, what should move, what should stay, and how the two sides will connect.
Be the first to comment