TL;DR: Most cloud migration plans budget for the boring, measurable stuff: uptime, unit cost, release cadence. The line item that almost never makes it onto the slide is that cloud removes the upfront infrastructure cost that used to make certain business models too risky to try, subscription products, API access, expansion into new markets without building anything there. That's not a performance improvement, it's a different set of things your engineering team is now capable of shipping.
Cloud migration business cases are usually built around three numbers: expected uptime, expected unit cost, expected release cadence. All real, all worth tracking, and all of them framed as improvements to the existing business. The category that gets left off the slide entirely is the one McKinsey's cloud-value research actually flags as the largest source of return: business models that weren't viable before because the upfront infrastructure cost made them too risky to try.
Migration and transformation are not the same line item
Migration: moving an app from your servers to a cloud provider. Transformation: the operational change that follows once that app can scale, recover, and ship on a schedule it couldn't manage before. You can complete the first and get almost none of the second, a lift-and-shift onto faster hardware still runs the same slow processes, just somewhere else. The gap between the two is where the return actually lives, and it's mostly not captured by "how's the uptime."
Five areas, ranked by how often they show up in a business case
| Area | What changes | Shows up in the plan? |
|---|---|---|
| Time to market | New environments in minutes, release on demand | Usually |
| Customer experience | Auto-scaling, multi-region keeps services online | Usually |
| Decision-making | Managed data/AI services on tap | Sometimes |
| Cost model | CapEx → usage-based OpEx | Always |
| New business models | Subscription, platform, API products become viable | Rarely |
The last row is the one worth dwelling on, because it's structurally different from the other four. Rows 1-4 make the existing business faster, cheaper, or more reliable. Row 5 makes things possible that weren't on the roadmap at all, a software vendor offering its product as a subscription instead of a license, a company exposing an internal capability as a metered API, a local business serving another country's customers without building anything there. None of that requires new engineering talent. It requires the upfront cost barrier to disappear, which cloud does automatically, and almost nobody puts a line for it in the business case.
The metric nobody tracks for this
If your team is only tracking uptime and unit cost, you're measuring rows 1 and 4 and missing row 5 entirely, because "revenue from a product that didn't exist before the migration" isn't a metric anyone thinks to add to the dashboard until after it's already generating revenue. Worth adding deliberately: track whether any internal capability gets flagged as "this could be its own product" during the post-migration retro. That conversation happens more often than teams expect once the infrastructure cost of trying is gone.
The common worries, briefly
| Worry | The reality | What to do |
|---|---|---|
| "Our data won't be secure" | Providers out-invest most companies on security; shared-responsibility splits the work clearly | Access controls, encryption, monitoring from day one |
| "It'll cost more than on-prem" | Can, without management, with right-sizing and budgets, most orgs cut cost while gaining flexibility | Adopt FinOps, track a unit-cost metric from the start |
| "We'll be locked into one vendor" | Multi-cloud/hybrid design keeps options open | Open standards, infrastructure as code for portability |
None of these three block row 5 specifically, they're about the migration itself, which is exactly why "new business models" gets left off the risk register too. It's not a risk anyone's weighing against; it's an upside nobody's counting.
Proof, briefly
A Sharjah retail group rebuilding for peak-demand reliability (auto-scaling storefront, real-time inventory, CI/CD) didn't set out to launch a new business line, they set out to stop crashing on sale days. The infrastructure work alone drove online revenue up 38% in two quarters, purely from the site staying up and converting the traffic it already had. That's rows 1-4 working. Row 5, an actual new product or revenue line, wasn't even the goal of that engagement, which is itself the point: most teams don't budget for row 5 because they don't go looking for it.
FAQ
Is "new business models" really a cloud benefit, or is that just good product strategy?
Both, cloud removes a specific blocker (upfront infrastructure cost) that used to make certain product ideas too risky to greenlight. The product strategy still has to be good; cloud just changes which ideas clear the risk bar.
How do we know if we have a row-5 opportunity hiding in our stack?
Ask whether any internal-only capability (an API, a data pipeline, an admin tool) would be useful to someone outside the company. If yes, the cost of finding out is now low enough to actually test it.
Does this only apply to software companies?
No, a manufacturer selling data through an API, a logistics firm selling tracking access, anyone running software has capabilities worth checking for this. The starting point differs by industry, the mechanism doesn't.
Originally published on the Sherdil Cloud blog, the full piece (with the complete five-area breakdown and the Sharjah retail case study in full) is here. For the migration path itself, see legacy system modernization; for turning an internal capability into revenue specifically, turning IT into a profit center.
About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.
Top comments (0)