How long does an AWS migration take? realistic timelines by estate size and phase.
The honest answer is a range, not a date. As rough estimates: a single app moves in weeks, a small startup estate in one to three months, a mid-size estate in three to nine months, and a large enterprise in a year or more. The number is set by four phases (Assess, Mobilize, Migrate in waves, Optimize) and by a few drags: dependency depth, data volume, compliance, refactor scope and team availability.
- There is no single AWS migration timeline — it scales with estate size. A single application is typically 2–6 weeks; a small startup estate 1–3 months; a mid-size estate (tens to ~100 servers, several databases) 3–9 months; a large enterprise (hundreds–thousands of servers, heterogeneous databases, on-prem + cloud) 9–24+ months. Anyone quoting a fixed number without sizing your estate is guessing.
- Whatever the size, the calendar breaks into four phases — Assess (readiness, TCO, 7-Rs disposition), Mobilize (landing zone + a pilot wave), Migrate (the production moves, run in waves), and Optimize (right-size, Savings Plans, refactor the few that justify it). Mobilize and the Migrate waves dominate the schedule; Assess is short but gates everything after it.
- What moves the date is predictable: deep dependencies, large data volumes, compliance, how much you refactor versus rehost, and how much of your team is actually available. An experienced partner shortens it with a proven landing zone, rehearsed runbooks and a dedicated team, and continuous replication (AWS MGN) keeps each cutover short. If the migration qualifies, your matched partner can also file MAP funding: typically $50K to $150K for startups. Depends on the workload; AWS approves.
IWhy "how long does an AWS migration take" has no single answer
The honest answer spans weeks to years, because "a migration" can mean moving one containerized app off Heroku or relocating a thousand-server regulated enterprise estate off the data-center floor. The useful answer is to anchor the duration to estate size first, then adjust for the factors that actually move the date.
When a vendor promises a fixed timeline before they have inventoried your estate, they are quoting a marketing number. Duration is a function of four things: how many workloads move, how tangled their dependencies are, how much data has to cross the wire, and how much you re-architect on the way. A "two-week AWS migration" is real for a single stateless app; it is a fantasy for an estate with heterogeneous databases and compliance scope. Both are AWS migrations — simply different-sized projects.
A more durable way to reason about it: total timeline = (Assess) + (Mobilize) + (Migrate, in parallel waves) + (Optimize, overlapping the tail). Assess is short but gates everything — it produces the per-workload 7-Rs disposition (Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor) and the wave plan that decides how parallel the rest can run. The sections below give realistic durations per phase and per estate size, then the accelerators and drags that explain why two same-sized estates can finish months apart.
IIAWS migration timeline by estate size
Estate size is the first-order driver of how long a migration takes. These are representative 2026 ranges for a mostly rehost/replatform approach with selective refactoring — treat them as bands, not commitments.
The ranges assume a competent team or partner running a disciplined wave-based migration with continuous replication. They widen when you refactor heavily, when databases are heterogeneous (cross-engine conversions are the slowest single task), or when compliance gates each wave; they tighten when workloads are loosely coupled, data volumes are modest, and a partner brings a pre-built landing zone. The table makes the shape concrete; the sections after it explain why each band sits where it does.
Single application — 2–6 weeks
One app, a handful of servers, a single database: a Heroku or DigitalOcean app, a standalone service. A pure rehost via AWS Application Migration Service (MGN) or a containerise-to-ECS replatform (App Runner closed to new customers on April 30, 2026), one cutover wave, a short overlap. Validation and the cutover window dominate the schedule, not the move itself.
Small startup estate — 1–3 months
A few apps, ~10–20 servers, a small number of databases — a seed-stage company's whole footprint. Two to four waves and a couple of like-to-like database moves (e.g. Heroku Postgres → RDS via DMS). Most of the calendar is Mobilize plus the first waves; once the pattern is proven, the rest go quickly.
Mid-size estate — 3–9 months
Tens to ~100 servers, several databases (often one heterogeneous conversion), multiple interdependent apps — a growth-stage estate. This is where dependency mapping earns its keep: Assess takes weeks because getting the wave plan right is what lets later waves run in parallel. Expect a multi-wave Migrate phase over several months with a meaningful dual-run overlap.
Large enterprise — 9–24+ months
Hundreds to thousands of servers, mixed on-prem and cloud, heterogeneous databases, compliance gates, often a mainframe or SAP estate. Assess alone can run 1–3 months. The Migrate phase is a program, not a project — many parallel waves sequenced around freeze windows, with a dedicated team. Core MAP territory, and the honest range is a year-plus.
| Estate size | Profile | Total elapsed time | Typical # of waves | Dominant phase | MAP fit |
|---|---|---|---|---|---|
| Single app | 1–10 servers, 1 database (e.g. a Heroku/DigitalOcean app) | 2–6 weeks | 1 | Cutover + validation | Often too small for MAP |
| Small startup | A few apps, ~10–20 servers, a few databases | 1–3 months | 2–4 | Mobilize + first waves | Possible if spend is meaningful |
| Mid-size | 10–100 servers, several databases, interdependent apps | 3–9 months | 4–10 | Migrate (parallel waves) | Strong fit |
| Enterprise | 100s–1,000s of servers, on-prem + cloud, heterogeneous DBs | 9–24+ months | 10s | Migrate (program of waves) | Core MAP territory |
IIIThe four phases and how long each takes
Whatever the estate size, the timeline decomposes into the same four phases. Knowing the realistic duration of each — and which one gates the others — is how you read a project plan critically instead of accepting a single end date.
The phases map onto how AWS structures a MAP engagement (Assess → Mobilize → Migrate & Modernize), with Optimize as the continuous tail. They are partly sequential, partly overlapping. The durations below are for a mid-size estate; scale down for a single app and up for an enterprise.
1. Assess — readiness, TCO, and the wave plan
What happens: inventory every server, database, dependency and data flow; build a TCO model; assign a 7 Rs decision per workload; and produce the wave plan that sequences everything after it. Tools: Migration Evaluator, AWS Transform and partner discovery tools (AWS Migration Hub and Application Discovery Service closed to new customers on November 7, 2025).
Estimated duration: days for a single app, weeks for a mid-size estate, months for an enterprise. It is short relative to the whole, but it gates everything: a rushed Assess produces a bad wave plan, and a bad wave plan is what doubles a migration.
2. Mobilize — landing zone and the pilot wave
What happens: build the AWS foundation — the landing zone (multi-account structure, networking, IAM, guardrails, logging) — and run a pilot wave of one or two low-risk workloads end to end to prove the pattern, the tooling, and the cutover runbook.
Realistic duration: 1–2 weeks for a small estate; 3–8 weeks for a mid-size one; longer for an enterprise with strict networking and compliance baselines. This is where a partner compresses the calendar most: a vetted partner brings a pre-built, well-architected landing zone instead of building one from scratch, often saving weeks. The pilot wave is non-negotiable — skipping it to "save time" reliably costs more time later when an unproven pattern fails mid-migration.
3. Migrate — the production moves, run in waves
What happens: the actual moves, grouped into waves of related workloads and executed a wave at a time (with several often in flight at once). Rehosts go via AWS MGN with continuous replication so the cutover per wave is minutes; database moves go via DMS + the Schema Conversion Tool (SCT); each wave is validated, then its source is decommissioned.
Realistic duration: this is where elapsed time accumulates — weeks for a small estate, several months for mid-size, a year-plus for an enterprise. The lever is parallelism: how many waves you can safely run concurrently, set by how clean your dependency mapping was in Assess. Continuous replication keeps each cutover short, but the number and sequencing of waves sets the total.
4. Optimize — right-size, commit, refactor selectively
What happens: right-size the migrated workloads (a lift-and-shift copies the old over-provisioning), adopt Savings Plans or Reserved Instances, tune managed services, and refactor the few workloads whose cost or speed gains justify the engineering.
Duration: begins when the first wave is live and continues past the final cutover; it overlaps the tail of Migrate. Treating Optimize as optional is why some migrations finish "on time" but the bill creeps up: the savings that justify the project show up here.
Most of the calendar is the Migrate waves, with Optimize overlapping the end. Assess is the cheapest phase to invest extra time in and the most expensive to rush: it sets how parallel everything after it can run.
IVWhat genuinely speeds an AWS migration up
Some of the timeline is fixed by physics — data has to copy, waves have to validate — but a large share is determined by choices and preparation. These are the levers that reliably pull the date in.
- A clean dependency map from Assess: The single biggest accelerator — knowing which workloads depend on which is what lets you run many waves in parallel instead of serially. Time invested in discovery pays back multiples in the Migrate phase.
- Continuous replication (AWS MGN): MGN keeps source and target continuously synced, so the cutover per wave is minutes, not a multi-day data-copy window — shrinking both cutover risk and dual-running overlap.
- A pre-built, partner-supplied landing zone: Building a well-architected multi-account landing zone from scratch takes weeks. A vetted partner brings a proven one, compressing Mobilize substantially — often the fastest single week-saver available.
- Rehost-first, refactor-later sequencing: Moving the bulk as-is via MGN gets you off the old provider fast and stops the old bill; refactoring the few workloads that justify it happens in Optimize, off the critical path, instead of blocking the migration.
- Like-to-like database moves where possible: PostgreSQL → RDS PostgreSQL or MySQL → Aurora MySQL are fast; reserving cross-engine conversions for the workloads that truly need them keeps the slowest task off most waves.
- A dedicated, available migration team: A team actually allocated to the migration — or a partner whose full-time job it is — moves far faster than engineers fitting it around a product roadmap. Availability is often the real bottleneck, not technical difficulty.
VWhat slows it down — the factors that push the date out
A credible timeline accounts for the factors that quietly extend it. None are exotic; all are predictable, and naming them up front is how you keep the date honest instead of optimistic.
- Deep application coupling: Tightly interdependent workloads cannot move in parallel — they force long serial wave chains because each wave waits on the one before. Hidden, undocumented dependencies discovered mid-migration are the classic schedule-buster.
- Large data volumes: Multi-terabyte and larger estates take real time to copy. Online transfer (AWS DataSync) and physical transfer (AWS Data Transfer Terminal; Snowball Edge is closed to new customers) both have limits; a large warehouse or media library can add weeks to a wave.
- Compliance and regulated workloads: SOC 2, HIPAA, PCI, and similar add controls validation, audit gates, and change-control windows to each affected wave. The technical move is unchanged; the approvals and evidence-gathering around it extend the calendar.
- Refactor scope: Every workload you re-architect instead of rehosting adds engineering months. A blanket "refactor everything" plan is the most common way a 6-month migration becomes an 18-month one. Refactor on the strength of payback, not by default.
- Heterogeneous database conversions: Cross-engine moves (Oracle/SQL Server → Aurora PostgreSQL) need schema conversion, stored-procedure remediation, and heavy testing via SCT + DMS — consistently the slowest single task in any migration and a frequent critical-path item.
- Limited team availability: If the migration competes with feature work for the same engineers, it stretches to fill whatever time is left over — the most common non-technical cause of slippage, and exactly what a dedicated partner team removes.
- Business freeze windows: Retail blackouts, financial close periods, and peak seasons block cutovers for weeks. They are immovable, so the wave plan must sequence around them, not through them.
VIHow MAP and a vetted partner compress the timeline
An experienced partner shortens a migration by removing the slowest parts: building a landing zone from scratch, an unproven cutover pattern, and a part-time team. MAP is the funding side.
MAP runs in three phases (Assess, Mobilize, and Migrate and Modernize) that map onto the four-phase timeline above, with Optimize as the continuous tail. AWS says MAP helps offset initial migration costs. It is filed by a partner: your matched partner files it when the migration qualifies and AWS approves. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.
The bigger time saving is the partner. A vetted partner with a migration track record attacks the slowest drags directly through the levers below.
MAP applies only to qualifying migrations, and small ones may not qualify. The partner-driven time saving applies either way. CloudRoute replies within 24 hours and your matched partner reaches out within 5 business days, so Assess can start without weeks of vendor selection.
- A partner who checks MAP up front: Knowing early whether partner-filed funding applies keeps the business case from stalling between phases.
- Pre-built landing zone (partner): A proven multi-account, well-architected foundation drops into Mobilize in days, not the weeks a from-scratch build takes.
- Proven runbooks (partner): Wave plans and cutover runbooks executed across many prior migrations remove the trial-and-error that stretches first-timer schedules.
- A dedicated team (partner): A full-time migration team removes the single most common cause of slippage — your engineers being only partly available.
VIIA sample wave schedule for a mid-size migration
Timelines feel abstract until sequenced. Here is a representative wave schedule for a mid-size estate — roughly 60 servers, four databases (one a heterogeneous Oracle → Aurora PostgreSQL conversion), multiple interdependent apps — landing in the 5–6 month band. The shape is what matters: waves rise in risk as confidence grows, the hardest item sits mid-program, and waves overlap (one validating while the next replicates) to compress the calendar without raising cutover risk.
Weeks 1–4 — Assess
Inventory and dependency mapping, TCO model, a 7 Rs decision per workload, and the wave plan itself. If the migration qualifies, this is also when the partner prepares the MAP request. Output: a sequenced, dependency-aware wave plan that everything below follows.
Weeks 4–8 — Mobilize + pilot wave (Wave 0)
Build the landing zone (accounts, networking, IAM, guardrails, logging) and run a pilot wave of one or two low-risk, loosely-coupled workloads end to end on AWS MGN — proving the tooling, cutover runbook, and rollback before anything business-critical moves.
Weeks 8–16 — Waves 1–3 (the bulk rehost)
The loosely-coupled majority of the estate, rehosted via MGN with short cutover windows, plus like-to-like database moves (e.g. PostgreSQL → RDS) via DMS. Several waves overlap — one validating while the next replicates — and most of the server count clears here.
Weeks 14–20 — Wave 4 (the hard database conversion)
The heterogeneous Oracle → Aurora PostgreSQL conversion via SCT + DMS: schema conversion, stored-procedure remediation, parallel-run validation, tested rollback. Scheduled mid-program — the team is warmed up and the pattern proven, with schedule buffer still behind it — overlapping the tail of the bulk-rehost waves.
Weeks 18–24 — Waves 5–6 + Optimize
The most dependency-heavy, business-critical workloads move last, when confidence and runbooks are strongest. In parallel, Optimize ramps — right-sizing migrated waves, applying Savings Plans, refactoring the one or two workloads whose payback justifies it — and final source decommissioning closes out the dual-run.
Pilot the pattern on something safe, clear the loosely-coupled bulk fast while confidence builds, schedule the single hardest task (the cross-engine database conversion) in the middle — not first, not last — and move the most business-critical workloads at the end. Overlapping waves, not serial ones, are what keep the calendar in the 5–6 month band instead of 9+.
VIIISetting an honest expectation: what can and cannot be compressed
A trustworthy timeline distinguishes the parts of a migration that genuinely compress from the parts that do not, so you plan around reality rather than a best-case slide.
What compresses: landing-zone build time, cutover windows, the learning curve, wave parallelism, and team availability — exactly the levers MAP and a vetted partner pull, which together routinely move a mid-size migration from the top of its band toward the bottom.
What does not compress past a floor: data physically copying (throughput is finite), cross-engine database conversion and its testing (correctness cannot be rushed), compliance validation and audit gates, and business freeze windows. Trying to compress these is how migrations fail rather than finish early.
The realistic posture: size your estate honestly, expect the band the size implies, then use an experienced partner to land toward the fast end rather than skipping a phase. The fastest single step is getting Assess started. CloudRoute replies within 24 hours and your matched partner reaches out within 5 business days.
AWS migration timeline by size — phase durations side by side
The four phases mapped against estate size, so you can see both the total elapsed time and where it goes. Durations are representative 2026 ranges for a disciplined wave-based migration.
| Phase | Single app | Small startup | Mid-size | Enterprise |
|---|---|---|---|---|
| Assess (readiness, TCO, wave plan) | 2–5 days | 1–2 weeks | 2–6 weeks | 1–3 months |
| Mobilize (landing zone + pilot) | 3–7 days | 1–2 weeks | 3–8 weeks | 1–3 months |
| Migrate (production waves) | 1–3 weeks | 3–8 weeks | 2–6 months | 6–18+ months |
| Optimize (right-size, commit, refactor) | overlaps + ongoing | overlaps + ongoing | overlaps + ongoing | overlaps + ongoing |
| Total elapsed time | 2–6 weeks | 1–3 months | 3–9 months | 9–24+ months |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
How long does an AWS migration take?
What are the phases of an AWS migration and how long is each?
Can you migrate to AWS in two weeks?
What slows an AWS migration down the most?
How does MAP affect the migration?
What is a wave-based migration and why does it matter for the timeline?
How much faster is a partner-led migration than doing it ourselves?
How does CloudRoute fit in, and what does it cost me?
Get a realistic timeline for your AWS migration
CloudRoute matches you with one vetted AWS partner who sizes your estate, gives you a phase-by-phase timeline, runs the migration, and files MAP funding when the migration qualifies and AWS approves. CloudRoute is free for startups.