AWS to Azure Migration Cost Benchmarks: What the Numbers Actually Show

Most AWS-to-Azure migration budgets are wrong before the project starts. Not because the engineers are bad at their jobs. They are wrong because the cost model for a cloud migration is structurally different from the cost model for a capital project, and almost every benchmark circulating in the market was produced by vendors with a direct financial interest in your migration proceeding quickly.

We have run or reviewed enough of these migrations to have a firm view on what they actually cost, where the surprises originate, and which benchmark inputs actually predict outcomes. The short version: a mid-market lift-and-shift from AWS to Azure typically costs 1.2x to 2.4x the initial estimate. The gap lands in labor, not infrastructure. Organizations that close the gap share three specific practices in common, and they all involve doing work before the migration begins rather than during it.

What the industry benchmarks actually say

The most-cited migration cost data comes from Gartner and IDC. Gartner has consistently found that organizations underestimate cloud migration costs by 30 to 40 percent on average, with underestimation concentrated in post-migration optimization and workforce re-skilling. IDC's migration benchmark work, which Forrester has corroborated in separate survey data, puts average migration project overruns at 25 to 50 percent of initial budget for projects exceeding 200 workloads.

The numbers from our own work are slightly worse for AWS-to-Azure specifically. We see average labor overruns of 35 to 55 percent, driven primarily by three factors: identity and access management re-mapping between AWS IAM and Azure Entra ID (formerly Active Directory), networking model differences, and data transfer costs that almost no initial estimate accounts for correctly. Each of those three deserves its own treatment.

Where the money actually goes

A migration budget has three cost buckets: infrastructure, labor, and opportunity cost.

Infrastructure is the smallest surprise. Azure's on-demand rates are broadly comparable to AWS for equivalent compute classes. A D4s v5 (4 vCPU, 16 GB RAM) in East US runs approximately $0.192 per hour at on-demand pricing. An AWS r6i.xlarge (4 vCPU, 32 GB RAM) in us-east-1 runs $0.252 per hour. The headline rate comparison is close enough that it rarely explains overruns. What does explain them is the commitment structure: engineers fluent in AWS Savings Plans often underestimate how long it takes to build a sound Azure reservation strategy. Organizations pay on-demand rates for 3 to 6 months longer than projected while building that posture, and that delta is real cash out the door even though it appears post-migration.

Labor is where budgets come apart. For a 300-workload migration, we typically see 2,200 to 3,500 engineering hours consumed outside the initial estimate. The sources break down roughly as follows: IAM re-mapping and Entra ID integration accounts for 15 to 20 percent of total labor overrun; network topology re-design accounts for 10 to 15 percent; storage class migration and data validation accounts for 8 to 12 percent; and tooling replacement for AWS-native services with no direct Azure equivalent accounts for 10 to 25 percent depending on how deeply the source environment uses AWS managed services.

Opportunity cost is the number nobody writes down. A 300-workload migration run by an eight-person team consumes that team almost entirely for 6 to 9 months. The engineering backlog accrues. Feature velocity drops. Engineering organizations consistently undercount this at roughly 40 percent of its true value when preparing migration business cases, which means the approved budget looks better than the business case actually supports.

The identity tax

IAM re-mapping deserves its own section. It is the most consistent source of schedule overruns we observe across AWS-to-Azure work, and it is the one most frequently treated as an implementation detail rather than a project workstream.

AWS IAM and Azure Entra ID share a conceptual vocabulary but are structurally different products. AWS IAM is resource-centric: permissions attach to resources or roles, and the principal-to-resource path is explicit. Azure Entra ID is identity-centric: permissions flow from group memberships and role assignments in a directory model deeply integrated with Microsoft 365. Organizations that have accumulated 5 to 15 years of AWS IAM policy debt should budget 400 to 600 additional hours per 100 workloads to audit, rationalize, and re-map that policy estate. We have not encountered a migration of meaningful size where that investment proved unnecessary.

The Microsoft documentation on Azure role-based access control is comprehensive, but it describes the destination model rather than the translation path. The translation path requires human judgment. AWS allow-with-deny-exception patterns do not have clean equivalents in Azure's RBAC model. Automated tooling handles the straightforward cases; the complex cases, which are typically the security-sensitive cases, require senior security engineering capacity. Any migration plan that does not assign senior engineers exclusively to IAM rationalization is accepting the overrun before it happens.

The networking gap

