Cloud Worked Example — The Repatriation That Was Only Half Right
A worked example of a workload moved back out of public cloud — how the decision was made per workload rather than by policy, what the numbers were, and the part of the plan that turned out to be wrong.
This is an illustrative example. The company, workloads and figures are invented. The useful part is the method, and the mistake made halfway through.
The situation#
A media analytics company processing video for advertisers. Cloud bill $340,000 a year and rising 22% annually against 7% revenue growth. The board asked a reasonable question that contained a bad assumption: "should we move off the cloud?"
The assumption is that placement is one decision. It is not, and answering it as one is how organisations end up wrong in both directions at once.
The method#
Rather than answer for the estate, the team profiled the eleven workloads that made up 90% of the bill. Five properties each, four of them measured.
| Workload | Load pattern | Utilisation | Egress/month | Lifetime |
|---|---|---|---|---|
| Video transcoding | Steady, 24/7 | 81% | 2 TB | Years |
| Model training | Bursty, weekly | 6% | 40 GB | Years |
| Model inference | Steady, business hours | 74% | 180 GB | Years |
| Asset storage and delivery | Steady | n/a | 58 TB | Years |
| Customer dashboard | Variable, spiky | 19% | 400 GB | Years |
| Reporting pipeline | Nightly batch | 11% | 20 GB | Years |
| Six smaller services | Mixed | 8–30% | small | Uncertain |
Reading down the utilisation column made the answer obvious in a way the aggregate bill never could. Two workloads were steady and heavily used. The rest were bursty, spiky, lightly used, or not certain to exist next year — which is exactly the profile public cloud pricing is built for.
The decision#
Moved to owned infrastructure: transcoding and asset delivery.
| Cloud, annual | Owned, annual | Note | |
|---|---|---|---|
| Transcoding | $108,000 | $31,000 | Hardware amortised over 4 years |
| Asset delivery | $91,000 | $38,000 | Egress dominated the cloud figure |
| Total | $199,000 | $69,000 | Plus $145,000 up front |
Payback under 14 months on workloads with a lifetime measured in years and no seasonality. Asset delivery was the clearest case in the estate: 58 TB of egress a month is a per-GB charge on a fixed, predictable volume, and there was nothing elastic about it.
Stayed in cloud: everything else. Model training runs bursty at 6% utilisation — owning hardware for it would mean buying for a peak that occurs a few hours a week. The dashboard is spiky. The six smaller services might not survive the year, and buying hardware for something that might be retired is the most expensive form of confidence.
The part that was wrong#
The original plan included model inference, on the argument that it was steady and heavily used — the same reasoning that was correct for transcoding.
It was pulled out four weeks in, and the reason is worth recording.
Inference was steady, but it was not stable. The model was being retrained and replaced roughly every six weeks, and each version had different memory and accelerator requirements. Two versions back it had run comfortably on the previous generation of hardware; the current one did not. Buying for the current requirement meant buying for a moving target with a six-week cycle.
The profile had captured load pattern correctly and missed change rate. Steady load and stable requirements are not the same property, and only one of them is on the standard checklist. Inference stayed in cloud, where changing the shape of the machine is a configuration change rather than a procurement.
This was caught because someone asked what happens at the next model version. It was not caught by the framework.
What was kept portable#
A condition of the move, and the reason it stayed reversible: containerised workloads, infrastructure described in code, standard database engines, and data exportable with the export actually tested rather than assumed.
The exit question was answered explicitly for both moved workloads: if this hardware fails or the decision proves wrong, how long to get back to cloud? Answer: under a week, because nothing about the workload had been rewritten to depend on the new environment. That answer is what made the decision reversible enough to make.
The result after a year#
| Before | After | |
|---|---|---|
| Annual infrastructure cost | $340,000 | $196,000 |
| Cost growth rate | 22% | 4% |
| Incidents attributable to the change | 2, both in the first month | |
| Staff added to operate the hardware | 0.4 of a person, contracted |
The 4% growth rate matters more than the headline saving. The steady, predictable, growing part of the bill was the part that had been growing fastest, because it grew with volume at a per-unit rental rate.
What was learned#
Decide per workload. The board's question had one answer for two workloads and the opposite answer for nine. A single policy would have been wrong either way.
Utilisation is the column to read first. Two workloads above 70% and steady; everything else under 30% or spiky. That table made the decision; the bill never could.
Steady load is not the same as stable requirements. This is the lesson that cost four weeks. A workload can be perfectly predictable in volume and completely unpredictable in what it needs to run on, and the second property is the one that makes owning hardware painful.
Answer the exit question before moving, not after. "Under a week to reverse" is what made this a decision rather than a bet.