AISTORS ServicesWorkload placement and repatriation

Service 07

Each workload where it actually belongs.

Move the few that are cheaper. Leave the rest alone.

For teams under pressure to cut cloud cost who are being sold a wholesale move in one direction or the other. Most workloads should stay where they are. A small number are genuinely cheaper elsewhere. A few cannot lawfully sit where they sit today. We work out which is which, per workload, and put the reasoning and the exit cost in writing.

Book a 30-minute call

Two engineers at a large wall-mounted monitor in a bright office, the screen split between a grouped architecture diagram and a paired bar comparison, one of them pointing at a bar. — How the decision gets made
Each workload is compared on full run cost, including the people the platform was quietly absorbing. For most of the list the honest answer comes back as leave it alone.

Who this is for

If the left column is not you, say so on the call and we will tell you what would help instead.

This is for you if

Somebody has proposed a wholesale move. In either direction, and you want the decision made per workload on evidence rather than on a slide.
A few workloads have predictable, heavy load. Steady high compute with low egress is where the arithmetic genuinely changes, and it is worth checking properly.
Residency or sovereignty rules apply to you. Where data may sit is a constraint that decides the answer before cost gets a say, and it needs recording.
Your egress charges are material. Enough that data movement is a line somebody notices, which usually means data gravity is doing real work in the decision.
You want the exit cost written down. Before the next commitment, not after. This is the single most commonly skipped piece of analysis in cloud strategy.

This is not for you yet if

You want an argument against cloud. We will not supply one. The evidence does not support a general answer in either direction and we would be inventing a conclusion.
The estate is small and simple. Below a certain size the placement question answers itself and the assessment costs more than the decision is worth.
Nobody will share the bill or the inventory. Placement without usage and cost data is opinion. We need read-only access to both or there is nothing to analyse.
The workloads are still changing weekly. Placement decisions on a moving target go stale immediately. Let the architecture settle, then decide.
You need the answer this week. Dependency and egress analysis takes as long as it takes. A fast placement answer is a guess wearing a spreadsheet.

What we fix, and how

Four things go wrong with placement decisions. All four come from deciding at estate level rather than per workload.

PROBLEM 01

The decision is being made wholesale

What we do. We assess per workload, and most of the list comes back as leave it alone. A single estate-wide verdict in either direction is almost always somebody's position rather than your business case.

PROBLEM 02

The savings case ignores the people

What we do. We model the full run cost on both sides, including staffing, resilience, hardware refresh and the operational work the platform was quietly absorbing. That is usually where a repatriation case falls apart.

PROBLEM 03

Nobody wrote down how to reverse it

What we do. Exit and lock-in analysis is part of the assessment. You get the cost of undoing each decision before you make it, and where we cannot estimate that cost we record that as a finding in its own right.

PROBLEM 04

Sovereignty was treated as a preference

What we do. It is a requirement. Where rules dictate that a workload cannot sit in a region or under a jurisdiction, that constrains the answer before cost does, and the constraint is documented so the next person understands the architecture.

What you get

Five deliverables, each of which can conclude that nothing should move.

What we build

Workload placement assessment. Every workload scored on predictability, data gravity, egress, licensing, latency, regulatory position and who you can hire, with the recommendation and reasoning recorded per workload.
Hybrid architecture design. Where the answer is genuinely split, the network, identity and operational model that lets both halves be run by one team rather than two.
Selective repatriation. Executed only for the workloads where the full run cost including people is lower, in waves, with a tested rollback at each one.
Sovereign and data-residency architecture. Where jurisdiction decides the answer, the design that satisfies it, with the constraint written into the decision record rather than remembered.
Exit cost and lock-in analysis. For each platform and each model provider in the path, what leaving would cost and how long it would take, stated before you commit further.

What this is not

Not an argument against cloud. Nor for it. The published evidence does not support a general answer, and we will not manufacture one to make the engagement simpler.
Not a wholesale migration. If the analysis says three workloads move and forty stay, that is the deliverable, even though it is a smaller piece of work for us.
Not a hardware sale. We hold no reseller relationship with any platform, colocation or hardware supplier, so there is no margin behind the recommendation.
Not a one-off verdict. Placement changes as pricing, licensing and your own load change. The decision record is built to be revisited rather than filed.
Not done without your bill. Usage and cost data are the inputs. Without them the analysis would be an opinion with a diagram attached.

How it runs

The assessment can conclude that nothing should move, and frequently does.

Inventory, dependency and egress map

What runs where, what talks to what, and how much data crosses each boundary. Egress is usually the figure nobody has to hand, and it often decides the answer on its own.

Read-only access · No production change

Full run cost on both sides

Platform cost, licensing, staffing, resilience and refresh, modelled for the current placement and each candidate alternative. The people cost is included because that is where most cases turn.

