82% of enterprises run workloads across two or more public cloud providers, up from 76% in 2024, according to Medha Cloud's 2026 statistics compilation. Multi-cloud migration has become the ordinary shape of a mature footprint, and the planning method has not kept pace. Most migration work still begins from a design built for one provider, one identity model and one bill, then meets the additional provider at the point where correcting that design costs the most.
Definitions and boundaries that change the work
Multi-cloud migration is the act of moving or placing workloads across two or more public cloud providers, in combinations such as AWS with Azure or AWS with Google Cloud. Cloudtech's guide to multi-cloud migration strategies fixes the boundaries that keep the term from drifting: single-cloud migration puts everything with one provider, and hybrid cloud joins on-premises infrastructure to a single public cloud through products such as AWS Outposts or Azure Arc. Intuz's multi-cloud strategy guide draws the same line and adds that hybrid requires on-premises integration while multi-cloud can run entirely across public providers.
Those boundaries do real work. They fix what has to be duplicated, reconciled and assigned. A single-cloud migration moves workloads between tiers within one control plane. A multi-cloud migration moves them between control planes, and the reconciliation work that results has no one responsible for it until a role is appointed.
Two control planes create a reconciliation task
Everything that made a first migration tractable was a property of one provider: one identity system, one network fabric, one tagging scheme, one cost export, one support relationship, one region map. An additional provider repeats each of those and adds the work of reconciling them. CACI's 2026 guide to cloud migration challenges reports that misconfigured identity and access management, and excessively broad privileges, remain among the leading root causes of cloud incidents. That finding applies within a single provider. Two providers means two role models, two policy engines and two evidence trails that an auditor will ask you to join up.
Assessment decides placement before a provider is chosen
Cloudtech's guide lays out three readiness questions that decide placement for each workload: its legacy dependencies, including databases, licence servers and on-premises authentication; its data gravity, meaning where the bulk of its data rests and what moving it costs; and its latency sensitivity, meaning whether its response times survive a cross-cloud network path. CACI adds the failure mode that makes this work unavoidable, warning that a single missed dependency can cause an outage when a workload moves.
The assessment should end in one decision-ready entry per workload, giving a responsible role, a dependency list, a data classification, a recovery target and a proposed treatment. Medha Cloud reports that 47% of migration delays are caused by legacy application dependencies that were not identified during assessment. Discovery exports leave that gap open. Interviews with application leads close it, which is why readiness evidence is approved by a technical lead, a security lead and a business lead rather than filed by a tool.
Treatment choices, including the one multi-cloud alone opens
The seven treatments are retire, retain, rehost, relocate, repurchase, replatform and refactor. New Horizons reports that the 7 Rs model evolved from the Gartner 5 R model published in 2010, and frames the seven as different targets rather than sequential stages. Retire decommissions a system that no longer earns its place. Retain leaves a workload where it is. Rehost moves it with minimal change. Repurchase replaces it with SaaS and removes a migration dependency altogether. Replatform makes modest adaptations, often onto a managed database. Refactor rebuilds it against cloud-native services and gives up the most portability. Relocate is the treatment that exists only because there is more than one provider, and it works best between compatible infrastructure types.
Intuz identifies a further choice within that decision, between shallow and deep integration. Shallow moves an application with limited change to the server that runs it. Deep modifies it during the move to take advantage of auto-scaling, dynamic load balancing, serverless execution and a cloud-specific data store. Deep integration buys capability and pays for it in the future cost of leaving.
Interconnects and egress meters on the cross-provider route
Cloudtech's guide reports that Google Cross-Cloud Interconnect joins Google Cloud directly to AWS or Azure, while AWS Direct Connect and Azure ExpressRoute join a customer network to its own cloud. Each product takes a different route, so map the real route before projecting latency or cost.
Two meters run on that route. Medha Cloud reports that data transfer fees account for 6% to 12% of total migration cost and that cross-cloud migrations take about 2.3 times longer than on-premises-to-cloud migrations because of egress charges and API differences. New Horizons lists the practical mitigations: keep data close to where it is accessed, use intra-provider transfers where the rate is low or free, negotiate bundled pricing, prefer dedicated interconnects to public internet routing, cache frequently requested data and remove redundant copies. Budget for the round trip at the route, target and volume you actually use.
Identity, security evidence and residency by workload
Cloudtech's security sequence begins with a zero trust baseline, least privilege everywhere, one role-based access control model and federated identity so a user or service account does not need a separate credential for each cloud, with unified cloud security posture management to catch misconfiguration across both footprints. F1 Group, which points to the NCSC's guidance on lifting and shifting and its requirement that the platform be securely configured in line with separate cloud security guidance, also reports that the UK government's Cloud Challenge Book 2026 found that 60% of government digital services had moved to cloud by July 2026, with 28% of the remaining footprint still legacy after thirteen years.
Residency is decided workload by workload from legal obligation, supplier contract, processing location, backup design and recovery region. The security lead approves the outcome before deployment. A single residency slogan will not survive contact with a portfolio that includes regulated records, low-latency systems and ordinary business applications.
Buying signals from UK public sector listings
UK public sector buyers can see the shape of that engagement on the Digital Marketplace. The G-Cloud listing from Clarity Tech prices migration onto a multi-cloud platform at £550 to £1,250 per practitioner per day, with SC-cleared staff and CHECK-certified testers, and it commits to artefacts rather than platforms: technical discovery, workshops with application leads, a right-sizing assessment, Zerto-based replication for virtual workloads, and a choice of technology taken from a multi-cloud portfolio.
That listing is useful as a scoping document even to a buyer who will not use it. It shows what a migration supplier is willing to be held to: concrete deliverables, day rates, security clearances and a defined method, priced per practitioner rather than per workload or per environment.
Which sections matter to which reader
A finance lead drafting the business case needs the definition boundaries and the egress meters, because both decide the shape of the budget. An architecture lead needs the placement questions and the treatment list, because those two decide what crosses a provider boundary at all. A security lead needs the identity and residency material, and a buyer scoping an engagement needs the marketplace listing as a model of what a supplier can be held to. The sections build in that order because each one narrows what the next has to resolve: the definition fixes the scope, the placement work decides what moves, the treatment decides how, the route decides what it costs, and the controls decide whether the move can be approved.
The pages beneath this one take each of those decisions in turn, on assessment, cost, security, tooling and strategy. This page is the orientation; the depth belongs there.
Sources
- Multi-Cloud Migration Strategies
- Strategies for Successful Multi-Cloud Data Migration
- Cloud Migration Challenges: Risks, Strategy & Best Practices 2026
- 50 Cloud Migration Statistics for 2026 — Success & Failure Rates
- 10 Cloud Migration Best Practices for Microsoft Businesses
- Guide on Multi-Cloud strategy — The future of cloud migration
- Cloud Migration — Digital Marketplace
