A CFO has approved a cloud program twice. The first time, the business case promised lower infrastructure costs. The second time, it promised agility. Two years in, the bill is higher than the old data center budget, the engineering teams say they still wait for environments, and the board is asking what the money bought. She is not against cloud. She simply cannot see where the value went.

This is the situation many cloud sellers walk into, and it frames the question this article answers: where does cloud value actually come from, and why do some buyers capture it while others pay more for the same outcomes? The short answer is that cloud does not create value by itself. It creates the conditions for value, and the buyer earns the return by changing how it works. A seller who understands the mechanisms can help the buyer pick the ones worth pursuing and name who must do the work.

The first article in this knowledge base described cloud as an operating model defined by five characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Those characteristics do not translate into money on their own. They feed four distinct value engines, each with its own mechanism, metric and owner.

1. Cost engine: paying for what is used instead of what was forecast. On premises, capacity is bought for the expected peak and depreciates whether it is used or not. Resource pooling lets the provider spread hardware, facilities and operations across many tenants; elasticity and measured service let the customer pay for capacity only while it runs. The value is real but conditional: it appears only when someone turns capacity off, sizes it correctly and buys discounts for the steady part of the load. The mechanism also cuts the other way. A workload that runs flat out all year gains little from elasticity and can cost more in the cloud than on owned hardware.

2. Speed engine: shorter time from idea to running software. Self-service and automation remove the ticket queue between a developer and a test environment. The value shows up as faster releases, more experiments and less engineering time spent waiting. In McKinsey's modeling, accelerated product development is the largest single source of cloud value [1], and it is the engine most often left idle, because it depends on the customer changing its provisioning, approval and release processes rather than on the provider's technology.

3. Resilience engine: lower risk at a lower cost of insurance. Running across multiple availability zones or regions, using managed backup and replicating data used to require a second data center. In the cloud it becomes a configuration and a monthly charge. The value is the expected loss avoided: outages, data loss and the cost of recovery. It is real only if the architecture actually uses those features and is tested; the provider supplies the building blocks, not the design.

4. Growth engine: options the buyer could not afford before. Rented capacity lowers the cost of trying something new: entering a market, launching a digital product, analyzing data at a scale that would never justify a hardware purchase, or using AI services without building the infrastructure underneath. The value is new revenue or new capability. It is the hardest engine to forecast and the easiest to overclaim.

Provider frameworks describe the same territory in their own words. AWS's Cloud Adoption Framework says the platform can help customers "lower costs, reduce business risks, improve operational efficiency, become more agile, innovate faster, create new revenue streams, and reinvent customer and employee experience" (provider documentation, November 2021) [6]. Microsoft's Cloud Adoption Framework tells customers to "tie every cloud initiative to a measurable business objective so investment trade-offs are explicit and defensible," and lists cost efficiency, resiliency, security and sustainability as dimensions that shape cloud outcomes (provider documentation, updated May 2026) [7]. Treat both as provider claims about what is possible, not evidence of what a given buyer will get.

Each engine has a different sponsor inside the buying group, and that is why value conversations so often stall. The CFO and the FinOps team own the cost engine and are measured on spend against budget. Engineering and application leaders own the speed engine and are measured on delivery. The CIO, infrastructure leader and CISO share the resilience engine, measured on availability and risk. Business unit leaders and the chief digital or data officer own the growth engine, measured on revenue and new capability.

A business case built on one engine convinces one of those people; one that blends all four into a single number convinces none, because nobody can defend the parts they do not own.

The general selling discipline applies directly here. The Sales Agent article on Value Creation in B2B Selling: What the Evidence Says It Actually Means defines value as the work that leaves the buyer measurably better off in the buyer's own economic terms, and sets out four tests every value claim must pass: Anchor (a metric the customer already tracks), Alternative (net of the next best option, including doing nothing), Arithmetic (an equation the buyer can edit) and Advocate (a named person who will restate it). The four engines tell the seller where to look; the four tests tell the seller whether a claim is ready to leave the room. For how those claims come together into a decision document, see The Business Case: Why the Best ROI Model Still Loses to "No Decision".

Most of the modeled value is not cost savings. McKinsey estimated in November 2022 that cloud adoption could generate about $3 trillion in EBITDA value by 2030 across Forbes Global 2000 companies (analyst estimate) [1]. Its breakdown is the most useful part for sellers. What McKinsey calls "rejuvenate" value (cost and risk) totals $873 billion, of which IT cost optimization is only $155 billion, digitization of core operations $311 billion, and improved resilience and risk reduction $407 billion. "Innovate" value totals $2.3 trillion, with $612 billion from innovation-driven growth and $1.7 trillion from accelerated product development and hyperscalability [1]. By those figures, direct IT cost reduction is roughly 5% of the total. A year later, McKinsey stated that the value cloud generates from enabling businesses to innovate is worth more than five times what is possible by simply reducing IT costs [2]. These are modeled estimates built on use-case assumptions, not measured outcomes, and should be presented that way.

