Do cloud control planes port between providers?

No, they do not. Identity, networking, and key management are implemented differently, meaning these must be rebuilt at the target.

How long do cross-cloud migrations take?

They take 2.3 times longer than on-premises-to-cloud moves. This delay is caused by API differences and egress charges.

What are the primary costs of cloud crossings?

Egress charges and the double-run window are major drivers. Egress typically represents 6 to 12% of the total migration cost.

Cloud To Cloud Migration: What Changes in Practice

The counter-argument deserves a fair hearing, because it is the reason a great many subsequent migrations are planned as reruns of the first. A workload that has already left a leased data centre is virtualised, addressable through an API, and kept somewhere in configuration or code. Nothing at the target has to be racked, cabled or delivered. The receiving provider publishes a migration hub, a landing zone accelerator, a pricing calculator and reference architectures, and the engineers who ran the original move are usually still on staff. If both ends are clouds, the costly half of the problem has already been paid for, and what remains is a change of endpoint.

What that reading leaves out is responsibility. Nearly every control the first migration leaned on was supplied by the provider being left, was assembled once within that provider, and has no counterpart at the target until somebody builds it again. The account hierarchy, the logging pipeline, the key management service, the private path back to the retained systems and the policy engine that enforces tag-based access all stay behind. Google Cloud's account of cloud migration treats movement between providers as a type in its own right, used to escape vendor lock-in or to reach capabilities the current platform lacks, and that is the right frame. The workload is not the unit of change. The environment around it is.

The control plane is what changes, and it does not port

Two providers can both be called public cloud and still implement identity, networking and key management differently enough that a clean one-to-one mapping does not exist. The NCSC's guidance on lifting and shifting says that access control belongs to the customer and not to the provider, and that a straight lift and shift leaves most of the management and security burden with you. That is true at both ends. What a crossing changes is what primitives you work with and how much of your existing policy can be expressed in them.

A firewall rule, a role and a key are therefore not portable objects. A role becomes another role with another trust document, and often with a different assumption about what the principal is. A security group becomes a network access control list plus a managed firewall service. A customer-managed key becomes a new key in a new key management service, governed by a new key policy, with a re-encryption pass over everything the old key protected. Federation is the one component that can be made to cross, and it is worth doing first, because it takes long-lived credentials out of the work. A target role that trusts the source provider's identity tokens looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "accounts.google.com" },
      "Action": "sts:AssumeRoleWithWebIdentity"
    }
  ]
}

The value of that document is not its syntax. It is that the trust relationship is defined, versioned and reviewable, which is more than can be said for the service account keys that most cross-cloud projects inherit. The audience restriction that binds the trust to one target project belongs in the same policy, expressed as a check on the incoming token's audience claim. Without it, a token minted for another tenant is accepted, and the federation advantage disappears.

Placement is decided again, because the tiers differ

Once the control plane is accepted as a rebuild rather than a transfer, the placement question reopens, and it is not a formality. The NHS Cloud Centre of Excellence's cloud migration guidance requires each workload to be assessed against risk, technical fit and value, then ties the chosen strategy to a delivery tier: rehost and revise land at IaaS, rearchitect and rebuild at PaaS, replace at SaaS. Applied to a crossing, that leaves three outcomes rather than one. A workload that ran at IaaS at the source may have a managed PaaS equivalent at the target, in which case the operating burden falls and the control surface narrows. It may have no equivalent, in which case IaaS remains and the security burden stays exactly where it was. Or the target's marketplace may offer a SaaS replacement, in which case the work becomes a data extraction and the placement question becomes a contract question. That same guidance is careful to say the strategy-to-tier link is not strict, and a crossing is where the caveat earns its place.

Data movement is metered at both ends, which is new

An on-premises migration moved data across a link the organisation already paid for. A crossing moves data across a boundary priced per gigabyte in each direction, and the price on the outbound side is set by the provider being left, not by the provider being joined. Cybertize Technologies' 2026 to 2027 benchmark report puts egress at 6 to 12% of total migration cost and identifies the double-run window, where both environments are billed at once, as a heavier driver of overrun than compute or storage pricing. The same report puts budget overruns at 38% of migrations and missed timelines at 31%, and reports that 86% of the chief information officers surveyed intend to move at least some workloads back out of public cloud.

The Medha Cloud statistics compilation shows that cross-cloud migrations take 2.3 times longer than on-premises-to-cloud migrations, because of egress charges and API differences, that 18% of projects roll back at least some workloads for performance, cost or compatibility reasons, and that 25% of organisations have already brought at least one workload back to on-premises or colocation.

Those numbers shape the work rather than its mood. The data has to move first and the compute after it, the delta window has to be bounded in hours rather than weeks, and the source has to stay readable until the target has been proven under production traffic rather than under test traffic. A crossing is rarely the last move an organisation makes, so the exit terms at the provider being joined deserve as much scrutiny as the ones at the provider being left. This section is the part a finance lead needs; the sections above it are the part an infrastructure lead needs.

The crossing sequence, in the order the risks arrive

Rebuild the landing zone at the target and prove the guardrails are effective before any workload is scheduled onto it.
Establish the identity plane in both directions and remove standing credentials from the work.
Replicate data within a bounded delta window, and check the target copy against the source before compute moves.
Cut over DNS and freeze writes at the source, with the freeze announced and timed in advance.
Keep the source systems readable and warm for a defined period, with one individual responsible for watching it.
Decommission the source only on evidence that the target has performed under load for the agreed period.

The order matters more than the contents. Steps three and four are where most teams compress their own schedule, and step six is where they leave money on the table by keeping an environment alive long after it has any use.

Cutover control, and the rollback you can execute

Cyber-Duck's cloud migration practice lays out the execution order a crossing needs: infrastructure as code to provision the target environment, continuous integration and continuous deployment pipelines to automate deployment, and a final data migration with a DNS switchover after quality, accessibility, security and compliance tests are passed. The parts worth adopting are the order and the evidence, not the tooling. A rollback that has been executed in a test environment against the same infrastructure definitions is the only kind that can be trusted during a cutover window, and the decision to use it belongs to the individual who has watched the source and the target together for the full duration of the freeze.

What this page orients, and what it hands on

This page has mapped the practice of moving between clouds rather than repeating the mechanics of a first migration. It has shown that the control plane is the unit of change, that placement is decided again because tiers differ, that data movement is metered on both sides, and that a crossing proceeds through a sequence where the risks arrive in a known order. The depth on each of those belongs to the pages beneath this one: the assessment pages for workload-level checks, the cost pages for the double-run model, the security pages for the landing zone and identity controls, and the checklist pages for the lines you mark true or false against your own infrastructure. What a reader should carry away is the recognition that a cloud-to-cloud move is not a rerun of the first migration, and that the environment around the workload is where the work actually lies.