The pricing page looked straightforward. Compute costs, storage tiers, egress fees listed in clean rows. The engineering lead at a mid-size SaaS company, call them Meridian (the company has asked not to be named, a request that itself tells you something), chose the option with the lowest monthly estimate. Their CFO signed off. The migration team spent six weeks moving workloads over. Fourteen months later, Meridian moved everything back.
The bill had come in roughly double what the pricing page implied. Not because of hidden fees, exactly. Because of the gap between what a pricing page measures and what running software actually costs.
The Setup
Meridian built a multi-tenant analytics platform. Their architecture was read-heavy, with bursty traffic patterns tied to end-of-month reporting cycles. They were spending meaningfully on their existing cloud provider and believed, reasonably, that the same workload on a cheaper provider would cost less. The new provider’s per-core compute rate was lower. Storage was cheaper. On paper, the math worked.
What the paper didn’t capture was operational complexity. The new provider’s managed Kubernetes offering was a minor version behind the market leader’s, which mattered because two of Meridian’s dependencies had stopped supporting that version. Their database backup tooling had been built around specific snapshot APIs that the new provider implemented differently. The object storage tier had subtly different consistency guarantees, which their caching layer didn’t account for.
None of these were dealbreakers in isolation. Together, they were a full-time job.
What Happened
Meridian’s engineering team, which had been sized for product work, spent the first three months post-migration in remediation mode. A senior engineer who had been allocated to a new feature shipped nothing for eleven weeks. Another team member became the de facto expert on the new provider’s quirks, a role that existed nowhere in the org chart and that no one had planned for.
The direct compute savings were real. They shaved roughly 20 percent off their infrastructure line item. But they hadn’t modeled the opportunity cost of engineering hours redirected from product to compatibility work. They hadn’t priced in the customer support load that increased as subtle reliability differences manifested in the product. And they hadn’t accounted for the eventual migration cost back, which was itself non-trivial.
When Meridian’s CTO eventually ran the numbers retrospectively, the “cheaper” option had cost more than staying put would have, even before accounting for the features that didn’t ship and the sales cycles that slipped because the product stalled.
This is not a story about a bad provider. The provider Meridian chose is used successfully by companies at scale. It is a story about the mismatch between how cloud costs are presented and how they actually accumulate.
Why the Pricing Page Lies (Not Intentionally)
Cloud pricing is almost always quoted at the resource level: CPU-hours, GB-months, API calls. What it doesn’t quote is integration cost, operational familiarity, tooling compatibility, or the cognitive overhead of a team learning a new platform while also shipping a product.
For a greenfield project with no existing tooling, no migration burden, and a team with time to invest in platform expertise, the cheapest compute rate often does translate to the cheapest bill. Those conditions rarely exist for a company in the middle of building something.
The hidden cost structure breaks down into roughly four categories. First, migration costs: moving workloads is never free, and the engineering time required is almost always underestimated in initial projections. Second, compatibility gaps: managed services across providers are not interchangeable, even when they share an open-source base. Third, operational learning curves: your team has accumulated knowledge about how your current platform behaves under load, at failure, and at the edges of its quotas. That knowledge doesn’t transfer. Fourth, the opportunity cost of the work that doesn’t happen while engineers are solving the above three problems.
The fourth category is the one that kills you. It’s invisible on a ledger.
What This Looks Like at Scale
The Meridian case is a small-company version of a pattern that plays out at larger companies with more zeros. When enterprises have migrated workloads for cost reasons and found the savings smaller than projected, the culprit is rarely fraud or misrepresentation. It’s almost always undercounted switching costs and the undervalued expertise embedded in existing operations.
Amazon, Google, and Microsoft understand this dynamic very well. It’s a significant part of why each of them invests heavily in services that are deeply integrated with the rest of their platform: the stickiness is a feature of the architecture, not an accident. Switching costs are the moat, and they’re built into the product whether you see them or not. This is also why the most profitable software firms often hire fewer engineers than you’d expect, not because they do less, but because deep platform familiarity compounds in ways that headcount can’t easily substitute for.
What We Can Learn
The honest version of a cloud cost comparison includes engineering hours for migration, a realistic timeline for reaching operational parity, a compatibility audit against your existing tooling and dependencies, and some estimate of the product work that will slip during the transition period.
That math is harder to do than comparing pricing pages, which is why most organizations don’t do it rigorously before making the decision. They do it afterward, when the bill arrives.
Meridian’s CTO told me something that stuck: “We treated it like buying a cheaper commodity. But we weren’t buying a commodity. We were buying into a platform we’d have to learn, integrate, and operate. The price of the compute was the smallest part of what we were actually purchasing.”
The cheapest compute rate and the cheapest cloud bill are related but not equivalent. Closing the gap between them requires accounting for everything that doesn’t appear on the pricing page, which is most of what you’ll actually spend.
