The real cost of migrating between clouds

Quick answer

Compare four buckets, not one: run-rate difference (usually 10 to 25 percent, often less after discounts), one-time exit cost (data egress, dual-running, cutover), engineering cost (rewriting managed service integrations, IaC, CI, observability, runbooks), and productivity drag during and after the move. A mid-sized estate typically needs 12 to 30 engineer-months and 6 to 18 months of elapsed time. Payback under three years is common only when the run-rate saving exceeds roughly 25 percent or the move solves a non-cost problem too.

Cloud-to-cloud migration proposals almost always start with a price comparison spreadsheet showing 22 percent lower compute rates. That spreadsheet is the least reliable part of the analysis, because compute rates are the piece providers compete on hardest and the piece your existing discount agreement already addresses. The cost that decides the project sits elsewhere.

The four cost buckets

Bucket	Typical magnitude	Timing
Run-rate difference	10 to 25% of annual spend	Ongoing, after cutover
Exit and data movement	0.5 to 3 months of spend	One-time
Engineering effort	12 to 30 engineer-months	Spread over 6 to 18 months
Dual running	30 to 70% of spend during overlap	3 to 9 months typically

For a company spending 2.4 million USD a year, a 20 percent run-rate saving is 480,000 USD annually. Against that, 20 engineer-months at roughly 16,000 USD fully loaded per month is 320,000 USD, six months of 50 percent dual-running is 600,000 USD, and egress plus cutover tooling might add 120,000 USD. Total one-time cost of roughly 1.04 million USD against 480,000 USD a year is a 26-month payback before considering any productivity loss. That is not obviously a bad deal, but it is not the six-month win the price spreadsheet implied.

Egress is the visible cost and rarely the biggest

Moving 400 TB out of a provider at roughly 0.05 to 0.09 USD per GB after volume tiers is somewhere between 20,000 USD and 36,000 USD. Real, worth planning for, and typically dwarfed by engineering time. Some providers waive egress for a documented full exit within a limited window, which is worth asking about explicitly. Physical transfer appliances change the arithmetic for very large datasets but add weeks of elapsed time. The general mechanics are covered inegress cost optimization.

Managed services are where the engineering months go

Lifting virtual machines is mechanical. Replacing managed services is not. Every place the application depends on a provider-specific managed queue, event bus, identity service, serverless runtime, managed database flavor, or IAM model becomes a rewrite with its own testing and its own failure modes.

Inventory these before estimating anything. Count the distinct managed services in use, then rate each as equivalent (a like-for-like exists, days of work), adaptable (semantics differ, weeks), or rewrite (no equivalent, months). A team with 4 rewrites and 11 adaptables is looking at two to three quarters of platform work regardless of how the compute prices compare.

Count the surrounding systems

The application is not the only thing that moves. Infrastructure as code modules, CI/CD pipelines and runners, observability dashboards and alert rules, log pipelines, secret management, backup and disaster recovery, network connectivity to offices and partners, compliance evidence, and every runbook referencing a provider console. This layer is routinely forgotten in estimates and routinely accounts for 30 to 40 percent of the total effort.

Dual running is the dominant one-time cost

Almost nobody cuts over in a weekend. Realistic migrations run both environments in parallel for months while traffic shifts service by service. During that window you pay for both, plus cross-cloud data transfer between the halves, which can be substantial for chatty services. Compress the overlap aggressively: migrate by bounded context, cut over completely, decommission immediately. Every extra month of overlap on a 2.4 million USD estate costs roughly 100,000 USD at 50 percent duplication.

People cost more than machines

A team fluent in one provider becomes junior overnight on another. Expect a productivity dip of 15 to 25 percent for one to two quarters after cutover, plus training, plus the risk of attrition among engineers who specialized in the old platform. Also count the features not shipped while the platform team migrates. That opportunity cost is usually larger than the egress bill and never appears in the spreadsheet.

When the move actually makes sense

Three situations justify it. The run-rate saving is large, above roughly 25 percent, and durable after accounting for the discount agreement you would get by staying and renegotiating. The move solves a non-cost problem that has independent value: a compliance requirement, a region you need, a service capability that materially changes the product. Or the workload is narrow and portable, in which case migrating one workload rather than the estate cuts the effort by an order of magnitude and preserves leverage for the next contract negotiation, as described inenterprise discount negotiation.

Model the target before you commit

The strongest way to de-risk the decision is to build the target architecture in infrastructure as code for a representative slice and price it properly, rather than mapping instance types on a spreadsheet. C3X prices Terraform for multiple providers from a live catalog, so a proposed target design can be costed with the actual resource shapes and storage classes you would deploy. Compare against your current amortized cost, not list price, and the run-rate half of the business case stops being guesswork. See theresource catalog.

FAQ

What are the main costs of migrating between cloud providers?

Four buckets: the ongoing run-rate difference (usually 10 to 25 percent and smaller once existing discount agreements are counted), one-time exit costs including data egress and cutover tooling, engineering effort to rewrite managed service integrations and surrounding systems, and dual-running while both environments operate in parallel. Engineering effort and dual running normally dominate, not egress.

How much does data egress cost in a cloud migration?

Moving 400 TB out typically costs between 20,000 USD and 36,000 USD at roughly 0.05 to 0.09 USD per GB after volume tiers. It is real but usually small next to engineering time. Some providers waive egress for a documented full exit within a limited window, which is worth requesting explicitly, and physical transfer appliances can help with very large datasets at the cost of extra elapsed time.

How long does a cloud-to-cloud migration take?

For a mid-sized estate, typically 12 to 30 engineer-months spread across 6 to 18 months of elapsed time. The variable is managed service dependency: lifting virtual machines is mechanical, but each provider-specific queue, event bus, identity model, serverless runtime, or managed database flavor becomes a rewrite with its own testing burden and failure modes.

Why is dual running the biggest one-time cost?

Realistic migrations shift traffic service by service over months rather than cutting over in a weekend, so both environments bill simultaneously and cross-cloud transfer between the halves adds more. On a 2.4 million USD estate, each extra month of 50 percent duplication costs roughly 100,000 USD. Migrating by bounded context and decommissioning immediately after each cutover is the main lever.

What gets forgotten in cloud migration estimates?

The surrounding systems: infrastructure as code modules, CI/CD pipelines and runners, observability dashboards and alert rules, log pipelines, secret management, backup and disaster recovery, network connectivity to offices and partners, compliance evidence, and every runbook referencing a provider console. This layer routinely accounts for 30 to 40 percent of total effort and is rarely in the first estimate.

When does switching cloud providers actually pay off?

When the durable run-rate saving exceeds roughly 25 percent after accounting for the discount you could negotiate by staying, when the move solves a non-cost problem with independent value such as a compliance or regional requirement, or when the workload is narrow and portable enough that moving one system rather than the estate cuts effort by an order of magnitude while preserving negotiating leverage.

What to do next

Price the target architecture, not a spreadsheet of instance types. C3X prices Terraform across providers from a live catalog. See the resource catalog.