Cloud migration cost: what companies really spend
A cloud migration typically costs $15,000-60,000 for a small project, $60,000-250,000 for a mid-size application stack, and $250,000 or more for large enterprise environments with legacy dependencies. The number that actually lands depends far more on how much you re-architect versus simply relocate, and on data volume, than on which cloud provider you pick.
What actually drives the cost
Number of services is the first multiplier. Migrating a single web app with one database is a fundamentally different project from migrating 40 interconnected microservices, each with its own dependencies, data store, and deployment pipeline. Cost scales close to linearly with service count once you're past a handful.
Re-architecture versus lift-and-shift is the second, and often the biggest, lever. Lift-and-shift, moving infrastructure roughly as-is into cloud equivalents, is typically 30-50% cheaper upfront than re-architecting for cloud-native patterns like autoscaling, managed databases, and serverless functions. The catch is that lift-and-shift often costs more over time, since you're not capturing the efficiency gains cloud infrastructure is actually built for. Teams choosing based purely on upfront cost sometimes end up paying twice.
Data volume drives both cost and timeline. Transferring terabytes of data isn't just a bandwidth problem, it's a cost problem: cloud providers charge for data egress, and transferring large volumes over extended windows adds both direct transfer costs and the cost of the engineering time spent managing it safely.
Downtime tolerance is the final major driver. A migration that can tolerate a maintenance window is meaningfully cheaper than one that must run zero-downtime, since zero-downtime migrations require running parallel environments, extra validation, and more careful phased cutover work, all of which is engineering time.
Cost breakdown by migration size
| Migration size | Typical range | What's typically included |
|---|---|---|
| Small (1-5 services, single database) | $15,000-60,000 | Assessment, lift-and-shift or light re-architecture, basic validation |
| Mid-size (full application stack, 5-20 services) | $60,000-250,000 | Deeper re-architecture options, phased cutover, monitoring setup |
| Large enterprise (20+ services, legacy/compliance needs) | $250,000-1,000,000+ | Extensive dependency mapping, compliance validation, staged rollout over months |
These ranges assume the migration itself, ie. planning, execution, and validation. They don't include ongoing cloud hosting costs after migration, which are a separate, recurring line item.
The hidden costs companies miss
Data egress fees are the most commonly underestimated cost. Moving data out of a cloud provider, whether during a multi-cloud migration or a later provider switch, is billed per gigabyte and can add up meaningfully for data-heavy applications. This cost is easy to miss because it doesn't show up until you're already partway through, or until you try to leave.
Parallel running costs are the second miss. During a safe, phased migration, you're paying for both the legacy environment and the new cloud environment simultaneously for weeks or months. Budgets built around "cloud costs replace on-prem costs starting day one" are wrong; there's an overlap period where you're paying for both.
Retraining and tooling costs round out the list. Engineers comfortable managing on-premise infrastructure or one cloud provider need time to get productive with new tooling, whether that's a different provider's console, new CI/CD pipelines, or new monitoring stacks. That ramp-up time has a real cost even though it rarely appears as a line item in a migration quote.
Budgeting realistically
The honest way to budget a migration is to price the assessment separately from the execution, since the assessment often reveals dependencies and data volumes that change the execution estimate significantly. Get quotes that explicitly call out re-architecture scope, egress cost estimates, and parallel-running duration, rather than a single bundled number. A team offering cloud and DevOps services should be able to walk through where your specific migration lands on the small-to-large spectrum before quoting a number, and should be transparent about whether they're recommending re-architecture because it fits your workload or because it's a bigger project. Cost profiles differ somewhat by destination too. AWS and Azure have more complex discount programs that can offset costs if negotiated well, while GCP applies sustained-use discounts automatically, which matters for how you model year-one spend.