Most companies are not capturing it. In its November 2023 report, McKinsey found that only 10% of companies have fully captured cloud's potential value, another 50% are starting to capture it, and 40% have seen no material value (analyst data; the summary does not state the sample size) [2]. It names three sources of lost value: unrealized use cases (focusing on IT savings rather than new value), cloud sprawl (redundant cloud foundations) and stalled adoption, noting that breakeven generally comes at around 50% cloud adoption while the median large company runs only 15-20% of its applications in cloud [2].

The speed engine depends on practices, not hosting. DORA, the software delivery research program run by Google Cloud, has tested the five NIST characteristics against delivery outcomes for several years. In its 2019 survey, only 29% of respondents who said they had adopted cloud agreed that they met all five characteristics [3]. In both 2018 and 2019, elite performers were more than 23 times more likely than low performers to meet all five [3]. In 2019, respondents who met all five were 2.6 times more likely to estimate the cost of operating their software accurately and twice as likely to identify their most operationally expensive applications [3]. The 2023 report associates flexible infrastructure with 30% higher organizational performance, and the 2024 report warns that organizations "may be better off staying in the data center if they are not willing to radically transform their application or service" [3]. These are survey-based, correlational findings from a program run by one provider, about software delivery teams; their direction is still clear: paying a cloud provider is not the same as operating a cloud.

The option value is strongest for young and growing businesses. Two studies using government microdata point the same way. Jin and McElheran, using US Census Bureau data on roughly 26,000 manufacturing establishments a year from 2006 to 2014, found that the ability to "rent" IT as needed, in particular through cloud computing, was associated with significantly higher survival and growth among young plants, while investment in traditional IT capital increased the likelihood of failure [4]. Young plants failed at an average annual rate of 3.33%, against 1.35% for older plants, and older plants showed gains from IT services mainly when they were very small or faced high uncertainty [4]. That paper is a 2018 working draft, and its results are associations. DeStefano, Kneller and Timmis, in a peer-reviewed study using UK firm data and the rollout of fiber broadband as an instrument for cloud adoption, found that cloud leads younger firms to increase revenue, employment and productivity, while incumbent firms experience no scale effects and weaker productivity gains, instead restructuring through establishment closures and spreading activity farther from headquarters [5]. For an enterprise seller, the lesson is not that large companies gain nothing. It is that for established buyers, value comes through reorganization (closing sites, consolidating operations, changing where work happens), and reorganization requires sponsorship well above IT.

Leading with the smallest engine. Cost reduction is the easiest story to tell and the easiest to verify, which makes it the easiest to fail. If the business case rests on IT savings alone, it competes with the smallest slice of the value [1] and invites a line-by-line comparison against a depreciated data center that the cloud may lose.

Promising value the buyer has not agreed to earn. Every engine requires an operating change: rightsizing and commitment management for cost, self-service and automation for speed, tested multi-zone architecture for resilience, and product investment for growth. A savings figure with no named person responsible for that change is a forecast of disappointment. DORA's finding that most self-described cloud adopters do not meet the basic characteristics [3] is the warning.

Stopping at the migration. A workload moved without change ("lift and shift") can carry the old cost structure into a new billing model. McKinsey's stalled adoption point [2] and DORA's 2024 warning [3] describe the same trap: the buyer pays the cost of moving without reaching the volume or the change needed to break even.

Ignoring the cost of the change itself. Retraining, re-architecture, dual running during migration and new governance tools are real costs. McKinsey notes that remediating some applications can require investment equal to several years of their support and maintenance costs [2]. A business case that omits them will be rebuilt by someone else.

The Value Engine Audit is a reusable way to find where cloud value lives for this buyer and whether it is real. Run it with the buyer, not for them. For each of the four engines, answer five questions:

Score each engine as Strong, Possible or Absent. Most good deals have one Strong engine that justifies the decision and one Possible engine that justifies the ambition. A deal where every engine is Possible has no business case yet. A deal where the only Strong engine is cost on a steady workload deserves an honest conversation about whether the cloud is the right home for it.

The audit connects to the Operating Model Map from the previous article: the Map names who owns each decision cloud moves, and the Audit names who owns each return.

For account executives: stop opening with savings. Ask which of the four engines the buyer's compelling event depends on, then find the owner of that metric and build the case with them. Use the Four Tests before any number goes into a proposal.

For sales engineers and architects: you own the Mechanism and Change rows. Be precise about which workloads benefit from elasticity and which do not, and write down the operating changes each engine requires.

For partners: the evidence says value comes from change, not hosting. Position migration, modernization, platform engineering and FinOps services as the work that turns a Possible engine into a Strong one, and measure your engagements on the buyer's metric rather than on workloads moved.

For sales leaders: inspect deals by engine. Ask reps which engine is Strong, who owns it and what metric both sides will track after signature. The next engine is the next expansion conversation.

Cloud makes value possible; the buyer's change in how it works makes it real. Sellers who help buyers choose the engine, name the owner and measure the result sell a return the buyer can defend.