A migration quote is rarely one number. It is seven line items — assessment, dual-running, egress off your old provider, partner labor, tooling, training, and app changes — each scaling differently with size and strategy. This page itemizes the real spend, prices it by migration size and by 7-Rs strategy, separates one-time cost from the ongoing TCO it buys, and shows how the AWS Migration Acceleration Program (MAP) funds a large share so a qualifying customer migrates at little-to-no net cost. With a worked example.
The honest answer to "how much does it cost to migrate to AWS" spans two orders of magnitude — the real cost is a function of estate size, migration strategy, how much you re-architect, and whether AWS funds it. The useful answer is to decompose it into components you can actually estimate.
When a vendor quotes a migration as one number, they have already made assumptions you cannot see: which of the 7 Rs they will apply to each workload, how long they will dual-run, whether they are pricing the egress to pull data off your current provider, and whether they assume AWS funding offsets part of the bill. Two quotes that look 3× apart are often pricing two genuinely different projects.
A more durable way to reason about it: total migration cost = (one-time project cost) − (AWS MAP funding) + (the new steady-state AWS run-rate). The first term is what most people mean by "migration cost." The second is the lever this page spends the most time on, because for qualifying migrations it is the difference between a six-figure invoice and a net cost near zero. The third is your ongoing bill — which the migration should land below what you pay today, once optimized. The seven components below are the line items inside that one-time project cost: knowing which are unavoidable (labor, dual-running) and which are workload-specific (heterogeneous DB conversions, deep refactors) lets you challenge a quote intelligently rather than accept or reject it whole.
Every migration invoice — a partner statement of work or your own internal-cost tally — reduces to these seven buckets, and pricing them separately is how you find where the money actually goes. Two dominate almost every project — partner/labor and dual-running; the rest are real but smaller. The order below roughly follows when the spend lands across the timeline.
What it is: inventorying every server, database, dependency, and data flow; building a TCO model; choosing the 7-Rs disposition per workload; producing a migration plan and wave schedule. Tools: AWS Application Discovery Service, Migration Evaluator (formerly TSO Logic), Migration Hub.
Typical cost: $10K–$60K as a standalone engagement for a mid-size estate, or a few days of effort for a small one. The lever: under MAP the Assess phase is frequently AWS-funded or free — the most reliable place MAP shows up first, because AWS wants to de-risk its own funding decision.
What it is: the overlap window where you pay for BOTH your old environment and the new AWS environment at once, because you cannot cut over instantly — you replicate, run in parallel, validate, then decommission the source. This is pure duplicated run-rate and the most underestimated line item.
Typical cost: 1–6 months of your current bill, paid twice — spend $20K/month and dual-run for three months and that is ~$60K of overlap on top of everything else. Control it with automated replication (AWS MGN keeps source and target continuously synced so the final cutover is minutes, not weeks) and decommissioning each source workload the moment its wave is validated.
What it is: the cost to pull data OUT of your current cloud. AWS does not charge for ingest — inbound transfer to AWS is free and AWS offers credits to offset migration data-transfer. The charge comes from the provider you are leaving: most clouds bill egress at roughly $0.08–$0.12/GB, so moving 50 TB out can cost $4K–$6K in egress alone, paid to the incumbent.
Typical cost: near-zero for small datasets up to tens of thousands for data-heavy estates (analytics warehouses, media libraries, large object stores). Control it with AWS DataSync for online transfer over Direct Connect/VPN, or AWS Snow Family for petabyte-scale offline transfer when egress or bandwidth make the network path uneconomic.
What it is: the people doing the work — an AWS partner's migration team, contractors, or your own engineers' loaded time pulled off the roadmap. The largest single line item on most projects, covering landing-zone build-out, the actual moves, database conversions, testing, and cutover runbooks.
Typical cost: the bulk of any six-figure migration — for a partner-led mid-size move, labor is commonly $80K–$300K of the gross. The lever: this is the line MAP offsets most directly — the partner is paid through MAP funding rather than your budget, which is why a MAP-funded, partner-run migration can net out near $0 while still being fully staffed.
What it is: the software that does the moving. The core AWS tools are low- or no-cost: AWS Application Migration Service (MGN) is free for the rehost itself (you pay only for the target EC2 you spin up); AWS Database Migration Service (DMS) is billed only for the small replication instance; the Schema Conversion Tool (SCT) is free. Third-party platforms can add license cost.
Typical cost: usually the smallest bucket — often under $5K–$15K, since AWS deliberately makes the migration tools cheap to remove a barrier to entry. The hidden cost is not license fees but the engineering time to operate the tools, which lands in the labor bucket.
What it is: getting your team operational on AWS — IAM, VPC networking, the managed services you are landing on, CloudWatch observability, and the operational runbooks. Under-investing here is why some migrations succeed technically but the bill creeps up afterward: an untrained team over-provisions and never right-sizes.
Typical cost: $5K–$40K by team size and depth. MAP engagements frequently bundle enablement and AWS provides training credits, so this is often partially funded rather than a separate cash line.
What it is: code and architecture changes to make an application run well on AWS — almost none for a pure rehost, some for a replatform (swap self-managed databases for RDS/Aurora, containerize for ECS/EKS), a lot for a refactor (decompose a monolith, move to Lambda, adopt managed queues and event buses). The most variable line item, and the one that turns a cheap migration into an expensive one.
Typical cost: ~$0 for rehost; tens of thousands for replatform; $100K–$1M+ for deep refactors of substantial applications. The judgment call: refactor only the workloads whose ongoing-cost or velocity savings justify the engineering; everything else rehosts now and refactors later, if ever.
On a typical partner-led mid-size migration: roughly 50–65% labor, 15–25% dual-running, 5–10% application changes, the rest across assessment, egress, tooling, and training. The two big buckets are exactly what MAP funding and a tight cutover plan attack hardest.
Estate size is the first-order driver of gross cost. These are representative 2026 ranges for the one-time project cost (before MAP funding), assuming a mostly rehost/replatform approach with selective refactoring.
Treat these as bands, not quotes — the same server count can cost wildly different amounts depending on database heterogeneity and how much you re-architect. What matters is the order of magnitude and the shape of the spend, which the table makes concrete.
| Estate size | Profile | Typical timeline | Gross one-time cost | Dominant line items | MAP fit |
|---|---|---|---|---|---|
| Small | Single app, 1–10 servers, one database (e.g. a Heroku or DigitalOcean app) | 2–6 weeks | $15K–$60K | Labor, short dual-run | Below MAP minimums — referral |
| Mid-size | 10–100 servers, several databases, multiple apps | 2–6 months | $120K–$400K | Labor, dual-running, some refactor | Strong fit if spend is meaningful |
| Enterprise | 100s–1,000s of servers, mixed on-prem + cloud, heterogeneous DBs | 6–24+ months | $500K–$5M+ | Labor, refactor, parallel waves | Core MAP territory |
After size, strategy is the largest cost lever — and the one you control most directly. The 7 Rs (Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor) sit on a clear cost gradient: the less you change, the cheaper and faster the migration; the more you re-architect, the higher the one-time cost but the lower the ongoing TCO.
The strategic mistake is treating it as one decision for the whole estate. Mature migrations assign a disposition per workload: retire the dead, retain the few that should not move yet, rehost the bulk to get off the old provider fast, and refactor only the handful where ongoing savings or release velocity clearly pay back the engineering. MGN makes rehost almost mechanical and DMS + SCT make the database moves tractable; the refactor decisions are where senior judgment earns its keep.
Move servers as-is onto EC2 using AWS Application Migration Service (MGN), which installs a replication agent, keeps the source continuously synced, and lets you cut over in a short window. Almost no application change; cost is dominated by labor and a short dual-run. This is where most estates start — it gets you off the old provider, and stops the old bill, fastest.
Rehost, but swap a few components for managed AWS services during the move: self-managed PostgreSQL → Amazon RDS or Aurora, a VM-hosted app → containers on ECS/EKS, a cron box → EventBridge + Lambda. More application-change cost than rehost, but you capture managed-service operational savings immediately. The common sweet spot for mid-size migrations.
Re-architect onto cloud-native primitives: decompose a monolith into services, move compute to Lambda or Fargate, adopt Aurora Serverless, SQS/SNS/EventBridge, and managed data services. This is months of engineering and the highest one-time cost — but it produces the lowest ongoing run-rate and the fastest future delivery. Reserve it for the workloads where that payback is real.
Rehost to escape the old provider and stop the old bill. Replatform where a managed service removes ops toil for little extra effort. Refactor only the workloads whose TCO or velocity gains clearly exceed the engineering cost. A blanket "refactor everything" plan is the most common way budgets quadruple.
The one-time migration cost is only half the picture. What justifies it is the total cost of ownership (TCO) after the move — and a well-executed AWS migration typically lands the steady-state bill meaningfully below the prior stack.
TCO is more than the monthly cloud invoice. It includes the hardware refresh you no longer buy, the data-center and colocation costs you shed, the over-provisioned headroom you stop paying for, and the operational hours your team gets back when managed services replace self-managed infrastructure.
The post-migration savings levers, concretely: right-sizing (most pre-migration estates are 20–40% over-provisioned); elasticity (auto-scaling and serverless mean you pay for use, not peak); Savings Plans and Reserved Instances (committing to steady-state usage cuts compute 30–60% versus on-demand); managed-service consolidation (RDS/Aurora, ElastiCache, S3 lifecycle policies replace self-managed equivalents and their labor); and license elimination on heterogeneous database moves (Oracle/SQL Server → Aurora PostgreSQL via SCT+DMS removes commercial-database license fees).
The honest caveat: these savings are not automatic. A lift-and-shift with no follow-up right-sizing can cost more month-one than the source, because you replicated the over-provisioning. They show up when you right-size, adopt Savings Plans, and refactor the worst offenders — precisely the optimization work an AWS partner includes in a MAP engagement, which is why the migration and the post-migration cost-optimization are best run by the same team.
Think of it as a payback period. A mid-size migration that lands the run-rate 20–40% lower typically pays back its one-time spend within months — and when MAP funds most of that one-time cost, the payback collapses toward immediate.
The AWS Migration Acceleration Program (MAP) changes the entire cost conversation. For qualifying migrations AWS funds a large share of the cost, so the customer's net cash outlay can approach zero — in exchange for committing to run on AWS afterward.
MAP runs in three phases — Assess, Mobilize, and Migrate & Modernize — and funding scales across them, landing largest at the production cutover. The partner is paid through MAP, which is why a MAP-funded engagement can be fully staffed without the cost flowing to your budget. The phase mechanics are below.
The honest framing — and this matters, because overclaiming here is how trust is lost: MAP is for qualifying migrations, meaning meaningful size with a credible commitment to ongoing AWS spend after the move. The funding is, in effect, prepaid against your future bill, and the larger the post-migration run-rate the larger the funding AWS underwrites. Small migrations below the threshold do not get MAP — there CloudRoute simply routes you to a vetted partner for a clean, cheap cutover.
Where it applies, the funding offsets the two largest line items — partner/labor and assessment — and frequently bundles enablement and optimization, which is how a six-figure gross cost nets out near zero. CloudRoute routes you to a MAP-eligible partner (Advanced or Premier tier, migration track record) who scopes the funding and files the MAP record, so you never have to learn the program mechanics.
Numbers make the lever concrete — a representative mid-size migration, a multi-app SaaS estate moving off another cloud, costed two ways: self-funded, and MAP-funded partner-run.
Assume ~40 servers, three databases (one a heterogeneous Oracle → Aurora PostgreSQL conversion), a ~30 TB data estate to transfer, a current run-rate of $22K/month, and a mostly-replatform strategy with one refactored workload — a three-month project with a two-month dual-run overlap.
Assessment $30K · partner/labor $180K (landing zone, the moves, the Oracle→Aurora conversion via SCT+DMS, cutover runbooks) · dual-running ~$44K (two months at $22K in parallel) · egress ~$3K (30 TB at ~$0.09/GB) · tooling $8K · training $15K · one refactor $60K. Gross one-time cost ≈ $340K.
Assess is AWS-funded ($0 to the customer); partner/labor is largely paid through MAP (the partner is funded by AWS, not your budget); Mobilize + Migrate funding offsets a large share of the rest, scaled to the committed post-migration run-rate; dual-running and egress are partly absorbed by AWS migration credits. Net cash cost: a low fraction of the $340K — frequently approaching $0 for a migration of this size with a committed ongoing spend.
On the ongoing side, post-migration right-sizing, Savings Plans, and the one refactor bring the run-rate from $22K/month to roughly $14K–$16K/month — a 25–35% cut. The customer avoids most of the one-time cost and lowers the recurring bill that funds it.
Same migration. Self-funded: ~$340K out of pocket. MAP-funded and partner-run: net cash cost a small fraction of that — often near $0 — plus a run-rate ~25–35% lower. The difference is entirely the funding mechanism and who runs the project — exactly what CloudRoute routes you into.
The two funding paths side by side for the same mid-size migration. Strategy changes the gross number; MAP changes what you actually pay.
| Cost line | Self-funded (no MAP) | MAP-funded, partner-run (qualifying) |
|---|---|---|
| Assessment / discovery | $10K–$60K out of pocket | Often AWS-funded → ~$0 |
| Partner / labor | Full cost on your budget | Largely paid through MAP |
| Dual-running overlap | Full duplicated run-rate | Partly offset by AWS credits |
| Egress off old provider | Paid to incumbent ($0.08–$0.12/GB) | Partly offset by credits |
| Tooling | MGN/DMS/SCT cheap; 3rd-party adds license | Same — already low |
| Training / enablement | $5K–$40K out of pocket | Often bundled + AWS credits |
| Net cash cost to you | Full gross one-time cost | A small fraction — near $0 |
| Ongoing run-rate (optimized) | 20–40% lower than old stack | 20–40% lower than old stack |
Situation: Outgrowing their current cloud on cost and capability. A self-funded quote came back at ~$360K one-time — labor, a hard SQL Server → Aurora PostgreSQL conversion, and a long projected dual-run — which the board would not approve while extending runway. They also feared an unmanaged cutover taking down production during their busiest quarter.
What CloudRoute did: Routed within 24 hours to an Advanced-tier AWS partner with a SQL-Server-to-Aurora and MAP track record. The partner ran the AWS-funded Assess phase (free), filed the MAP record scoped to the committed post-migration run-rate, built the landing zone in Mobilize, and executed a wave-based cutover on AWS MGN with a minutes-long switchover per wave. SCT + DMS handled the database conversion with a tested rollback per wave.
Outcome: MAP funding offset the assessment entirely and the large majority of labor; net cash cost to the customer was a small fraction of the $360K self-funded quote — effectively a funded migration. Dual-running was held to ~6 weeks. Post-migration right-sizing + Savings Plans brought the run-rate from ~$24K to ~$16K/month (~33% lower). CloudRoute's commission was paid by the partner from AWS engagement funding — the customer paid CloudRoute $0.
engagement: ~4 months · self-funded quote avoided: ~$360K · net migration cost: near $0 · run-rate: ~33% lower · routing cost: $0
CloudRoute routes you to a vetted, MAP-eligible AWS partner who runs the migration and files the funding. For qualifying migrations your net cash cost approaches $0, and you pay CloudRoute nothing.