This is the cornerstone guide to migrating to AWS in 2026: the 7 Rs framework for deciding what to do with each workload, the three-phase MAP model AWS runs the migration through, the actual tooling (MGN, DMS, SCT, Migration Hub), realistic timelines and cost — and how the AWS Migration Acceleration Program funds the work so qualifying migrations land at little-to-no cost. CloudRoute routes you to a vetted partner who runs it.
An AWS migration is the deliberate move of your applications, data, and supporting infrastructure from a source environment onto AWS — done as a planned program, not an ad-hoc rebuild. The hard part is rarely the compute; it's the data, the dependencies, and the cutover.
Most teams arrive here for one of a few reasons: a Heroku or DigitalOcean bill that no longer scales economically, an Azure or GCP commitment expiring, an aging on-prem datacenter or a colo lease coming due, an Oracle licensing renewal that suddenly costs more than the migration would, or a board mandate to consolidate on a single cloud. The trigger is usually commercial; the work is always technical.
A real migration touches five layers. Compute — where your app servers, containers, and functions run. Data — databases, object storage, file shares, and the replication that keeps them in sync until cutover. Networking — VPC design, DNS, load balancers, VPN or Direct Connect back to anything you keep. Identity and security — IAM, secrets, encryption, and the guardrails that stop the new account from becoming a liability. And operations — observability, CI/CD, backups, and the runbook the on-call team uses at 2am.
The single biggest predictor of a smooth migration is how well you understand the existing system before you touch it. A discovery pass — what runs where, what talks to what, how much data moves, what the real RPO/RTO requirements are — is what separates a 10-week rehost from a 9-month archaeology project. AWS Application Discovery Service and Migration Hub exist precisely to make that inventory honest.
This guide is the map for the whole journey. The 7 Rs tell you what to do with each workload. The MAP model tells you how AWS structures and funds the program. The tooling section names the services that do the actual moving. Then we cover timeline, cost, source platforms, risk, and how to start — with links down into the focused pages for each.
You do not migrate "the system." You migrate a portfolio of workloads, and each one gets a disposition. The 7 Rs are AWS's canonical framework for that decision. Run every application through them during Assess, and you have a migration plan.
The 7 Rs are not a ladder you climb — they are seven distinct dispositions, and a good plan mixes them. The instinct of mature teams is to rehost or replatform the bulk to get off the old bill fast, then refactor the few workloads where the cloud-native payoff is real. Refactoring everything up front is the most common way migrations blow their timeline and budget.
Discovery almost always finds workloads nobody uses: a reporting service replaced two years ago, a staging environment for a dead product, a cron job whose output goes nowhere. You don't migrate these — you decommission them. It's common to retire 10–20% of a server estate, and every retired workload is migration cost you never pay.
Some workloads aren't ready or aren't worth moving yet: a mainframe mid-amortization, an app with a hard data-residency constraint, or something pending its own replacement. You explicitly retain these and plan the hybrid connectivity (VPN or Direct Connect) to bridge them. Retain is a decision, not a default — undocumented "we'll deal with it later" workloads are how migrations stall.
Move the workload to AWS with minimal change, typically with AWS Application Migration Service (MGN) replicating the whole server into EC2. This is the fastest disposition and the lowest-risk for getting off the source platform. You don't get cloud-native benefits immediately, but you stop the bleeding and buy time to optimize afterward. Most migrations are majority-rehost by server count.
For VMware estates, relocate moves vSphere VMs to VMware Cloud on AWS without converting them — same hypervisor, now on AWS hardware. For containers, it's lifting a cluster to EKS with minimal manifest changes. Relocate is rehost's cousin for environments that are already virtualized or containerized and just need to change address.
Sometimes the right move is to stop running the software at all: replace a self-hosted CRM, ticketing system, or analytics stack with a SaaS equivalent (often bought through AWS Marketplace). You migrate the data out and retire the servers. Repurchase trades operational burden for a subscription — usually correct for commodity, non-differentiating workloads.
Move to AWS while swapping the undifferentiated heavy lifting for a managed service: self-managed Postgres becomes Amazon RDS or Aurora; a hand-rolled queue becomes SQS; a container on a VM becomes ECS Fargate or App Runner. The app code barely changes, but you shed patching, backups, and failover. Replatform is the sweet spot for databases and stateful middleware — the operational savings are immediate and the risk is contained.
Re-architect the workload to take real advantage of AWS — decompose a monolith into services on Lambda and EKS, move to event-driven patterns, adopt purpose-built databases. Refactor delivers the biggest long-term payoff (scale, cost, velocity) and carries the biggest cost and risk. The discipline is to refactor selectively, post-migration, on the workloads where the business case is clear — not as a precondition to getting off the old platform.
Rehost or replatform the portfolio to exit the source platform on a predictable timeline, then refactor the 10–20% of workloads where cloud-native economics justify it. Trying to refactor everything during the migration is the number-one cause of blown budgets and slipped cutover dates. See lift-and-shift vs replatform for the per-workload decision in depth.
The Migration Acceleration Program (MAP) is the methodology and funding vehicle AWS uses to run partner-led migrations. It breaks the program into three phases, each with its own deliverables, gate, and funding mechanics. Understanding the phases tells you what happens when — and where the money enters.
MAP is not a tool; it's a structured program AWS partners deliver against, with funding attached at each phase. A vetted partner files the MAP engagement through the AWS Partner Network, runs the phases, and draws the AWS funding — which is why a qualifying migration costs you little-to-nothing. The three phases run in order, with a go/no-go gate between each.
A 2–4 week discovery and business-case exercise. The partner inventories your estate (often with Application Discovery Service and Migration Hub), builds a total-cost-of-ownership comparison of staying put vs running on AWS, sizes the migration, and assigns a 7 Rs disposition to every workload. The deliverable is a directional TCO, a target-state architecture sketch, and a migration plan. AWS frequently funds the Assess phase entirely, so this stage is typically free to you. See aws migration assessment for what a real Assess engagement produces.
A 4–8 week phase that builds the operational foundation and de-risks the plan with a pilot. The partner stands up the AWS landing zone (multi-account structure, networking, security guardrails, logging, IAM), sets up the migration tooling, and migrates a small, representative set of workloads end-to-end to prove the runbook. AWS provides Mobilize-phase funding — commonly credits in the range of a quarter of the projected migration cost — to offset the build. The landing zone you stand up here is the foundation everything else lands on; get it right and the rest is repeatable.
The production phase: migrate the bulk of the portfolio in waves, cut over, validate, decommission the source, and modernize selectively. This is where most of the calendar lives — anywhere from 8 weeks to 9+ months depending on estate size and how much refactoring is in scope. AWS funding at this phase is larger (commonly scaling toward half of eligible migration cost), credited against your AWS bill as workloads land. By the end you're running on AWS, the old environment is off, and the post-migration spend commitment that justified the MAP funding kicks in.
This is the part most "how to migrate to AWS" guides skip. AWS has a direct commercial incentive to move your workloads onto its platform, and it puts real money behind that through MAP. Here's how the economics actually work — and where the honest caveats are.
The mechanism: AWS wants your long-term consumption, so it co-invests in the cost of getting you there. Through MAP, AWS provides credits scaled to the size of the migration — funding the Assess phase, offsetting the Mobilize build, and crediting a meaningful share of the Migrate-phase cost. The partner doing the work is compensated through MAP funding as well. Stack those together and a qualifying migration can land at little-to-no net cost to you.
The honest framing — because overclaiming here destroys trust: MAP funding scales with migration size and is tied to a post-migration AWS-spend commitment. It's designed for migrations of real substance, not a single small app. If your migration clears the threshold, the funding genuinely makes it low-cost or effectively free to execute. If it doesn't, MAP isn't the right vehicle — but a vetted partner referral still de-risks the cutover, and smaller AWS credit programs may apply instead.
MAP also ties directly into the broader AWS credit picture. The same partner-attested, AWS-funded mechanics that drive credit programs drive MAP — they're two faces of the same incentive. If your situation is part-migration, part-greenfield, the credit and migration funding can be sequenced together. See the credits cluster for the funding mechanics in depth: the $100K AWS credits guide and how AWS POC funding works explain the partner-filed model that MAP shares.
CloudRoute's role is the routing: we connect you to a partner who both runs the migration and files the MAP engagement, so the funding actually gets claimed. Founders routinely leave AWS funding on the table simply because nobody filed for it — a partner who knows the program closes that gap. See the AWS Migration Acceleration Program page and AWS migration funding for the full mechanics.
For a migration that qualifies for MAP, AWS-funded credits plus partner compensation can cover effectively all of the migration cost — you commit to running the resulting workloads on AWS afterward. For migrations below the MAP threshold, treat CloudRoute as a vetted-partner referral that de-risks the cutover, not a free-migration guarantee. We tell you which bucket you're in before you commit anything.
A migration is executed with a specific set of AWS services, each owning a slice of the move. You don't need to operate these yourself when a partner runs the migration — but knowing what does what makes you a far better-informed buyer.
The toolchain splits cleanly along the layers from Section I: discovery, server/compute migration, database migration, and data transfer — coordinated by a control plane.
The pattern in practice: Discovery Service builds the inventory, Migration Hub tracks the program, MGN handles the rehosts, DMS + SCT handle the databases, and DataSync moves the bulk data. A partner orchestrates all of it against the runbook proven during Mobilize — so the production waves are repetition, not improvisation.
The right target architecture depends heavily on where you're starting. Each source platform has well-trodden mappings onto AWS services. Here are the common ones, with links to the dedicated guide for each.
Across all of these, the same shape holds: compute maps to a container or serverless service, the database replatforms onto RDS or Aurora, and object/file storage moves to S3. The detail — and the difficulty — is almost always in the data layer.
Heroku dynos map to ECS Fargate or App Runner; Heroku Postgres replatforms onto RDS or Aurora; add-ons map to native AWS services. DigitalOcean Droplets and App Platform follow the same path. Vercel front-ends often stay on Vercel while the backend and data move to AWS, or move wholesale to Amplify/CloudFront + Lambda. These are typically the fastest migrations — small estates, clean boundaries. See heroku to aws.
GCP: GKE→EKS, Cloud SQL→RDS, BigQuery→Redshift or Athena, GCS→S3. Azure: AKS→EKS, Azure SQL→RDS, Functions→Lambda, App Service→App Runner, Blob Storage→S3. Cloud-to-cloud moves are mostly replatform exercises — the concepts map almost one-to-one, and egress cost plus data-sync time are the main planning variables.
Physical servers rehost via MGN into EC2. VMware estates can relocate wholesale to VMware Cloud on AWS, or run on AWS Outposts for workloads that must stay physically local. On-prem migrations lean hardest on discovery (the inventory is rarely accurate) and on hybrid networking via Direct Connect during the transition. See on-premise to aws.
Oracle→Aurora PostgreSQL (via SCT + DMS) is one of the highest-ROI moves there is — Aurora's performance with none of Oracle's license cost — but it's also the most schema-conversion-heavy. SQL Server can rehost, replatform to RDS, or convert to Aurora. SAP runs as a certified workload on AWS with its own reference architectures. These are the migrations where partner expertise pays for itself many times over. See oracle to aurora and sql server to aws.
Every migration is different, but the ranges are knowable. Here's what to actually expect on calendar and budget — before MAP funding offsets the cost.
Timeline is driven by estate size, data volume, and how much refactoring is in scope — not by the cloud itself. A clean PaaS migration (a handful of services, one or two databases) often completes inside the MAP Assess + Mobilize window. A mid-size estate (50–200 servers, several databases) is typically a 4–8 month program. A large or heavily regulated enterprise estate, or one with deep heterogeneous-database conversion, runs 9–18 months and several waves.
Cost has two components people conflate: the one-time migration cost (the project — discovery, landing zone, execution, the partner's time) and the ongoing AWS run-rate after you land. MAP is designed to offset the first; the second is what your TCO analysis in Assess is really about, and it's usually lower than the source platform once rightsizing and reserved/savings-plan pricing are applied. See aws migration cost and aws migration timeline for the detailed models.
The key planning numbers: budget 2–4 weeks for Assess, 4–8 weeks for Mobilize, and size Migrate by waves of workloads rather than as one monolith. Downtime per workload at cutover, with MGN and DMS continuous replication, is typically minutes-to-hours — not days — because the heavy data movement happens live before the switch.
A credible migration plan names its failure modes up front and has an answer for each. These are the risks that actually bite, and how a competent partner contains them.
Run every workload in your estate through this table during the Assess phase. The output is your migration plan: a disposition, an effort level, and a tool for each application.
| R | What it means | Effort | Risk | AWS tooling | Pick it when… |
|---|---|---|---|---|---|
| Retire | Decommission — nobody uses it | None | None | — | Discovery shows it's dead or redundant (often 10–20% of an estate) |
| Retain | Leave on the source, bridge with hybrid networking | Low | Low | Direct Connect / VPN | Not ready, data-residency-bound, or pending its own replacement |
| Rehost | Lift-and-shift, minimal change | Low | Low | MGN → EC2 | You need off the source platform fast; optimize later |
| Relocate | Move the VM/container layer wholesale | Low | Low | VMware Cloud on AWS / EKS | Already virtualized or containerized; just change address |
| Repurchase | Drop the app, buy a SaaS equivalent | Medium | Medium | AWS Marketplace + data export | Commodity, non-differentiating workload (CRM, ticketing) |
| Replatform | Lift-tinker-shift onto managed services | Medium | Medium | RDS / Aurora / ECS / App Runner | You want to shed ops (patching, backups) without rewriting |
| Refactor | Re-architect for cloud-native | High | High | Lambda / EKS / purpose-built DBs | Clear business case for scale/cost/velocity — do it selectively, post-migration |
Situation: Heroku economics had stopped scaling and the datacenter lease forced a decision. They wanted one cloud, lower run-rate, and SOC 2-grade controls — but the platform team was fully allocated to product and couldn't run a migration of this size without stalling the roadmap. They also didn't know AWS would fund the move.
What CloudRoute did: Routed within 24 hours to an Advanced-tier AWS partner with Heroku + data-center migration track record. Partner ran a free MAP Assess (3 weeks): 7 Rs disposition across ~120 workloads — retire 18, rehost the datacenter servers via MGN, replatform the Heroku app to ECS Fargate, Heroku Postgres → Aurora PostgreSQL via DMS. Mobilize (6 weeks) stood up the landing zone + pilot. Migrate ran in four waves over ~5 months. Partner filed the MAP engagement so AWS funding offset the work.
Outcome: Cutover downtime per wave: 20–90 minutes (DMS continuous replication carried the data ahead of each switch). Steady-state AWS run-rate landed ~38% below the combined Heroku + colo spend after rightsizing and a savings plan. MAP funding plus partner compensation covered effectively all of the one-time migration cost; the customer's net outlay was near $0, against a post-migration AWS-spend commitment. Total program: ~8 months, founder/platform-lead time ≈ a few hours a week.
estate: ~120 workloads · program: ~8 months · run-rate cut: ~38% · migration cost to customer: ≈$0 (MAP-funded)
CloudRoute routes you to a vetted AWS partner who runs the migration end to end and files the MAP funding. Qualifying migrations land at little-to-no cost. No discovery theater, no procurement maze.