“Cloud is cheaper” is not a business case. Neither is “we already own the servers.”
Cloud services can reduce cost, increase it or change its shape. The result depends on the workload, current estate, service level, skills, contractual model and time horizon. A comparison of a monthly cloud estimate with last year's hardware maintenance omits too much to support a decision.
The financial model should sit alongside security, resilience, capability and strategic considerations. It should not be used to disguise them.
Begin with the workload
An organisation does not move “infrastructure” as one uniform object. It moves applications, data and services with different patterns and constraints.
For each workload, establish:
- demand over time and its predictable peaks;
- performance and availability requirements;
- data volume, movement and retention;
- technical dependencies and latency sensitivity;
- security, privacy and regulatory obligations;
- recovery objectives;
- expected remaining life;
- change frequency and product roadmap;
- current support capability.
A public campaign site with short traffic peaks, a stable internal records system and a data-intensive analytics service can produce very different cloud economics. Portfolio slogans conceal that difference.
Where cloud economics can be favourable
Variable demand
Elastic infrastructure can reduce the need to buy permanent capacity for occasional peaks. The saving depends on whether the workload can actually scale down, whether the software supports that model and how accurately usage is controlled.
A system left running at peak capacity in the cloud has gained little elasticity. Design and operational practice matter as much as the commercial promise.
A major refresh is due
A cloud option may compare well when hardware, data-centre or core software commitments are approaching renewal. The business case can avoid new capital expenditure and some lifecycle work.
Do not treat the current estate as free. Include imminent refresh, facilities, licences, support, backup, recovery and staff effort. Equally, do not write off supported assets with useful life remaining simply because a migration programme is available.
Managed services replace work the firm should not own
Cloud database, identity, monitoring or platform services can remove categories of patching and administration. This may improve resilience and release specialist time.
Released time is not automatically a cash saving. If employees remain, describe the work they can stop and the higher-value work they can perform. If the organisation still needs substantial engineering to configure and operate the managed service, include it.
Resilience would otherwise require new investment
Geographic redundancy, automated backup and recovery tooling may be more economical through a suitable cloud design than building a second physical environment.
Those capabilities are not automatic simply because an application runs in a public cloud. Architecture, data replication, account separation, testing and operational readiness determine whether recovery works. Cost the required design rather than the provider's most basic service.
Where cloud may cost more
The workload is stable and well served
Consistent demand on appropriately sized, supported infrastructure can favour an existing or managed fixed-cost environment. Paying a premium for on-demand flexibility is poor value if the organisation does not need or use it.
This is a case for modelling, rather than a universal rule. Power, support, refresh, resilience and internal labour must still appear on the non-cloud side.
Data moves frequently or at high volume
Charges for outbound transfer, cross-region traffic, managed gateways and movement between services can be material. The application architecture determines much of this cost.
Map data flows before estimating. Include client delivery, backups, analytics, security tooling, third-party integrations and exit. Pricing changes, discounts and tiering should be taken from the proposed contract at decision time.
The application is poorly suited to consumption pricing
A legacy application may run continuously, require large fixed instances and lack the observability needed to control use. Moving it without redesign can recreate the old estate on a more variable bill.
Re-architecting may improve the position and brings its own cost and risk. Compare rehosting, modest remediation, deeper modernisation, managed hosting and retaining the service. “Cloud migration” is too broad an option for a serious investment paper.
Useful assets and contracts remain
Early termination charges, software licences, depreciation treatment and supported hardware life can make immediate migration unattractive. A staged move aligned with renewal dates may be better.
Avoid sunk-cost reasoning: money already spent should not justify carrying a service whose risk or ongoing cost is unacceptable. The relevant value is the cost and benefit that can still change.
The operating model is absent
Cloud environments need financial ownership, security configuration, identity controls, monitoring, incident response, backup, recovery and skills. Without those capabilities, bills and risk can grow together.
A small firm may get better value from a managed provider that wraps those responsibilities around suitable infrastructure. The hyperscale platform is a component, not an operating model.
Costs that commonly disappear from the first estimate
Migration and parallel operation
Inventory, remediation, testing, data transfer, cutover, rollback planning and assurance are project costs. During transition, both environments may run. The length of parallel operation should come from the plan and risk assessment, rather than a standard assumption.
Include internal subject-matter time and the effect on other delivery. Keep contingencies visible and explain what uncertainty they cover.
Network and data transfer
Estimate traffic by direction, region and service boundary. Include content delivery, logging exports, security inspection, backup and any repeated movement caused by hybrid architecture.
Storage growth
The unit price can look small while data, replicas, logs, snapshots and backups accumulate. Apply documented growth and retention assumptions. Identify who owns lifecycle policies and the consequences of deleting information too early or retaining it too long.
Support and operations
Price the support tier and response arrangements the service actually requires. Include monitoring, on-call cover, incident management, platform engineering and supplier-management effort. Base estimates that assume an expert team is always available are unsuitable for a firm without one.
Security, privacy and compliance
Cloud providers secure their infrastructure according to a shared-responsibility model; the customer still has substantial configuration and governance duties. Include identity architecture, logging, key management, vulnerability work, assurance, data-residency review and evidence for regulators or clients.
Cloud can improve security compared with an under-maintained local environment. It can also create broad exposure through a configuration error. Treat security as an evaluated design outcome.
Commitment and exit
Reserved capacity and committed spend can reduce unit prices while limiting flexibility. Include minimums, indexation, currency exposure and unused commitments.
Exit costs cover data extraction, contract overlap, application change, testing and loss of provider-specific services. Portability has a price during design and another during exit; decide how much is worth buying.
Build a multi-year comparison
Three years is a useful starting horizon for many digital-platform decisions, though contract length, refresh cycles and transformation plans may justify a different period.
Use consistent categories on both sides:
Transition: discovery, design, migration, remediation, testing, assurance, training, parallel running, termination and internal time.
Recurring service: compute, platforms, storage, transfer, network, licences, support, monitoring, security, backup, facilities and people.
Change: expected enhancement and deployment effort, environments, automation and the cost imposed by legacy constraints.
Risk treatment: resilience, recovery, compensating controls and material residual exposures. Avoid converting every risk into a false-precision cash figure; scenarios can be more credible.
End position: remaining asset value, contract commitments, decommissioning and exit or next-migration cost.
Keep cash cost, accounting treatment and capacity benefit distinct. A CFO needs the cash profile; the board also needs to know which capabilities and risks differ.
Use scenarios and unit economics
Create at least a central case and plausible high- and low-demand cases. Vary the assumptions that drive the result: usage growth, data transfer, migration duration, commitment discount, staff requirement and timing.
Identify the break points. At what sustained demand does the cloud option cease to be cheaper? How much delay can the migration tolerate? What level of data movement changes the ranking? This gives leaders something to monitor after approval.
Where possible, use unit economics alongside totals: cost per active client, transaction, environment or workload unit. Check that the unit reflects useful value and cannot be improved merely by shifting activity outside the measure.
Keep non-financial value visible
Faster environment provisioning, access to managed capabilities, improved recovery and a better route to modernisation may justify an option that costs more. They should be described with evidence and ownership.
Some benefits can be measured operationally: time to provision an environment, recovery performance in a test, lead time for change or hours spent patching. Others remain strategic options. State the claim and how the firm will know whether it occurred.
The discipline is to avoid forcing every benefit into a financial saving until the preferred option appears cheapest.
Decide per service, then manage the outcome
A sensible strategy may be mixed. Some services move to public cloud, some use SaaS or managed hosting, and some remain on supported local infrastructure until retirement. Consistency has operational value, but uniformity is not the goal.
After migration, compare actual cost and service with the model. Assign financial and technical owners, tag resources, budget alerts, review commitments and remove unused services. FinOps practice is the continuing management that turns consumption data into decisions; it is not a one-off cost-cutting exercise.
If you want the three-year cost comparison model as a pre-built spreadsheet - covering all five cost categories for both cloud and on-premise, with a three-scenario output - download it here. It's designed so that a CTO and CFO can sit down together and work through it in half a day with the infrastructure cost data you already have.
For the wider decision, read cloud strategy for mid-market service firms, the security risks in legacy platforms and total cost of ownership for digital platforms.
If you're currently evaluating a cloud migration, or if you've already migrated and the costs aren't where you expected, download the cost comparison template and run the numbers properly. Or get in touch for a cloud readiness assessment. Sometimes half a day with the right framework saves you three years of overspending.
