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.
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.
- 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.
- No actual portability. The "avoid lock-in" justification rarely holds up, because almost nobody has actually built workloads to be portable between clouds. You get the cost of multi-cloud without the benefit.
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? If it's the latter, the right move usually isn't a rushed consolidation — it's an honest architecture review that decides, deliberately, which workloads actually benefit from which platform, and which ones are multi-cloud purely by historical accident.
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 — it needs to be resourced like the strategic decision it is: a team with genuine, deep expertise across the platforms in play, clear ownership of the boundary between them, and a documented reason revisited on a schedule, not assumed forever.
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.