Most cloud transformations do not fail at the technical layer. They fail in the six months before any workload moves — in rooms where the wrong questions are being asked.
Organisations spend weeks evaluating providers. They compare pricing calculators, benchmark regions, and negotiate enterprise agreements. Then they start migrating. And six months later, they are running three providers they did not fully plan for, with costs they cannot attribute, and a governance model that exists only in a slide deck.
The technology was never the problem.
Multi-cloud is a posture, not a plan
Most organisations do not choose multi-cloud. They arrive at it. A business unit discovers AWS is faster for analytics. Azure is already in place because of the Microsoft enterprise agreement. GCP enters through a data science experiment that quietly became production. Before any deliberate decision was made, the organisation is running across three providers.
This is not a failure of discipline. It is the natural result of distributed decision-making in a fast-moving organisation. The failure is in not designing for it — in never asking, before any of this happened, what portability would need to look like.
Multi-cloud managed well does not start with a provider selection exercise. It starts with a portability conversation.
Portability before providers
Portability is not a technical feature you can add later. It is a design constraint you accept early — or pay for heavily afterwards.
It means building workloads that do not depend on proprietary services they cannot function without. It means containerising where it makes sense, using cloud-agnostic orchestration for the pieces that matter, and understanding data residency requirements before they become a crisis at contract renewal time.
This does not mean avoiding managed services. Avoiding managed services would be wasteful and impractical. It means being conscious about which proprietary dependencies you are accepting, and which you are not. A managed Kubernetes service is a reasonable choice. A workflow engine baked into a single provider's ecosystem that your entire data pipeline depends on — that deserves a clearer conversation before you commit.
The organisations that manage multi-cloud well did not plan to be multi-cloud. They planned for portability — and that made multi-cloud manageable when it arrived.
The early optimisation trap
Once workloads are running in the cloud, the pressure to optimise appears almost immediately. Finance wants a cost reduction story. Platform teams want to demonstrate value. Vendors offer tools that promise to cut your bill significantly if you just commit to their architecture.
Most early optimisation efforts anchor you deeper into a single provider before your workload patterns are stable. Reserved instances and savings plans are reasonable — but they are commitments. Cloud-native services that replace portable middleware are efficient — but they narrow your exit options. Cost optimisation before you have six to twelve months of real usage data is premature. You are making permanent decisions on temporary evidence.
The organisations that rushed optimisation in year one often spent years two and three unravelling decisions that looked rational at the time. The ones that stayed patient built leverage. They knew their actual usage before they committed to it.
What governance actually means here
Cloud governance is not a spreadsheet of approved services. It is not a central approval committee that slows everything down while adding no safety. And it is not a RACI chart that nobody reads after the workshop.
Governance in a cloud context means a small number of clear guardrails enforced through policy as code — not through human gatekeepers. It means tagging standards that make cost attribution possible without a quarterly archaeology project. It means landing zone patterns that give teams a safe starting point, so that every new workload does not have to resolve the same networking, identity, and security questions from scratch.
The right governance model is one that teams forget about because it works in the background. When governance requires humans to act as approvers, it will be bypassed, or it will slow everything down. Usually both, at different times.
What the thinking requires
Cloud is not a destination you arrive at and stop. It is a capability — and what you get from it depends almost entirely on decisions made before you were under pressure to make them.
The organisations that arrive with the least chaos are the ones that treated cloud transformation as a set of architectural decisions to make carefully, not a migration programme to complete quickly. They were patient about optimisation. They were deliberate about portability. And they were honest about what governance could realistically enforce at their scale.
The technology was rarely the hardest part. The thinking before it usually was.
What to decide first
- Decide your portability constraints before you decide your provider commitments — the order matters more than most teams realise.
- Give yourself a full usage cycle before optimising. Premature commitment purchases are the most common source of regret in cloud programmes.
- Build governance into the landing zone, not the approval process. Policy as code enforces standards at every scale; humans in the loop do not.