The second structural cost driver is network topology. AWS VPCs are logically isolated networks with explicit route tables, stateful security groups, and stateless network ACLs. Azure Virtual Networks use a different model: Network Security Groups are stateful and work similarly to AWS security groups, but the subnet model has different defaults, the peering model across subscriptions differs from AWS Transit Gateway, and default deny behavior at the subnet boundary is configured differently.

For organizations with fewer than 50 workloads and simple network topologies, this is a manageable one-time re-design cost. Budget 100 to 200 hours for a senior network engineer and move on. For organizations with complex multi-VPC topologies, hub-spoke architectures, or AWS Direct Connect dependencies, the re-design and validation work can run to 500 to 900 hours before the first workload moves. We have seen organizations discover, mid-migration, that their AWS architecture depended on capabilities with no near-equivalent on Azure, adding 60 to 90 days to the schedule at full team cost.

The Azure equivalent of AWS Direct Connect is Azure ExpressRoute. The commercial and configuration model differs enough that organizations with existing Direct Connect circuits should treat connectivity transition as a separate workstream with its own timeline. Treating it as a side task is how migrations stall at 70 percent completion while the networking team scrambles.

The egress line item most estimates omit

Almost every AWS-to-Azure migration budget underweights data transfer costs during the migration window.

AWS charges $0.09 per GB for outbound data transfer to the internet from us-east-1 for the first 10 TB per month. Azure charges comparable rates for inbound from the internet. But the migration-period transfer costs, moving actual workload data from AWS storage to Azure during the transition window, are distinct from steady-state egress and are routinely omitted from initial estimates.

For a 300-workload estate with 50 TB of persistent data, migration-period egress alone runs $4,500 to $9,000 depending on transfer method and whether AWS PrivateLink is used to reduce per-GB cost. AWS Snowball and Azure Data Box options become cost-competitive for data estates above 100 TB. Below that threshold the egress costs are a budget line item rather than a budget driver, but teams consistently forget to include them, and omitted line items accumulate.

Managed services: the true cost driver

The counter-take we offer is this: the real cost of an AWS-to-Azure migration is not infrastructure or even labor in the abstract. It is the depth of AWS managed-service dependency in the source environment.

Conventional pricing comparisons treat AWS and Azure as equivalent for equivalent compute and storage, which is broadly true. That framing breaks down for managed services. Organizations that have built meaningfully on Amazon Kinesis, Amazon SQS, AWS Step Functions, Amazon EventBridge, or Amazon ElastiCache will find that Azure equivalents exist but are not drop-in replacements. Replacing Kinesis with Azure Event Hubs is not a configuration change; it is a re-architecture. The API surface, partition model, consumer group semantics, and client library ecosystem differ enough that application code requires meaningful rework.

Our internal rule: for every AWS managed service an architecture depends on meaningfully, add 80 to 150 engineering hours for evaluation, re-architecture, and validation before counting that workload as migrated. An application with five significant AWS managed-service dependencies is not a lift-and-shift candidate regardless of what a vendor assessment says. Treating it as one is where the 2.4x overrun range comes from.

What to do before you sign anything

If your organization is seriously evaluating an AWS-to-Azure migration, the following steps are non-negotiable preparation before any contract is signed:

1. Run a workload classification audit. Categorize each workload as lift-and-shift eligible, re-platform required, or AWS-managed-service dependent. The last category is your true cost driver. Quantify it before signing.
2. Build the IAM audit into the project plan as a named workstream. It will not happen by accident. Assign a senior security engineer 4 weeks before migration begins, with no competing priorities.
3. Price the managed-service gaps explicitly. For each AWS managed service your workloads depend on, document the Azure equivalent, the API surface differences, and the re-architecture effort. If that list has more than 8 services, get a second opinion on the migration timeline.
4. Account for egress and transfer costs before the budget is approved. Calculate your data estate size, apply the appropriate transfer method cost, and put the number in the budget now rather than discovering it at go-live.
5. Model the commitment ramp explicitly. Assume 3 to 6 months of Azure on-demand pricing before your reservation posture stabilizes. That delta versus your steady-state target is a migration cost, even if it appears post-migration in the infrastructure budget.
6. Negotiate the timeline before the scope. The single most reliable predictor of migration overruns is a compressed timeline that prevents IAM and networking work from being sequenced correctly. A well-sequenced 12-month migration almost always costs less than a compressed 6-month one, even before accounting for quality.