A repatriation business case sets this year's cloud invoice against a five-year amortised cost for owned hardware and shows a 40% saving. The arithmetic checks out and the staffing line is there. Review the model: what would you change, what would you leave alone, and which single line decides the argument?

What is actually required

The model has to answer one question: over the same horizon, under the same demand, which option costs less and how confident are we? The usual review finds a missing line item. This model has the line items. Its flaw is that the two sides are modelled with different dynamics: one side is a point, the other is a curve.

What I would change

1. Model both sides over time, not as two numbers. Owned hardware is priced once and its cost per unit of work is then frozen for the term. Cloud unit price-performance moves, because new instance generations arrive and the workload can be moved onto them. Put an explicit assumption in the model, for example 0% to 10% per year of price-performance improvement taken by re-platforming, and run the case at both ends of that band. If the conclusion survives 0%, it is a real conclusion.

2. Add the refresh and the residual. A five-year model with no hardware refresh assumes year-five machines perform like year-one machines and fail no more often. Put the refresh in at its real date and put a residual value on what is sold or scrapped.

3. Compare capacity shapes, not averages. Owned capacity is bought for peak plus failure headroom and is paid for at 3 a.m. on a Sunday. If the workload's peak-to-average ratio is 3 to 1, the owned side must carry roughly three times the average capacity and the cloud side does not. A comparison of owned-at-peak against cloud-at-average is not a comparison.

4. Price the exit. Moving back, or moving between colocation providers, is a project. It belongs in the model as a probability-weighted line, not as an assumption of permanence.

What I would leave alone

The bare rate comparison, kept as a sanity check, because it is the number executives will quote and it is useful to know how far it is from the real answer. And the staffing estimate, if it was built from a named team plan rather than a percentage. Teams tend to attack the staffing line because it is the one they can argue about, and it is often the best-evidenced number in the document.

The line that decides it

The growth uncertainty over the term. Owned capacity must be sized to the top of the demand range, because you cannot buy it back in a week. If the five-year volume forecast spans a factor of two, the owned side carries the top of that range for five years and the 40% saving does not survive. If volume is flat and well understood, which is true of steady transcode, archival storage and some inference fleets, repatriation is a defensible call and the argument moves to whether the operations team can be hired and retained.

When this is the wrong answer

When the workload is large, steady and dominated by one resource, the five-year model is close enough and the review is wasting the team's time. A petabyte-scale storage tier with flat growth has a genuinely predictable curve. In that case, stop reviewing the spreadsheet and review the operational plan, which is where these projects actually fail.

Common weak answers

• "Add a 30% contingency." A contingency hides the disagreement instead of resolving it, and it is applied to the side the reviewer distrusts rather than to the uncertain assumption.
• "Cloud is cheaper below a certain scale." Scale is not the variable. Variability and uncertainty are.
• "Include opportunity cost." Only if you say what of, with a number. Otherwise it is a way of winning an argument without evidence.