ROI & Payback

The two dimensions of cloud ROI

Cloud transformation generates return in two fundamentally different ways, and a credible business case addresses both explicitly.

Direct ROI is the return that comes from cost reduction and cost avoidance: lower infrastructure operating costs, hardware refresh deferral, licence rationalisation, and reduced operations headcount on commodity infrastructure tasks. Direct ROI is calculable from the TCO analysis and can be modelled conservatively without heroic assumptions.

Indirect ROI is the return that comes from capability gain: faster time to market, higher system availability enabling better customer experience, improved compliance posture reducing audit costs and regulatory risk, and the ability to scale infrastructure with demand rather than against it. Indirect ROI is harder to quantify but often larger than direct ROI in absolute terms. The discipline is to quantify it conservatively rather than ignoring it.

What to calculate for direct ROI

The direct ROI calculation should cover three years and include the following components. Infrastructure cost delta: the difference between current total infrastructure operating cost (all sixteen TCO categories) and projected cloud operating cost, net of migration investment. Licence cost evolution: the change in licensing costs as on-premises licences are retired and replaced by cloud-native alternatives. Operations headcount reallocation: the cost of infrastructure operations staff that can be redeployed to business-value work as commodity infrastructure management is eliminated.

The migration investment — the one-time cost of the transformation — is treated as a negative component in year one and potentially year two, with the ongoing savings accumulating from the point where the migration investment is complete.

What to calculate for indirect ROI

For indirect ROI, the most useful approach is to identify three to five specific business outcomes that cloud enables and quantify each conservatively. Availability improvement: if current system availability is 99.2 % and cloud-native architecture targets 99.9 %, the delta represents a specific number of additional available hours per year. Multiplied by revenue at risk per hour (or cost of support tickets, or cost of manual workarounds), this becomes a financial figure. Time to market: if cloud-native CI/CD practices reduce the time to deploy a new feature from six weeks to one week, what is the value of the additional five weeks of capability? The answer depends on the organisation’s competitive dynamics. Compliance audit simplification: if BSI C5-attested infrastructure reduces audit preparation effort from forty person-days per year to fifteen, that is twenty-five person-days of auditor time redirected to higher-value work.

The payback timeline

The payback period for cloud transformation — the point at which cumulative returns exceed cumulative investment — depends on the migration complexity and the starting point. For a mid-sized organisation migrating workloads that are already virtualised and relatively current, eighteen to thirty months is a realistic expectation. For organisations with heavily customised or legacy workloads, the payback horizon extends to thirty-six to forty-eight months.

Present the payback timeline as a range with explicit assumptions, not as a single point. A CFO who understands that the base case assumes a 20 % operations cost reduction and the optimistic case assumes 30 % is in a better position to stress-test the model than one who receives a single number.

Making assumptions explicit

Every ROI model rests on assumptions. The discipline of a credible business case is to state those assumptions explicitly and to show what happens to the ROI if the key assumptions are wrong.

The most important assumptions to surface are: the migration timeline (delays increase migration investment and delay the start of ongoing savings), the staff reallocation rate (how quickly can freed-up operations capacity be redirected?), the licence renegotiation outcome (software vendors often resist migrating licences to cloud-native models), and the adoption rate of new cloud-native practices (FinOps optimisation, reserved capacity purchasing, right-sizing — these generate material savings but require time to implement).