Migrating to AWS is rarely a tooling problem — it's a sequencing, risk, and funding problem. This page walks the whole journey end to end: the decision (should you migrate, when, why), the discovery → assess → landing zone → pilot → migrate → optimize sequence, rehost vs replatform, honest timelines, and the AWS Migration Acceleration Program (MAP) path that funds the work so a vetted partner can run your cutover at little-to-no cost.
Migration is expensive in attention even when it's cheap in dollars. Before the how, the honest question is whether the move clears the bar for your situation, and whether the timing is right. There are good reasons to migrate and good reasons to wait.
The strongest reasons to migrate are concrete and financial. A renewal cliff — a Heroku, on-prem VMware, or co-location contract that would lock you in for another term. An inverted cost curve: Heroku dynos and managed add-ons that run 3–5× the equivalent ECS Fargate + RDS footprint once you cross a few hundred dollars a month. A capability ceiling: you need a managed Kubernetes control plane, multi-region failover, a data lake, or Bedrock-class inference and your current platform doesn't offer it. A compliance trigger: a SOC 2, HIPAA, or PCI requirement that's far easier to satisfy on AWS's shared-responsibility model (dedicated networking, KMS, CloudTrail) than on a PaaS where you don't control the substrate.
The weaker reasons — worth interrogating — are "AWS is what real companies use" and "our investors expect it." Real pressures, but they don't by themselves justify a quarter of engineering distraction. If your app is small, your bill is under a few hundred dollars a month, and you have no compliance or capability gap, the rational move is often to wait: the migration is cheaper and lower-risk once the workload is large enough that MAP funds it and the savings pay back the disruption.
Timing matters as much as the decision. The best windows are before a renewal, before a funding round closes (so credits and savings land in next year's plan), and before — not during — a hypergrowth spike that would otherwise force you to scale the old platform first and migrate later under duress. The worst window is mid-incident or mid-launch: never run a cutover the same month you're shipping the thing your whole company is counting on.
One quieter reason has become decisive in 2026: AWS-native AI. If your roadmap includes generative-AI features, being on AWS puts Bedrock, model-level data isolation, and the Bedrock POC credit track one IAM role away rather than one more vendor and one more data-egress story. For AI-leaning teams that alone often tips the decision.
Migrate now if you have a renewal cliff, an inverted cost curve, a capability or compliance gap, or an AI roadmap — and the projected post-migration AWS spend is large enough to qualify for MAP (typically a meaningful monthly commitment). If none of those is true and your bill is small, waiting is the senior decision, not the move.
Plenty of clouds can run your containers. The reason this cluster is about AWS specifically is a combination of breadth, the maturity of the migration toolchain, and a funding mechanism that genuinely has no equal on the other major clouds at the time of writing.
On capability and tooling, AWS has the widest managed-service surface (Aurora and RDS across six engines, EKS/ECS for containers, Lambda and App Runner for serverless, S3 and the data-lake stack, Bedrock for inference) and the most paved migration path. Application Migration Service (MGN) does agent-based block-level rehost with cutover windows in minutes; Database Migration Service (DMS) plus the Schema Conversion Tool (SCT) handle homogeneous (Postgres→RDS) and heterogeneous (Oracle/SQL Server→Aurora PostgreSQL) moves with continuous replication; Migration Hub and Application Discovery Service inventory the portfolio; DataSync and Transfer Family move bulk data. None of it is experimental — it's the battle-tested layer you want under a production cutover.
The math-changer is the AWS Migration Acceleration Program — a three-phase funding structure (Assess, Mobilize, Migrate & Modernize) in which AWS underwrites the migration to consolidate your workload on AWS long term. AWS frequently funds the Assess phase outright, then credits a meaningful share of the Mobilize and Migrate costs, paid through the partner who executes the work. This applies to qualifying migrations (typically those with a real projected AWS spend post-migration), and the exact percentages are set per deal. That funding is why done-for-you is viable: on most platforms paying an agency to migrate you is pure cost, but on AWS the partner is largely paid by AWS through MAP — so a vetted partner runs the whole thing for a qualifying customer at little-to-no charge. MAP ties into the broader credits picture; see $100K AWS credits and how AWS POC funding works for how the credit layer stacks on top.
Almost every successful AWS migration follows the same six-phase arc, mapping cleanly onto AWS's own MAP phases. Knowing the shape tells you where you are, what's next, and where the risk concentrates (the pilot and the cutover, every time).
The most common failure mode is skipping straight to "let's move servers." Teams that do discover the dependencies they didn't map, the database that won't cut over cleanly, and the landing zone they have to retrofit under pressure. The phases exist to surface those before they become a 2 a.m. rollback.
Inventory everything — applications, servers, databases, data volumes, network dependencies, third-party integrations, runtime versions — using AWS Application Discovery Service (agent or agentless) feeding Migration Hub. Output: a dependency map and a per-application disposition (which of the 7 Rs each workload gets). This is where the surprises surface: the undocumented cron box, the database nobody owns.
Build the TCO and business case: current run-rate vs projected AWS run-rate, migration-effort estimate, and the funding ask. Output: a TCO model, a target-architecture sketch, a wave plan, and — critically — the MAP record the partner files with AWS, which confirms eligibility and sizes the funding. AWS commonly funds this phase outright.
Stand up the foundation before anything moves: multi-account structure (AWS Organizations + Control Tower), networking (VPCs, subnets, transit/peering), identity (IAM/SSO), guardrails, and logging (CloudTrail, Config). This is the part teams most often underbuild. See AWS landing zone for the full build and AWS DevOps for the CI/CD and IaC that keeps it maintainable.
Migrate one low-risk-but-representative application end to end: replicate it, cut over in a controlled window, validate, and prove the rollback path actually works. Output: a repeatable cutover runbook and real timing data to extrapolate across the waves. A pilot that can't roll back cleanly is a finding, not a failure — far better caught here than in wave three.
Execute the waves: rehost via MGN with short cutover windows, databases via DMS with continuous replication so the source stays live until the flip, bulk data via DataSync. Each wave: replicate, test in AWS, schedule the window, cut over, validate, decommission the source — with the old environment kept warm until the wave is confirmed stable. This is the bulk of the calendar and where the partner earns their keep.
Right-size instances, move steady-state compute onto Savings Plans/Reserved capacity, replatform the workloads that justify it (EC2 databases → RDS, VMs → containers), and retire the lift-and-shift inefficiencies you accepted to move fast. The cost curve bends down, the architecture earns the "cloud-native" label, and the AWS credits you secured get spent buying down the early bill.
AWS frames migrations as the "7 Rs": Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor. In practice the decision that matters for almost every workload is rehost vs replatform vs refactor — and the right default is "rehost now, replatform selectively, refactor later."
Rehost (lift-and-shift) moves the workload as-is onto EC2 via MGN. It's the fastest path to "off the old platform" and the lowest-risk per workload because nothing about the app changes — same OS, same runtime, same config. The downside is you carry your old inefficiencies into AWS and don't capture managed-service savings until you optimize later. For most teams under time pressure or a renewal cliff, rehost-first is the correct call: get out, stabilize, then improve.
Replatform (lift-tinker-shift) makes targeted changes that pay back fast without rewriting the app: move a self-managed Postgres to RDS/Aurora, containerize a VM onto ECS/Fargate or EKS, swap a self-hosted queue for SQS, or move a static-but-server-rendered front end to App Runner. Replatforming the database and the runtime usually captures the bulk of the operational savings for a fraction of a full rewrite. The rule of thumb: replatform the things that are expensive to operate (databases, message brokers, orchestration) and rehost the things that are cheap to leave alone.
Refactor — re-architecting into managed/serverless primitives (Lambda, Step Functions, event-driven, microservices) — delivers the most long-term value and costs the most up front. It is almost never the right first move; refactor after you're stable on AWS, workload by workload, where the business case is clear. Trying to refactor mid-migration is how cutovers slip by quarters.
The other three Rs are quick discovery-time filters: Retire the workloads nobody uses (every migration finds 10–20% of servers to just turn off), Retain the ones that genuinely can't move yet (a legacy dependency, a licensing constraint), and Repurchase where a SaaS equivalent beats migrating at all (self-hosted email → SES or a SaaS, a homegrown CRM → off-the-shelf).
Rehost to get off the old platform fast and de-risk the cutover. Replatform the database and the runtime where the operational savings are obvious. Refactor later, deliberately, once you're stable. A migration that tries to refactor everything at once is a rewrite wearing a migration's clothes — and it will slip.
The done-for-you model isn't "hand us your AWS keys and disappear." It's a clear division of labor where the partner owns the migration machinery and you own the product decisions — with AWS funding the work so a qualifying customer pays little to nothing.
A vetted partner runs the six-phase journey above as a managed engagement: they file the MAP record, build the landing zone, configure and run MGN/DMS/SCT, write and rehearse the cutover runbook, execute the waves, and stand up the monitoring and cost guardrails. You stay in control of the targets and the timing — which workloads, which order, which cutover windows, and the go/no-go at each gate.
On funding, the qualifying-migration path works like this: AWS underwrites the Assess phase at no charge, then credits a share of the Mobilize and Migrate costs — paid to the partner through MAP — so the engagement is funded rather than billed to you. For a qualifying workload the customer's direct cost trends toward $0; any portion not covered is small and usually recovered within a month or two from the cloud-bill delta. We don't overclaim this: MAP funding is for qualifying migrations only. If yours doesn't qualify, the same partner is a vetted referral that de-risks the cutover — you pay for the engagement directly, at partner rates.
CloudRoute's role is the routing layer. We don't run the migration; we match you to a partner who has done your exact source-to-target move, confirm MAP eligibility, and make sure the record is filed correctly so the funding lands. The partner is paid by AWS through MAP and engagement funding; CloudRoute is paid a routing commission by the partner. You don't sit in that payment loop — which is why the customer-facing price for a qualifying migration is $0.
The most common worry about a done-for-you migration is loss of control or a giant internal time sink. Neither is true when the split is clear — here is exactly who does what.
| Responsibility | You provide | The partner provides |
|---|---|---|
| Workload knowledge | App architecture, dependencies, data sensitivity, runtime versions | Discovery tooling, dependency mapping, the disposition (7 Rs) call |
| Decisions & sign-off | Migration targets, wave order, cutover windows, go/no-go at each gate | Options, tradeoffs, recommendations, risk callouts |
| Access | Source-environment + new AWS account access, DNS control | Landing zone, IAM/SSO, guardrails, account structure |
| Migration machinery | — | MGN, DMS + SCT, DataSync, Migration Hub config + execution |
| Cutover | A maintenance window + product validation of the cut-over app | The runbook, the rehearsed rollback, running the cutover |
| Funding | Projected post-migration AWS spend (sizes the MAP funding) | Files + manages the MAP record so the funding lands |
| After | Decommission sign-off, ongoing product ownership | Right-sizing, Savings Plans, optimization, handover docs |
There is no honest single number — a five-server SaaS and a 300-VM enterprise estate are different universes. But the phase shape is consistent, and the realistic ranges below are what to plan around. Anyone promising a one-week enterprise migration is selling you the cutover and hiding the assess and landing-zone work.
For a small workload (a single app, one database, a handful of servers — a typical Heroku or DigitalOcean migration), the whole journey is commonly 3–6 weeks: a few days of discovery, a short assess, a week of landing zone, a quick pilot, and a cutover or two. The cutover window itself is often minutes to a couple of hours.
For a mid-size estate (10–40 workloads, a few databases, some integrations — a growth-stage company moving off GCP/Azure or out of a data center), plan 2–4 months. The landing zone and wave planning take real time, and you'll run multiple cutover waves.
For a large or heterogeneous estate (50+ workloads, Oracle/SQL Server with heavy schema conversion, SAP, strict compliance), 6–12+ months is normal. Heterogeneous database migrations (Oracle/SQL Server → Aurora PostgreSQL) are reliably the long pole — schema conversion with SCT, stored-procedure rewrites, and exhaustive data validation dominate the calendar far more than moving the application tier does.
The biggest schedule risks, in order: (1) heterogeneous schema conversion; (2) undiscovered dependencies that surface mid-wave; (3) an underbuilt landing zone you have to retrofit; (4) cutover windows the business won't accept the downtime for — which is why minimal-downtime replication (MGN/DMS continuous sync) earns its setup. A partner who has done your exact move has hit all four before and prices the schedule accordingly. That is the entire point of routing to one who has.
You can run the migration yourself or route it to a vetted partner with MAP funding. DIY gives you maximum control and zero external dependency; partner-led trades a little control for funded execution, experience with your exact move, and your team staying on product. The real tradeoff for a qualifying workload:
| Variable | DIY migration | Partner-led (MAP-funded) |
|---|---|---|
| Who runs it | Your engineers, learning as they go | A partner who has done your exact source→target move |
| Cost of the engagement | Your engineering time (the real cost) + any tooling | ~$0 for a qualifying migration — AWS funds it via MAP |
| MAP / credit funding | Hard to access without partner ACE/APN submission | Partner files the MAP record so the funding lands |
| Landing zone | You design and build it (easy to underbuild) | Built to a proven, governed baseline |
| Cutover risk | First rodeo — rollback path often untested | Rehearsed runbook + proven rollback from the pilot |
| Timeline certainty | Wide — surprises hit a team without the reps | Tighter — priced off prior moves like yours |
| Team focus | Pulled off the product roadmap for the duration | Stays on product; owns decisions + validation only |
| Best for | Tiny, simple moves; teams with deep AWS reps + slack | Anything non-trivial, on a clock, or wanting it funded |
Situation: Heroku bill had crept past $9K/month across dynos, Heroku Postgres, and add-ons, with a renewal forcing a decision. The team needed managed Postgres at scale, a path to EKS, and a SOC 2-friendly network they couldn't build on Heroku. No one internally had run an AWS migration, and pulling two senior engineers off the roadmap for a quarter was a non-starter ahead of their Series-B prep.
What CloudRoute did: CloudRoute routed within 24 hours to a partner with a documented Heroku→ECS/EKS + Heroku Postgres→RDS track record. Partner filed the MAP record on day 4; AWS funded the Assess phase outright. Landing zone (Control Tower, multi-account, SSO) stood up in week 2. Pilot app cut over in week 3 with a tested rollback. Heroku Postgres migrated to Aurora PostgreSQL via DMS with continuous replication; the app tier rehosted then replatformed onto ECS Fargate across three waves.
Outcome: Production traffic fully on AWS by week 10. MAP credited the large majority of the migration cost (Assess fully funded; Mobilize + Migrate credited via MAP) so the customer's direct cost was effectively $0; a small non-funded remainder was recovered inside month 2 from the cloud-bill delta. Heroku bill went to $0 by month 3. Internal engineering load: ~4 hours/week, concentrated on cutover validation. CloudRoute's commission was paid by the partner from AWS engagement funding.
cutover: 10 weeks · founder/eng time: ~4 hrs/week · MAP-funded: majority of cost · cost to customer: ~$0
CloudRoute matches you to a vetted AWS partner who has done your exact move, files the MAP record so AWS funds it, and runs the cutover. Qualifying migrations land at ~$0 to you. No procurement, no discovery theater.