How to choose the right cloud (and stop re-litigating it every six months).

Walk into any large enterprise mid-cloud-strategy and you'll find the same argument happening. It's been happening for two years. It will probably happen for two more.

One faction wants AWS because that's where the talent is. Another wants Azure because the Microsoft contract already covers it. A third wants GCP for the data and AI tooling. Someone in the corner is quietly building on Oracle Cloud because that's where the Exadata sits. The CIO has commissioned three RFPs in the last 18 months and made zero binding decisions.

The cost of this indecision — duplicated platforms, fragmented teams, no negotiating leverage with any vendor — is usually larger than the cost of just making the wrong choice. But the choice doesn't get made, because the people involved don't agree on what they're actually choosing.

Here's the framework we use to cut through it.

Step 1: Reframe the question

"Which cloud should we use?" is not a useful question. It's too abstract. Every hyperscaler is good enough at the basics that, for most general-purpose workloads, the technical answer is "any of them." The argument feels intractable because the question being argued isn't the question that matters.

The question that matters is some version of:

"Which cloud, used as our primary platform for the next five years, will let our specific organisation move fastest, with the lowest total cost, on the workloads we actually care about?"

Once you frame it that way, the inputs to the decision become specific to you, not generic to the industry. "AWS has more services" stops being a relevant argument. "AWS has more services that we will plausibly use" might be. "Azure integrates with our identity stack" stops being a tiebreaker. "Azure halves the migration effort for the 60% of our portfolio that's already on Microsoft" might be.

Step 2: Score against the things that actually move

Most cloud comparison matrices we see have a hundred line items, each weighted equally, all of them green or yellow. They produce a score that's the same for every customer. That's not a decision tool, it's a comfort blanket.

A real comparison weights the dimensions that actually differ for your situation — and ignores the ones that don't.

The dimensions we usually find decisive:

• Existing platform gravity. What's the rest of your stack already on? Identity, productivity, data warehouse, ERP. These create real switching costs and real efficiencies — they should be a major input, not a footnote.
• Talent market in your geography. The most beautiful platform on paper is worthless if you can't hire engineers who know it within commuting distance. This is highly regional — what's true in Singapore is not what's true in Mumbai or Sydney or Dubai.
• Workload-specific economics. Most workloads cost roughly the same across hyperscalers. A few do not — data-heavy analytics, GPU training, certain database patterns. If those are your high-volume workloads, the price gap can be significant.
• Sovereign and regulatory fit. Especially if you operate across our region — MAS, OJK, Bank Negara, RBI, SAMA, the UAE PDPL. The right answer for a regulated entity in one country is sometimes different from the right answer in another.
• Vendor relationship and commercial leverage. Where do you already have the executive relationship? Who's willing to commit ecosystem investment, marketplace credits, training subsidies? This matters more than most people admit out loud.

"The cloud comparison everyone is having is generic. The one you actually need is highly specific to your context."

Step 3: Decide whether you're a single-cloud or multi-cloud organisation

This is the question most strategies don't answer cleanly, and it's the one that creates the most expensive ambiguity downstream.

The honest framing:

• Single primary cloud + tactical exceptions is the right answer for most organisations under, say, $500M in revenue or with engineering teams under 200 people. The operational simplicity outweighs the theoretical flexibility benefits.
• True multi-cloud as a strategy — meaning each major workload class has a deliberate platform choice — makes sense for very large enterprises, regulated industries with strict redundancy requirements, or organisations with a strong architectural reason for it (often: data sovereignty, latency, or genuinely different workload economics).
• Accidental multi-cloud — different teams independently picked different platforms over the years and now you're maintaining duplicate skill sets, duplicate platforms, duplicate vendor relationships — is the worst of all worlds. This is what most "multi-cloud" strategies actually are, and the first job is to stop pretending it's a strategy.

Step 4: Make the decision a doctrine, not a preference

The reason cloud decisions get re-litigated isn't because new information emerged. It's because the decision was never made binding enough. A new project lead joins, prefers a different platform, builds something on it, and now you're back to the argument.

The fix is to convert the decision into a written architectural doctrine that:

1. States the primary cloud explicitly, with the reasoning.
2. Defines the criteria under which an exception can be granted (and what the exception process is).
3. Names the architecture authority — usually a small group, sometimes a single CTO or chief architect — who can grant exceptions.
4. Is reviewed on a fixed cadence (we suggest 18 months) — not whenever someone disagrees with it.

This sounds bureaucratic. It is, slightly. But the alternative — every project re-running the cloud decision from scratch — is a tax that compounds across hundreds of projects over years. The doctrine pays for itself in the second project.

Step 5: Plan to revisit, but on a schedule

Cloud decisions are not permanent. The right primary cloud for your organisation in 2026 may not be the right one in 2031, because your situation will have changed, and so will the platforms.

What we tell clients: bake a formal review into the doctrine. Every 18–24 months, revisit the original criteria with current data. If nothing material has changed, that's a five-line memo that confirms the existing decision and lets everyone get back to work. If something has changed, you have a structured way to surface it and re-decide.

This is the opposite of how most organisations operate. Most either never revisit (and end up two CEOs and a generation of technology behind), or they revisit constantly (and never commit to anything). A scheduled review with clear criteria gives you both stability and adaptability.

---

The compressed version

If you're stuck in the cloud-selection loop right now, here's what we'd say in five lines:

1. Stop comparing clouds in the abstract. Compare them against your workloads, talent, gravity and regulators.
2. Pick a single primary cloud unless you have a deliberate, written reason not to.
3. Convert the decision into doctrine, with a clear exception process and a named owner.
4. Schedule the review — don't accept ad-hoc re-litigation.
5. Get back to building.

The companies that move fastest on cloud aren't the ones that picked the perfect platform. They're the ones that picked a good-enough platform, decided it loudly, and stopped having the argument. That's the strategy worth optimising for.