Your own billing data as the input

Constraint and sovereignty review

Which workloads are constrained by regulation, contract or residency, and what those constraints permit. Recorded as requirements before any cost comparison is allowed to override them.

Constraints recorded, not assumed

Per-workload recommendation with exit cost

Move, stay or redesign, with reasoning and the cost of reversal for each. Delivered as a document you can circulate and argue with rather than a presentation.

You keep this whatever you decide

Execution in waves, where anything moves

Only for the workloads that justified it, one wave at a time, with a tested rollback and the documentation written as the work proceeds.

Fixed scope per wave

Platform native

Placement work is platform-neutral by definition. These are the estates we assess and build across.

Azure

Landing zones, Azure Local and Arc for hybrid control, ExpressRoute for connectivity, licence mobility and Hybrid Benefit treated as a real input to the arithmetic.

AWS

Control Tower and Organizations, Outposts and Direct Connect for hybrid, egress and data transfer modelled explicitly rather than estimated.

Google Cloud

Landing zones, GKE Enterprise and Anthos for workloads that must run in more than one place, Interconnect for connectivity.

DigitalOcean and private

Lean providers and colocation for predictable high-compute workloads, with Kubernetes as the portability layer where portability genuinely earns its cost.

Portability has a price. We build for it where the exit analysis shows it repays that price, and we say plainly where it does not, because a portable architecture nobody will ever exercise is just a more expensive one.

The evidence, if you want it

You do not need these numbers to recognise the problem. They are here because somebody in your approval chain will ask.

21%

of cloud-based workloads and data were reported as repatriated by respondents, even as public cloud adoption kept rising.

Source: Flexera, 2026 State of the Cloud Report.

29%

wasted cloud spend, its first increase in five years, recorded alongside 81 percent generative AI usage.

Source: Flexera, 2026 State of the Cloud Report.

71%

say switching their primary AI vendor or model would be difficult.

Source: IBM, The Calculus of AI Sovereignty, 2026.

Read the three together and the brief is narrower than it looks. Repatriation is real but partial, and it is happening while public cloud adoption continues to rise, which means the story is placement rather than exit. Waste is rising rather than falling. And lock-in is now a model decision as much as an infrastructure one. None of that argues for moving everything. It argues for deciding each workload deliberately and recording the exit cost before the next commitment.

Questions we are actually asked

Are you telling us to leave the cloud?

No. Most workloads should stay exactly where they are. Wholesale moves in either direction are usually somebody's thesis rather than your business case. What we produce is a per-workload decision with the reasoning attached, and for most estates the majority of that list says leave it alone.

How do you decide what moves?

Predictability of load, data gravity, egress volume, licence terms, latency requirements, the regulator's position, and who you can actually hire to run it. Steady high-compute workloads with low egress are the usual candidates. Spiky, bursty and rapidly changing workloads almost never are.

What about sovereignty and data residency?

Treated as a requirement rather than a preference. Where rules mean a workload cannot sit in a given region or under a given jurisdiction, that constrains the answer before cost does, and the constraint is recorded so the next person understands why the architecture looks the way it does.

Will you tell us the exit cost before we commit?

Yes, and in writing. Exit and lock-in analysis is part of the assessment rather than an upsell. If we cannot estimate the cost of reversing a decision, we say that too, because an unquantified exit is itself a finding.

Do you have a preferred destination?

No, and no reseller relationship on any platform or colocation provider, so there is no margin behind the recommendation. Where you have already decided, we build natively on your choice and state plainly what it costs you.

We are being told repatriation will halve our bill. Is that true?

Almost never, and the claim usually ignores the staff, resilience and refresh costs that the platform was absorbing. We model the full run cost on both sides, including the people, and we have told clients the move was not worth making.

Next step

Bring the bill and the inventory.

Thirty minutes, no obligation. Tell us which workloads somebody has proposed moving and why. We will tell you what would decide it, what data we would need, and whether the case is likely to survive contact with the full run cost.

Starts with: A fixed-scope placement assessment. Read-only billing, usage and inventory access is enough to begin.
Investment: Scoped on the introductory call, and credited in full against any execution that follows.
If the answer is stay: That is a legitimate result. You keep the assessment, the cost model and the exit analysis. No further commitment.

Book a 30-minute call

Or write to [email protected].

Related work

Service 06

Cloud cost and FinOps

Before moving anything, find out what the current estate is wasting. Rightsizing usually beats relocation.

Service 05

Cloud architecture and migration

Where the analysis says build or move, this is the work that does it in waves with a rollback.

Disclosure

AI capability and data handling

Lock-in is now a model decision too. Which providers, on what terms, and what leaving each would cost.