Cloud migration business case documents fail for a reason that has nothing to do with the cloud. They fail because they are written by people who understand infrastructure for people who understand money, and the translation never happens. The technology section is immaculate. The financial section is a single number with no working behind it.
Finance directors are not hostile to cloud adoption. They are hostile to unfalsifiable claims. “It will be more scalable” is not a benefit they can put in a forecast. “It will save 30%” is not a benefit either, unless you can say 30% of what, measured how, arriving in which quarter, and what happens to the number if you are wrong.
This guide is the translation layer. It covers what belongs in a cloud migration business case, how to build a baseline that survives challenge, where the benefits genuinely come from, how to model three years of cash properly, how to stress-test the result, and how to compress the whole thing onto one page a board will actually approve. It assumes you already know roughly what the move costs — if you do not, start with our breakdown of cloud migration cost in the UK and come back.
Table of contents
- Why a cloud migration business case gets rejected
- What an approver reads first in a cloud migration business case
- The anatomy of a strong cloud migration business case
- Building the cloud migration business case baseline
- Costing the cloud side without wishful thinking
- Where cloud migration business case benefits genuinely come from
- Modelling three years in the cloud migration business case
- Sensitivity analysis that hardens the cloud migration business case
- Writing the paper the board will actually read
- Governance after the cloud migration business case is approved
- Frequently asked questions
- References
Why a cloud migration business case gets rejected
Rejection is rarely a verdict on the technology. It is almost always a verdict on the evidence. The pattern repeats across organisations of every size, and once you have seen it a few times the failure modes are easy to spot before you submit.
The author is the wrong person
A cloud migration business case written entirely by the infrastructure team reads as a shopping list. One written entirely by finance reads as a cost-cutting exercise that ignores operational reality. The credible version has a named business sponsor who is neither, and who can answer “why now” without referring to a product roadmap.
The baseline is a guess
Almost every weak case has a strong cloud estimate and a vague on-premises comparison. If the current cost of running the estate is a rounded figure someone remembered, the whole comparison collapses under the first question. Your baseline needs to be as evidenced as your proposal.
Benefits are asserted rather than quantified
Agility, scalability and resilience are real. They are also unbankable in that form. Every benefit in a cloud migration business case needs a unit, a quantity, a start date and an owner who agrees to be measured on it. If nobody will sign up to deliver a saving, it is not a saving.
Only one option is presented
Presenting a single option tells the approver you have not done the analysis. A board wants to see that alternatives were considered and rejected on evidence: stay put and refresh the hardware, partially migrate, fully migrate, or replace the application entirely. Our guide to legacy system modernisation sets out how those options differ in practice.
Risk appears nowhere
A case with no downside section is not optimistic, it is incomplete. Approvers assume the risks exist whether or not you listed them, and a document that pretends otherwise loses credibility on every other number too.
What an approver reads first in a cloud migration business case
Understanding the reading order changes how you write. Nobody starts at page one and works through. They look for four things, in this sequence, and form a view within about ninety seconds.
The number and the ask
How much money, over what period, and what exactly is being approved today. Put it in the first paragraph. A cloud migration business case that hides the ask until page eleven reads as evasive even when it is not.
The payback and the shape
When does cumulative benefit exceed cumulative cost. A twenty-two month payback is fine; a twenty-two month payback presented as “savings from year one” is not, because the first year is almost always negative and your reader knows it.
The counterfactual
What happens if we approve nothing. This is the single most underused section. Hardware reaching end of support, a data centre lease expiring, or a security control you cannot implement on the current platform all make the do-nothing option expensive, and that expense belongs in the comparison.
The evidence trail
Where did these numbers come from. A quoted figure with a named source beats a modelled figure with none, every time, and a cloud migration business case that cites its sources inline rarely gets sent back for rework.
The anatomy of a strong cloud migration business case
UK public sector bodies use HM Treasury’s five-case model, and it is worth borrowing even if you are a private company, because it forces you to answer questions in an order that makes sense to anyone who has read a business case before.
The strategic case
Why this, why now, and how it connects to something the organisation has already committed to. If your cloud migration business case cannot be traced to an existing strategic objective, it will be read as a technology preference rather than a business decision.
The economic case
The options appraisal. Each option costed on the same basis, with the same horizon and the same assumptions, so the comparison is fair. This is where net present value, payback and the shortlist rationale live.
The commercial case
How you will buy it. Which provider, which contract vehicle, what the commitment terms are, what the exit provisions look like, and who carries which risk. Procurement will read this section closely even if nobody else does.
The financial case
Affordability, as distinct from value for money. A project can have an excellent return and still be unaffordable in the quarter the cash is needed. Split capital from operating expenditure and show the profile month by month for the first year.
The management case
Who runs it, what the milestones are, how benefits get tracked after go-live, and what the governance looks like. A cloud migration business case without a delivery plan attached invites the response that it is premature.
Building the cloud migration business case baseline
The baseline is where most of the analytical work sits, and it is the part teams consistently underestimate. You are not comparing a cloud invoice to a server invoice. You are comparing the total annual cost of the current arrangement to the total annual cost of the proposed one.
Hardware and the refresh cycle
Annualise it in the cloud migration business case rather than quoting the purchase price. If the current estate cost £96,000 and is replaced every five years, that is £19,200 a year of capital consumption whether or not it appears in this year’s budget. Include the switches, the firewalls, the uninterruptible power supplies and the backup appliance, not only the servers.
Licensing you already hold
Operating system licences, database licences, hypervisor licences, backup software and the management agents nobody remembers. Some of these travel to the cloud under existing agreements and some do not, and the difference materially changes the answer.
Power, cooling and space
UK business electricity averaged around 27p per kWh in 2026, roughly 50% above pre-2022 levels. A modest rack drawing 3kW continuously costs approximately £7,000 a year in electricity alone before cooling, and that figure belongs in the baseline of any honest cloud migration business case.
Support, maintenance and third-line cover
Vendor support renewals, the maintenance contract on the air conditioning, the out-of-hours callout arrangement. These are usually documented somewhere in accounts payable and are among the easiest baseline numbers to evidence properly.
The staff time nobody books
Patching, firmware updates, capacity planning, hardware failures and the periodic disaster recovery test. Estimate the days, cost them at a loaded rate, and state the assumption openly. Two days a month at £400 a day is £9,600 a year, and reviewers respect a stated assumption far more than a silent omission.
Downtime and the risk-adjusted line
If the estate has had unplanned outages, cost them. Revenue lost, staff hours idle, recovery effort. Even a conservative figure changes the comparison, and leaving it out quietly favours the status quo.
| Baseline line item | Typical annualised figure | Evidence source |
|---|---|---|
| Server and storage refresh | £19,200 | Purchase ledger, 5-year cycle |
| Network and security hardware | £5,400 | Asset register |
| Software and OS licensing | £14,000 | Licence statements |
| Power and cooling | £9,800 | Metered usage at 27p/kWh |
| Vendor support and maintenance | £11,500 | Renewal invoices |
| Internal staff time | £9,600 | Stated day-rate assumption |
| Facilities and floor space | £4,200 | Lease apportionment |
| Downtime, risk-adjusted | £6,300 | Incident log, conservative |
| Total annual baseline | £80,000 | Illustrative mid-market estate |
That total is the number your proposal has to beat. Notice how much of it never appears on an IT invoice, which is precisely why a cloud migration business case built from invoices alone tends to understate the true cost of standing still.
Costing the cloud side without wishful thinking
The cloud column has two halves that behave very differently: a one-off spike to get there, and a recurring run-rate once you arrive. Merging them is the most common modelling error, because it makes year one look impossible and year three look implausible.
The one-off costs of getting there
Every cloud migration business case needs these itemised rather than bundled: discovery and assessment, landing zone design and build, the migration work itself, application remediation, testing, cutover weekends and the project management wrapped around all of it. This is the spike, and it lands in the first two or three quarters.
The steady-state run-rate
Compute, storage, database, networking, backup, the security tooling and the support plan, which is typically charged as a percentage of consumption rather than a flat fee. Model this at the volumes you expect after optimisation, not at the lift-and-shift volumes you will briefly run.
Commitments and how much they actually save
Reserved capacity and savings plans advertise reductions of up to 72% against on-demand pricing on a three-year commitment. Real portfolios land considerably lower because not everything can be committed. Assuming 30% to 40% blended is defensible; assuming the headline is not.
Egress, exit and the switching question
The Competition and Markets Authority concluded in July 2025 that competition in UK cloud infrastructure is not working well, and found that egress fees deter switching between providers. Whatever changes follow, a cloud migration business case should price the cost of leaving before you sign, not after.
The overlap nobody budgets
For a period, both estates run. You pay the old maintenance and the new subscription simultaneously, and every week of slippage extends it. Three months of overlap on the figures above is roughly £20,000 that has to sit somewhere in the model.
| Cost line | Type | Illustrative amount | When it lands |
|---|---|---|---|
| Discovery and assessment | One-off | £9,000 | Months 1-2 |
| Landing zone build | One-off | £16,000 | Months 2-4 |
| Workload migration | One-off | £28,000 | Months 4-9 |
| Application remediation | One-off | £15,000 | Months 5-10 |
| Parallel running overlap | One-off | £20,000 | Months 6-9 |
| Training and new operating model | One-off | £7,000 | Months 3-12 |
| Cloud consumption, unoptimised | Recurring | £62,000/yr | From month 4 |
| Cloud consumption, optimised | Recurring | £48,000/yr | From month 15 |
| Managed support and tooling | Recurring | £13,000/yr | From month 4 |
Two things in that table decide the entire cloud migration business case: the £95,000 of one-off spend, and the £14,000 gap between unoptimised and optimised run-rate. The first sets how deep the trough goes. The second decides whether you ever climb out.
Where cloud migration business case benefits genuinely come from
Benefits need to be separated into cash, cost avoidance and value, because approvers treat them very differently. Cash is a line that leaves the budget. Cost avoidance is money you would otherwise have spent. Value is real but unbankable, and claiming it as cash is how a case loses credibility.
Avoided capital refresh
Usually the largest single item in a cloud migration business case, and the easiest to evidence, because there is a quote or a lifecycle date behind it. If the refresh was due in eighteen months, the avoidance is real and datable.
Reduced run-rate after optimisation
Only counts if someone owns it. Flexera found that 27% of cloud spend is wasted and budgets overrun by around 17%, so a business case that assumes automatic savings is arguing against the evidence. Attach the saving to a named cloud cost optimisation workstream with a date.
Recovered staff hours
Patching, capacity planning and hardware failures consume time that can be redeployed. Be honest about whether it is a headcount reduction or a redeployment, because finance will ask, and “we will do more with the same team” is a perfectly acceptable answer if you say it plainly.
Resilience and risk reduction
Faster recovery, better backup, geographic redundancy. Quantify by expected loss avoided rather than by assertion: outage frequency times duration times cost per hour, adjusted down for honesty.
Enabling work you cannot do today
Analytics, higher elasticity, faster environment provisioning. Real, and worth stating, but keep it in a clearly separate section from the cash. A cloud migration business case that mixes aspiration with arithmetic gets challenged on both.
The shape matters more than the exact percentages. If avoided refresh and run-rate reduction are not the two largest bars in your model, something in the benefit stack is probably being overclaimed.
Modelling three years in the cloud migration business case
A twelve-month view makes cloud look expensive, because it captures the whole one-off spike and none of the steady-state benefit. A five-year view invites the criticism that nobody can forecast that far. Three years is the horizon most UK finance teams find credible.
Discount the future explicitly
An undiscounted cloud migration business case overstates its own returns. HM Treasury’s Green Book uses a 3.5% real discount rate for appraisal over the first thirty years. Whether you adopt that or your own cost of capital, state the rate and apply it consistently to every option. An undiscounted comparison quietly flatters whichever option has benefits furthest out.
Payback, net present value and internal rate of return
Payback tells the board when the cash comes back. Net present value tells them whether the whole thing is worth more than it costs in today’s money. Internal rate of return lets them compare it against other uses of the same capital. Provide all three; different readers trust different measures.
The J-curve is normal, so name it
Every cloud migration business case has a trough. Cost lands before benefit, and the cumulative position gets worse before it gets better. Show it deliberately, because a reviewer who discovers the trough themselves will assume you were hiding it.
Keep capital and operating expenditure separate
The move usually converts capital spending into operating spending, which changes depreciation, EBITDA and sometimes covenant calculations. That is a conversation for your finance business partner before submission, not after.
| Cash flow line | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Baseline cost avoided | £48,000 | £80,000 | £80,000 |
| One-off migration spend | -£95,000 | £0 | £0 |
| Cloud run-rate | -£56,000 | -£72,000 | -£61,000 |
| Net cash flow | -£103,000 | £8,000 | £19,000 |
| Cumulative position | -£103,000 | -£95,000 | -£76,000 |
| Cumulative with refresh avoided | -£7,000 | £1,000 | £20,000 |
The final two rows are the argument. Judged on operating cash alone the project is under water for three years. Judged against the £96,000 hardware refresh it displaces, it breaks even in month twenty-two. Which row your cloud migration business case leads with is the single most consequential presentational choice you will make, and both rows must be visible.
Sensitivity analysis that hardens the cloud migration business case
A single-point answer invites a single question you cannot answer: what if you are wrong. Sensitivity analysis answers it in advance, and it is the fastest way to move a cloud migration business case from plausible to persuasive.
Vary the three assumptions that actually move the answer
In almost every model these are the same three: the one-off migration cost, the steady-state run-rate, and how long parallel running lasts. Flex each by a realistic margin and show what happens to payback. Gartner has found around 60% of organisations exceed their initial migration budget, with overruns commonly between 30% and 50%, so a plus-30% case is not pessimism, it is the base rate.
Build a downside that still passes
The strongest thing you can put in front of a board is a pessimistic scenario that still clears the hurdle. If it does not clear it, you have learned something important before committing, which is the entire point of doing the analysis.
State the break-even explicitly
Name the point at which the decision flips: “this stops making sense if run-rate exceeds £78,000 a year, or if parallel running runs past seven months”. A cloud migration business case that names its own failure conditions reads as honest, and it gives the steering group something concrete to monitor.
| Scenario | One-off spend | Annual run-rate | Payback |
|---|---|---|---|
| Optimistic | £80,000 | £55,000 | 16 months |
| Base case | £95,000 | £61,000 | 22 months |
| Overrun of 30% | £124,000 | £67,000 | 34 months |
| No optimisation achieved | £95,000 | £75,000 | Never |
The last row is the one worth dwelling on. If nobody owns optimisation, the project has no payback at all, which is why the benefit and the owner have to be named together in the paper rather than assumed.
Writing the paper the board will actually read
Analysis is not the deliverable. The document is. A rigorous model presented badly loses to a mediocre model presented well, which is unfair but reliably true.
One page, then annexes
The first page of the cloud migration business case carries the recommendation, the ask, the payback, the top three risks and the decision required. Everything else is an annex. If a director reads only page one, they should still be able to vote.
Lead with the chart that carries the argument
Usually the cumulative cash position with the do-nothing line overlaid. One picture showing the crossover point does more work than three pages of tables, and it survives being forwarded to somebody who was not in the meeting.
Use the language finance already uses
Payback, net present value, run-rate, capital versus operating, contingency, benefits realisation. Not workloads, instances, tenancy or landing zones. Those belong in the annex where the technical reviewer will find them.
Put the assumptions in one visible place
A short assumptions register with owners and dates is a credibility multiplier. It signals that you know which parts of the cloud migration business case are estimates, and it converts arguments about conclusions into arguments about inputs, which are far easier to resolve.
Answer the obvious objections inside the paper
Security, data residency, vendor lock-in, exit costs, staff impact. Address each in two or three sentences before the meeting rather than defending them from a standing start during it.
Governance after the cloud migration business case is approved
Approval is a milestone, not an outcome. The gap between an approved case and a realised benefit is where most of the value quietly disappears, and closing it costs relatively little if it is planned in from the start.
Track benefits against the original numbers
Whoever owns each benefit reports actuals against forecast quarterly. This is uncomfortable and it is the only thing that makes the next cloud migration business case in your organisation believable.
Re-forecast rather than defend
Assumptions change. A model updated openly builds trust; a model defended past the point of evidence destroys it. Re-forecast quarterly and show the variance with an explanation attached.
Gate the decommissioning
Parallel running ends when someone decides it ends. Put a dated gate in the plan with a named decision-maker, because the overlap is the most common place where a sound business case bleeds out. Sustained savings then depend on ongoing cost optimisation discipline rather than one-off effort.
Close the loop with a post-implementation review
Six to twelve months after cutover, compare what happened to what was promised. The organisations that do this get materially better at estimating, and their subsequent business cases get approved faster.
Frequently asked questions
How long should a cloud migration business case be?
A cloud migration business case should run to one page of recommendation plus five to fifteen pages of annex. The constraint is not length, it is that every claim on page one has evidence somewhere behind it. A forty-page narrative with no model is weaker than a two-page summary with a working spreadsheet attached.
What discount rate should we use?
If you have a corporate hurdle rate, use it. If you do not, HM Treasury’s Green Book rate of 3.5% is a defensible public benchmark for UK organisations. What matters more than the exact figure is applying the same rate to every option so the comparison stays fair.
Should we include soft benefits like agility?
Include them, but in a clearly separate section from the cash, with no monetary value attached unless you can evidence one. Approvers are comfortable with qualitative benefits presented as qualitative. They are not comfortable with a number that turns out to be a guess.
What if the numbers do not support migrating?
Then you have done the job. A cloud migration business case that concludes “refresh the hardware and revisit in three years” is a successful piece of analysis, not a failure. Documenting why is also how you avoid relitigating the same argument every budget round.
How do we handle the risk of cost overrun?
Model it explicitly as a scenario, add a stated contingency of 15% to 20% on the one-off spend, and name the triggers that would cause it. Hiding contingency inside line items makes every line item look padded and invites across-the-board cuts.
Who should own the cloud migration business case?
A business sponsor with budget authority, supported by IT for the technical inputs and finance for the model. Sole IT ownership is the most reliable predictor of rejection, because it frames a business decision as a technology purchase.
How often should the model be revisited before approval?
Once after the baseline is evidenced, once after supplier pricing is received, and once after finance has reviewed the model mechanics. More iterations than that usually means the scope is still moving, which is itself worth surfacing.
Does the case change if we only migrate part of the estate?
Substantially. A partial migration keeps most of the fixed on-premises costs — power, facilities, support contracts — while adding cloud spend on top, so the benefit is far smaller than a proportional share. Model hybrid explicitly rather than scaling the full-migration numbers down.
References
CMA Cloud Services Market Investigation
CMA Cloud Infrastructure Services Final Decision Report
HM Treasury: The Green Book and Accompanying Guidance
Green Book Supplementary Guidance: Discounting
Flexera State of the Cloud Report
Microsoft Azure Reservations Documentation
