Cloud repatriation and the honest maths behind it

The typical cloud business case is built at platform level: total on-premises cost today against projected cloud cost tomorrow. That framing averages away the workloads where the economics are terrible, because the ones where they are excellent carry them.

Rebuild the same case per workload and the distribution is usually stark. A majority of workloads improve, a handful are neutral, and a small number get dramatically worse — often the largest and most business-critical ones, which is precisely why they were left until last.

Three workload shapes come back repeatedly in our assessments as poor candidates, and they are identifiable before migration rather than after.

Bringing a workload back is only sensible when the reason it went is understood. Moving something back to the same architecture that made it expensive in the first place just relocates the problem.

In practice, useful repatriation is usually a replatform: the workload returns to a modern private cloud — VMware, Nutanix or Proxmox — with the automation, monitoring and self-service that the public cloud experience taught the team to expect. The operating model stays; the substrate changes.

A defensible model needs three years, not one, and it needs to include the things people leave out: migration effort, dual-running during transition, licensing changes, egress, and the cost of the skills required to operate the result.

It also needs a sensitivity analysis. A case that only works if consumption grows exactly as forecast is not a case; it is a hope with a spreadsheet attached.