Cloud Exit Readiness: Dependency and Repatriation Checklist

A finance team finds a workload whose Cloud bill has doubled. The natural response is to ask whether it should come home. The expensive question is not whether the server can run elsewhere. It is whether everything attached to the server can move without quietly recreating the same cost, risk and operational burden in a different building.

That is why “repatriate” is the wrong verb for most decisions. You do not repatriate an application. You relocate a dependency graph.

The practical Cloud-exit guides that rank for this topic consistently focus on workload selection, egress, vendor lock-in, continuity and a phased approach rather than a wholesale escape narrative.1 (opens in a new tab) That is the right instinct. The work is portfolio management, not an ideological referendum on public Cloud.

The workload is not the unit of analysis

A workload has at least seven surfaces: compute, data, network, identity, operations, commercial terms and people. If you score only compute price, you will systematically favour the option that looks cheap before migration and expensive after it.

Surface	Question to ask	What a weak answer looks like
Compute	Is the demand steady, bursty, latency-sensitive or specialised?	“We can buy servers cheaper.”
Data	Where does data originate, reside and move?	“We will copy it over.”
Network	What are the ingress, egress, peering and user-latency dependencies?	“Bandwidth is included.”
Identity	Which roles, secrets and access policies bind the workload to the current environment?	“The app uses SSO.”
Operations	Who patches, scales, recovers and supports it after the move?	“The infra team will own it.”
Commercials	Which commitments, licences and support contracts move or remain?	“We will save on list price.”
People	Do we have the skills and on-call capacity for the target model?	“We can hire if needed.”

A workload that scores well on three surfaces and poorly on four is not an easy migration. It is an optimistic spreadsheet with a cutover date.

Use a stage gate, not a migration wish list

The most reliable way to control a Cloud exit is to require evidence at each gate. A team should be able to stop without calling the programme a failure. Stopping is sometimes the correct outcome.

Gate	Evidence required to proceed	Stop condition
1. Economic hypothesis	Three-year cost model with Cloud, target and transition costs	Savings depend on ignored operations or egress assumptions
2. Dependency inventory	Mapped upstream/downstream services, identity and data stores	Critical dependency is unknown or immovable
3. Target design	Supported architecture, security controls and operating model	Target only works as an unowned exception
4. Migration path	Rollback plan, data-sync approach and test criteria	Cutover requires a big-bang change
5. Service proof	Performance, resilience and security test results	Service level degrades beyond accepted range
6. Operational acceptance	Named on-call owner, runbook, observability and patch plan	Team cannot support the new model at 03:00
7. Commercial close	Contract and commitment exposure understood	Savings are offset by stranded commitments or licences

This does not make migration slow. It makes hidden work visible while it is still cheap to change course.

The cost model must include the transition

A Cloud bill is a run-cost number. A repatriation decision is a lifecycle decision. Use a model with five buckets.

Bucket	Include	Typical omission
Current run cost	Compute, storage, network, managed services, support	Discount expiry and committed-use timing
Target run cost	Hardware or colocation, power, network, software, operations	Spare capacity, resilience and refresh cycles
Transition cost	Engineering time, tools, parallel run, data movement, testing	Data synchronisation and rollback capacity
Risk cost	Performance degradation, downtime, compliance and delivery delay	The business cost of an uncertain cutover
Stranded cost	Unused commitments, licences, duplicated support	Contract tail after the workload moves

Do not bury the people cost in “existing staff”. If the target requires a new on-call competence, that cost is real even if it comes from a different budget.

The egress trap works in both directions

Teams rightly question the cost of leaving a Cloud provider. They often ignore the cost of continuing to reach Cloud-resident data, identities, APIs and observability after the application moves. A workload can be physically repatriated and economically coupled for years.

Map directional data flows, not just storage volumes. For every flow, identify the source, destination, frequency, bytes, latency tolerance, encryption requirement and owner. That turns “data gravity” from a slogan into a decision record.

If a target design requires constant cross-boundary data movement, the sensible outcome may be a hybrid architecture. Hybrid is not a compromise when it puts each component where its economics and constraints make sense. It is a refusal to pretend that one placement will suit every part of the graph.

Make reversibility a design requirement

A migration plan should be able to answer: if this fails after the first production cohort, how do we get back? “We will fix forward” is not a rollback plan.

Design for a controlled pilot: one workload slice, a measurable service level, synchronised data where needed, an explicit fallback path and an exit criterion. The pilot should test the expensive uncertainty, not merely prove that a container starts on the new platform.

What to do on Monday morning

Download the Cloud exit readiness scorecard. Choose one workload that appears expensive and complete the seven gates with a named owner for each dependency. The first useful outcome may be “do not move this workload yet”. That is a result, not a failure.

Use the Cloud Repatriation scorer to pressure-test workload fit, then return to the Cloud Repatriation insight for the broader portfolio model.

The aim is not to bring workloads home. It is to stop paying for a placement decision nobody has re-examined since the first Cloud contract was signed.