The Ambition
The leadership team of a major emerging market bank had a clear conviction: public cloud was the future of their infrastructure, and the organisation needed to move decisively in that direction. The aspiration was not incremental. Within a defined timeframe, everything would migrate. The financial savings from early waves of migration would fund subsequent ones. The model was coherent, the direction was clear, and the board was aligned.
What the board had not yet seen was what the actual data said about whether the model held up.
I was brought in to advise the CIO on the strategic foundations of the migration programme — specifically to stress-test the assumptions underlying the cloud business case against the bank’s actual environment before the programme was committed to the board.
The gap between what we found and what the initial narrative assumed is the reason this brief exists.
The 85% That Wasn’t
The bank’s technology team, like most teams evaluating cloud migration, had run the available vendor tools. A major hyperscaler’s TCO calculator — a publicly available tool designed to help organisations estimate their cloud migration savings — produced a headline figure showing substantial savings potential. The number was attention-getting, the direction was unambiguous, and it provided a credible-seeming foundation for the migration programme.
The independent analysis, built against the bank’s actual server inventory, actual utilisation metrics, and actual cost data, produced a different picture.
For a straight lift-and-shift of the x86 estate to public cloud — taking the existing servers and moving equivalent workloads to cloud instances at equivalent sizing — the compute cost comparison was essentially flat. On a like-for-like basis, before adding the costs that the vendor tool had either excluded or estimated conservatively — cloud storage, connectivity, migration services, and labour — the migration generated no material compute saving.
The gap between the vendor tool’s output and the independent analysis was not a rounding error. It was structural. And understanding why that gap exists is more valuable than the numbers on either side of it.
What Low Utilisation Actually Means
The bank’s x86 servers were running at very low average utilisation. This is common across large enterprise estates — servers provisioned for peak demand spend most of their time significantly underloaded. It is also, intuitively, the argument that makes cloud most compelling: if you are only using a fraction of what you are paying for on-premise, moving to elastic cloud infrastructure should eliminate that waste.
The assumption that breaks down under scrutiny is this: low utilisation does not automatically make cloud cheaper. It makes cloud potentially cheaper — under specific conditions.
A straight lift-and-shift preserves the waste in a different form. If you move an on-premise server running at low average utilisation to an equivalently sized cloud instance running at the same utilisation, you have changed the location of the server without changing the economics. The cloud instance costs roughly the same as the on-premise equivalent, and you have added migration cost to get there.
The path to genuine cloud savings runs through optimisation — right-sizing instances based on actual peak utilisation rather than provisioned capacity. That analysis, when applied to the bank’s estate, did produce meaningful compute cost reductions. But right-sizing is not lift-and-shift. It requires a different migration approach, a different sequencing logic, and a different programme design. The business case for optimised cloud migration is real. The business case for wholesale lift-and-shift was not, at least not on compute economics alone.
This distinction — between lift-and-shift and optimised migration — is one of the most consequential things a CIO can clarify before a cloud programme is approved. The two have different costs, different timelines, different risk profiles, and different savings outcomes. Conflating them in the business case is how programmes are approved on assumptions they cannot deliver against.
The ELA Trap
The compute comparison was only part of the picture. The bank held Enterprise Licence Agreements with multiple software vendors — fixed-term contracts that provided software entitlements at agreed rates regardless of how or where that software was deployed.
This is a structural constraint that vendor cloud calculators consistently underweight, and that organisations frequently discover too late. An ELA fixes your software cost for the term of the agreement. If you migrate workloads to cloud during that term and reduce your on-premise software deployment, the licence cost does not reduce accordingly — you continue paying the contracted rate until renewal. The cloud migration saves the hardware cost. It does not save the software cost, because the software cost is already committed.
For the bank, a significant proportion of its infrastructure spend was allocated to software under existing ELA and ULA arrangements. In an emerging market context, this carried an additional dimension: enterprise software agreements are typically denominated in US dollars or euros, while the organisation’s revenue and budget are in local currency. Exchange rate movements can change the effective cost of an ELA mid-term regardless of any migration decisions. A business case built on software savings that are already committed in a foreign currency — and subject to FX risk for the duration of the agreement — needed to account for that reality explicitly.
The practical implication for any organisation in a similar position: the sequencing of a cloud migration should be informed by the ELA renewal calendar as much as by the technical migration complexity. Workloads whose software is approaching ELA renewal are better candidates for early migration than technically simpler workloads locked into multi-year agreements.
What the “Quick Wins Fund the Journey” Model Requires
The migration programme had been structured around a compelling internal logic: early migration waves would generate savings, and those savings would fund subsequent waves, creating a self-financing transformation. It is an attractive model. It is also one that requires specific conditions to hold.
The first condition is that the early waves must genuinely save money on a fully-loaded basis — compute, software, storage, connectivity, migration services, and labour all included. Partial comparisons that show compute savings while excluding other cost categories create the appearance of a self-funding model without the substance.
The second condition is that the savings must be realised at a timing that allows them to fund the next wave before the next wave’s costs are incurred. If ELA constraints defer software savings by two or three years, the financial model does not work as presented even if the eventual savings are real.
The third condition is that the “quick wins” must actually be quick — technically straightforward workloads that migrate cleanly without extended parallel running costs. Workloads that require significant re-platforming, integration changes, or extended testing periods do not generate quick wins. They generate extended cost periods before any savings materialise.
None of these conditions were impossible to satisfy. But they required the business case to be built honestly against what the data supported rather than against the most optimistic interpretation of vendor projections.
What a Credible Cloud Business Case Requires
The work produced a revised business case that identified a realistic migration path: specific workload categories where cloud economics were genuinely favourable, sequenced against ELA renewal timing, with a right-sizing methodology that captured utilisation-based savings rather than assumed lift-and-shift equivalence.
That business case was less dramatic than the initial ambition. It did not promise wholesale migration within a defined timeframe or a self-funding programme from the first wave. What it promised was a set of migrations with defensible economics — savings that would materialise as modelled rather than requiring favourable assumptions to validate.
Three questions I bring to every cloud business case conversation with a CIO.
What does the comparison include? A compute-only comparison that excludes storage, connectivity, labour, and migration services is not a business case — it is a partial picture. Ask to see the fully-loaded cost on both sides before any conclusion is drawn.
What does the ELA calendar look like? The timing of software licence agreements is as important as the migration sequence in determining when savings materialise. A business case that treats software cost as immediately variable when it is actually fixed for years is modelling a fictional scenario.
Is the business case built on lift-and-shift or on optimisation? The two are different programmes with different economics. If the business case assumes optimisation savings but the programme plan describes lift-and-shift execution, the gap between the plan and the outcome is already built in.
Cloud migration is not a category of investment where ambition and rigour are in conflict. The organisations that move to cloud successfully do so because they built the business case on what the data supported — not on what the direction required it to say.
