Most teams pick a cross-cloud target the wrong way: they line up the hyperscaler pricing pages, compare on-demand VM rates, and pick the one that looks a few percent cheaper. That is how you end up spending a year re-architecting managed services to chase a saving that was never in the compute rate to begin with. The better approach is to decide on a short list of factors that genuinely change the answer, score your real estate against them, and only then look at providers. This guide gives you that rubric. The one fact to fix first: base on-demand compute rates are broadly similar across the hyperscalers, so cross-cloud savings come mainly from rightsizing, committed-use discounts, and avoiding egress, not from one cloud being inherently cheaper.
Start with the decision, not the provider
Before you shortlist anything, write down one motive and one inventory. The motive, cost, lock-in avoidance, compliance, or corporate strategy, is not a formality, because each one points at a different target and a different scope. The inventory is your dependence on proprietary managed services, marked per service as a clean lift or a re-architecture, because that layer is the real lock-in and the real migration work. A move justified by a VM sticker price will disappoint; a move justified by a clear motive and a scoped managed-service inventory can be planned honestly. Get those down first.
The factors that point to a target
- Your motive. Cost, lock-in avoidance, compliance, and strategy each change the target. An enterprise Microsoft agreement points one way, a data-sovereignty rule another, a genuine commercial-terms advantage a third. Name it before you shortlist.
- Dependence on proprietary managed services. Databases, queues, serverless, identity, and analytics are where lock-in lives and where the work concentrates. Some map cleanly, some need a data-model rewrite, and identity rarely translates line by line.
- Egress exposure. Large transfers between clouds carry egress fees, and steady inter-region or cross-boundary traffic can quietly dominate the bill. Estimate it before it becomes a surprise line item.
- Committed-use and reserved discounts. The savings that actually exist come from committing to reserved or savings-plan pricing on the target. Weigh whether the target’s committed rates beat what you already hold on the source.
- Single-cloud versus multi-cloud. Consolidating onto one provider simplifies operations and strengthens negotiating leverage; deliberately spreading across two buys resilience and leverage at the cost of duplicated tooling and skills. Decide which you are actually buying.
- Ecosystem and skills fit. The provider your team already knows, and whose managed services match your architecture, is cheaper to run than a nominally cheaper one your staff has to learn.
Which cloud your motive points to
Score your estate against the criteria above, then use these as starting points rather than conclusions. A move driven by an enterprise Microsoft agreement or deep Windows and identity investment tends to point at Azure. A workload leaning on data and analytics, or a team that values that ecosystem, often looks first at Google Cloud. The broadest service catalog and the largest partner and skills pool sit with AWS, which suits estates that want maximum service breadth. Oracle Cloud earns a look mainly where Oracle licensing and databases dominate and negotiation leverage is real. The point is that the right target falls out of your motive and your managed-service map, not out of a compute-rate comparison. Remember too that the committed-use discounts making one cloud cheaper are themselves a lock-in, so you are trading one commitment for another rather than escaping commitment.
How the savings case falls apart
Three errors show up repeatedly. The first is justifying the move on on-demand compute rates, which are broadly comparable, when the savings actually live in rightsizing, commitments, and egress avoidance. The second is underestimating the managed-service re-architecture, treating databases, identity, and serverless as lift-and-shift when they are the hard part, and discovering it mid-cutover. The third is ignoring egress in the business case, so a plan that penciled out on compute bleeds on data transfer. A quieter fourth: not modeling whether the target’s committed pricing genuinely beats the source you are trying to leave.
Confirm the case before you commit
Turn your top candidate into a pilot with written acceptance criteria: replicate one representative app group and its data end to end, exercise the migrated managed-service equivalents, and validate function, integration parity, performance at or above baseline, and, critically, cost. Model the move with your own rightsized footprint and negotiated or committed rates rather than list prices, and put egress on its own line. Keep the source as a fallback through a hypercare window so a rollback is a DNS change rather than a re-migration. Choose the target that clears your acceptance criteria and actually delivers the saving your motive promised, not the one with the lowest headline VM rate.
Use the TCO calculator to model a per-vCPU comparison with your own committed rates.