Ask most organizations why they run workloads across AWS and Azure, and you'll get a confident answer about resilience, avoiding vendor lock-in, or best-of-breed services. Look at how it actually happened, and the real story is usually simpler: one team picked AWS in 2019, another team acquired through a merger was already on Azure, and nobody ever unified them because the migration never made it onto anyone's roadmap.
That's not a strategy. It's an accident with a strategy written over it after the fact — and the retroactive justification is worth being honest about, because it changes what the right next step actually is.
Why this matters more than it sounds like it should
An accidental multi-cloud footprint costs more than a deliberate one, in ways that don't show up on a single invoice:
- Duplicated expertise. Your team needs to be genuinely competent in two (or three) different consoles, IAM models, and networking approaches — not shallow familiarity with both, but real depth in each, because a shallow understanding of a cloud platform's security model is exactly where serious misconfigurations come from.
- Security gaps at the seams. Most serious misconfigurations we see aren't inside a single cloud's boundary — they're in the connective tissue between two different platforms that nobody owns end to end. A firewall rule that makes sense in isolation on each side can still leave a genuinely exploitable gap in how the two networks actually talk to each other.
- No actual portability. The "avoid lock-in" justification rarely holds up under scrutiny, because almost nobody has actually built workloads to be portable between clouds — that requires deliberate, ongoing engineering discipline most organizations never actually invest in. You get the cost of multi-cloud without the benefit it was supposedly bought for.
- A support burden that scales with platform count, not workload count. Two clouds doesn't mean twice the operational overhead — it often means more than twice, because the genuinely hard incidents are the ones that require correlating logs, permissions, and behavior across two different platforms' very different tooling, under time pressure.
The honest question to ask first
Before treating your multi-cloud footprint as a strategic asset, ask plainly: did we choose this, or did it happen to us? The honest answer is usually uncomfortable, and it's worth getting anyway, because the two answers lead to genuinely different next steps.
If it's the latter — an accident, not a decision — the right move usually isn't a rushed consolidation either. Migrating a working, if messy, footprint under deadline pressure just trades one set of accidental decisions for another. The right move is an honest architecture review that decides, deliberately, which workloads actually benefit from which platform, and which ones are multi-cloud purely by historical accident and would be simpler, cheaper, and safer consolidated onto one.
What deliberate multi-cloud actually requires
If, after that review, multi-cloud genuinely is the right call — real regulatory requirements, real resilience needs, a real technical reason specific to a specific workload — it needs to be resourced like the strategic decision it is, not inherited like an accident and left alone:
- A team with genuine, deep expertise across the platforms actually in play — not one generalist stretched thin across two consoles, but real depth on each side.
- Clear ownership of the boundary between them. The seam between two clouds needs a specific, named owner, the same way any other piece of critical infrastructure does — "shared responsibility" between two teams too often means neither team actually owns it.
- A documented reason, revisited on a schedule, not assumed forever. The regulatory or resilience justification that was true three years ago may not still be true today, and a multi-cloud footprint that's never re-examined tends to just keep accumulating the costs listed above indefinitely, on the strength of a decision nobody's actually re-checked.
What we actually train teams on
The technical skills — networking across platforms, IAM in two different models, cost visibility spanning both — are teachable, and we build that training regularly. The harder part, and the one that actually determines whether a multi-cloud footprint stays under control, is the organizational habit of periodically asking the honest question above, rather than letting "we're multi-cloud" calcify into an unexamined fact about the company.
Most organizations we work with don't need a plan to leave multi-cloud. They need a plan to be honest about how they got there — and to stop calling an accident a strategy, whether or not they ever actually consolidate anything as a result.