Build a business case for cloud computing by comparing credible alternatives over the same period, including migration costs, ongoing operating costs, measurable benefits and delivery risk. The decision should explain why a particular workload should move, change or remain where it is.
I would start with the business problem rather than an assumed savings percentage. Cloud adoption can improve speed, capacity or resilience without lowering every cost. A defensible proposal shows which outcomes matter, how they will be measured and what evidence would justify the investment.
Define the decision and the workload boundary
State what approval you need: an assessment, a limited pilot, a migration or a broader modernization programme. These are different commitments. A proposal seeking funds for an experiment should not imply that the full production move has already been justified.
Identify the workload, users, business owner and dependencies included in the comparison. If a database moves but an integrated reporting system remains elsewhere, connectivity and operating responsibilities still matter. Excluding those costs because they sit in another department makes the proposal look better without improving the decision.
Describe the problem in observable terms. Examples include slow environment provisioning, a hardware refresh deadline, constrained peak capacity or recovery capabilities that do not meet business requirements. “We need to be cloud-first” is a strategic preference, not a complete workload-level justification.
My recommendation is to write one sentence connecting the investment to an outcome and a deadline. For example, the organization may need a tested recovery capability before a contract renewal. That establishes a decision to analyze without assuming which technology will win.
Build a fair current-state baseline
Inventory the infrastructure, software, facilities, support and labor supporting the workload. Separate costs that will genuinely disappear after a move from shared costs that remain. Moving one application rarely eliminates an entire data-center lease or all infrastructure staffing.
Distinguish cash spending from allocated accounting cost. An application may carry an internal charge for shared hardware, but moving it will not necessarily release that amount of cash. Finance should validate which benefits are avoidable expenditure, released capacity or simply a different allocation.
Include an appropriate future baseline. If hardware must be refreshed during the evaluation period, the retain option should include that realistic investment. If existing equipment remains suitable, do not invent an immediate replacement merely to make migration attractive.
Document the source, owner and confidence level for each material input. A measured storage footprint and a guess about future growth should not appear equally certain. A small number of transparent assumptions is more useful than a detailed model whose inputs nobody can defend.
| Option | Transition | Annual run | 3-year total |
|---|---|---|---|
| Retain | $0 | $120k | $360k |
| Cloud base | $60k | $85k | $315k |
| Cloud higher | $60k | $105k | $375k |
Compare alternatives that could actually solve the problem
Consider retaining and improving the existing system, rehosting it, using a managed platform, replacing it with software as a service or retiring unused functionality. The appropriate shortlist depends on the business problem and technical constraints.
Do not compare a fully resilient cloud design against a minimally protected current environment and attribute the entire difference to hosting location. Either compare equivalent service levels or explicitly show the extra cost and benefit of improved resilience.
Migration changes where a workload runs; modernization changes its capabilities or the way it can be operated and evolved. Microsoft’s modernization business case guidance treats value, cost and feasibility as decision inputs. I would keep those distinctions visible when comparing proposals.
A cheaper rehost may deliver less operational improvement than a managed-service redesign. A redesign may deliver more value but require more time and execution risk. The business case should explain the trade-off instead of combining the cheapest cost from one option with the strongest benefits of another. Match the relevant cloud computing advantages to measurable outcomes for this workload.
Estimate the full cloud run rate
Model compute, storage, databases, requests, data transfer, backups, logging, support and any relevant software licensing. Add the people and processes needed to operate the environment. A provider invoice is not the complete cost of running the workload.
Base usage on the workload’s expected pattern. Include quiet periods, normal operation and plausible peaks. Some resources can scale down substantially; others retain a paid baseline. Storage retention, replicated copies and high-volume logs can grow even when application traffic is stable.
Use current provider quotes or calculators for the actual region, configuration and commercial arrangement. Record the estimate date and any assumptions about currency, tax, discounts or commitments. Avoid treating a temporary credit as a permanent reduction in the workload’s economics.
I would keep an on-demand or flexible scenario alongside any commitment-based proposal. Discounts can be valuable when usage is predictable, but a commitment can create waste if the workload changes. Show the risk of unused capacity as well as the advertised unit saving.
Count transition and exit costs
Migration can involve discovery, design, engineering, data transfer, testing, training and external assistance. Include temporary dual running, project management and changes to connected systems. These are part of the investment even if they occur outside the cloud bill.
Plan decommissioning explicitly. Savings from the old environment do not begin merely because the new application is live. Contracts may continue, data may need to be retained and shared infrastructure may remain necessary for other workloads.
Include a reasonable exit or portability assessment. Ask how data could be exported, how long transfer might take and which application components would need redesign. You do not need a full migration project for every hypothetical future provider, but you should understand major dependencies.
The treatment of project contingency should be clear. Keep it visible rather than hiding extra amounts inside several unrelated lines. Then explain the risks it is intended to cover, such as uncertain data cleanup or integration work.
Use a worked example without disguising assumptions
Consider a purely hypothetical three-year comparison in US dollars. Suppose the retain option costs $120,000 per year, or $360,000 over three years. Suppose the proposed cloud option requires $60,000 of one-time transition spending plus $85,000 per year of ongoing cost, totaling $315,000.
Under these assumptions, the cloud option costs $45,000 less over the evaluation period. Its recurring annual cost difference is $35,000, so simple payback on the $60,000 transition cost is about 1.71 years. That calculation assumes the recurring difference begins immediately and does not account for phased migration or the time value of money.
The example is arithmetic, not a cloud-price quote or a prediction. The $60,000 transition assumption must include the relevant migration and dual-running costs. The annual figures must cover comparable service levels and operational responsibilities for the comparison to be meaningful.
For a larger decision, finance may require discounted cash flow, a suitable discount rate and a treatment of residual value. Use the organization’s approved method. Do not label a simple cost difference as a complete ROI calculation or count an accounting allocation as a cash saving without checking.
The old environment stops costing money on launch day.
Include contract overlap, dual running and an owned decommissioning plan.
Value benefits and test the downside
Separate hard financial benefits from operational improvements and strategic options. Reduced supplier payments may be a cash benefit. Faster environment creation may release engineering time. New capabilities may create an opportunity, but they do not automatically establish incremental revenue.
Avoid double counting. If saved staff time is used to deliver another project, do not also claim the same time as payroll savings unless staffing expenditure actually falls. If revenue depends on sales execution, customer demand and product changes, do not credit the infrastructure move with the whole amount.
Test scenarios for usage growth, data transfer, delayed decommissioning, higher support needs and a longer migration. In the hypothetical example, increasing annual cloud operating cost to $105,000 raises the three-year total to $375,000, making it $15,000 more expensive than retaining the system before other benefits are considered.
I would show which assumptions change the recommendation. A proposal that remains attractive only under one optimistic forecast needs a different approval discussion from one that performs acceptably across a realistic range. Uncertainty belongs in the decision, not in a footnote nobody reads.
Make non-financial requirements visible in approval
Some constraints should be treated as pass-or-fail requirements rather than converted into speculative savings. If a workload must meet an agreed data-location rule or integrate with a required system, an option that cannot satisfy that requirement may be unsuitable regardless of its apparent price.
Similarly, estimate the operational effort the organization can actually supply. A design may look inexpensive while requiring specialist coverage the team does not have. Include training or external support in the proposal, and explain whether that capability must remain available after launch.
Where benefits are difficult to price, describe a measurable operational result instead. A reduction in environment lead time can be measured directly before anyone claims an associated revenue effect. That makes the improvement assessable without inventing a financial conversion.
I would present these requirements beside the cost model, with a named reviewer for each. Decision makers can then see whether a lower-cost option also meets the service, governance and delivery conditions. A business case should support a viable decision, not merely produce the most favorable spreadsheet total.
Ask for staged approval and measure the result
Use a pilot to validate the highest-impact uncertainties: performance under representative load, integration effort, access controls, recoverability and actual unit cost. Set a spending cap and define the evidence needed to continue, revise or stop.
Assign benefit owners. The engineering team can measure provisioning time, finance can validate avoided expenditure and the business owner can assess service outcomes. A list of benefits without accountable owners is difficult to verify after migration.
After launch, compare actual cost and service performance with the case. Explain differences in demand, architecture, pricing and project scope. A higher total bill may reflect valuable growth, while an unchanged bill can conceal worse cost per useful transaction.
The final approval paper should state the chosen option, alternatives, assumptions, expected outcomes, risks and decision gates. My preference is a modest proposal that can be tested over a confident claim of guaranteed savings. Cloud adoption succeeds when the organization receives justified value and can demonstrate it afterward.
Common questions
Does moving to the cloud guarantee savings?
No. Compare equivalent workloads and include transition, operating and exit costs. Some proposals are justified by capability or risk reduction rather than a lower bill.
Should every benefit be converted to revenue?
No. Measure operational benefits directly when a reliable financial conversion is unavailable. Keep speculative revenue separate from validated cost changes.