Building a migration business case that holds.

The point is not to make migration look good. It is to make the number defensible, so the program is funded on a basis that still looks right twelve months later.

What is the right baseline to compare against?

The most common error is a weak baseline. The current estate is not just the server lease; it is the fully loaded cost of running it, including the next hardware refresh you would otherwise pay, datacenter space and power, network and facilities, software licensing, and the staff time spent keeping it alive. Counting only the obvious line understates the status quo and makes any alternative look worse than it is. Build the on premises baseline as a true total cost of ownership over the same multi year horizon you will measure the cloud against, so you are comparing like with like.

Equally, do not flatter the baseline. Capacity you bought and barely use, redundancy you no longer need, and software you could retire are not savings the cloud creates; they are waste you could remove anywhere. A clean baseline counts what the current estate truly costs to deliver the same service, no more and no less.

Why the optimised run rate, not the day one bill?

A straight lift and shift almost always lands higher than the on premises cost it replaces, because you are renting the same oversized footprint by the hour. That is not the steady state; it is the starting point. The real cloud run rate emerges after the optimisation work: rightsizing instances to actual demand, moving to efficient instance families, adding commitment coverage such as AWS Savings Plans and Reserved Instances, Azure Reservations and the Azure Savings Plan, GCP Committed Use Discounts, or OCI Universal Credits against a defensible baseline, and rearchitecting the workloads that are expensive to run as lifted. The business case must show this path explicitly, the day one bill, the optimised steady state, and the work that connects them, because assuming the steady state without funding the work is exactly the gap that makes cases fail.

What transition costs must the case include?

Transition is a one off investment the case must fund, not an afterthought. It includes the migration labour whether internal or external, discovery and assessment tooling, application remediation and testing, training for teams on the new platform, and the parallel running period where both estates are live and billed at once. Provider migration funding, such as assessment programs and migration credits, can offset a meaningful share of this, but it comes with conditions and is a one off benefit, not ongoing savings; model it as a discount on transition and verify the terms. A case that hides transition cost shows a payback that never arrives.

How should the benefits timeline be shaped?

Benefits follow a curve, not a step. Expect the combined cost to rise during parallel running, peak around cutover, then decline as workloads are decommissioned on premises and optimised in the cloud. Map the curve quarter by quarter, tie each decline to a specific action such as a commitment purchase or a rightsizing wave, and track realised against modelled savings monthly so the case stays honest after approval. A migration business case is not a one time document; it is a forecast you are accountable to, and the credibility of the next one depends on this one proving true.

Build a case the board can approve and you can defend

We help engineering and finance leaders build migration business cases on a true total cost baseline, an optimised run rate rather than a day one bill, and a funded transition, then deliver the optimisation the case promised, as an independent advisory with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or no risk Gainshare basis. Read the cross cloud cost optimization guide, see the migration decision framework, and subscribe to The Cloud Spend Navigator.