The honest answer is a range, not a date: a single app moves in 2–6 weeks, a small startup estate in 1–3 months, a mid-size estate in 3–9 months, and a large enterprise in 9–24 months. The number is set by four phases — Assess, Mobilize, Migrate in waves, Optimize — and by a handful of accelerators and drags: dependency depth, data volume, compliance, refactor scope, and team availability. This page gives the realistic durations for each, what speeds a migration up versus what slows it down, and how AWS MAP and a vetted partner compress the calendar.
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.
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.
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 containerize-to-ECS/App Runner replatform, one cutover wave, a short dual-run. The schedule is dominated by validation and the cutover window, not the move itself.
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.
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.
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 | Below MAP minimums — referral |
| 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 |
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.
What happens: inventory every server, database, dependency, and data flow; build a TCO model; assign a 7-Rs disposition per workload; and produce the wave plan that sequences everything after it. Tools: AWS Application Discovery Service, Migration Evaluator, Migration Hub.
Realistic duration: a few days for a single app; 2–6 weeks for a mid-size estate; 1–3 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 turns a 6-month migration into a 12-month one. Under MAP this phase is frequently AWS-funded and fast-tracked, because AWS wants to de-risk its own funding decision.
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.
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.
What happens: right-size the migrated workloads (most estates land 20–40% over-provisioned after a lift-and-shift), adopt Savings Plans / Reserved Instances, tune managed services, and refactor the few workloads whose ongoing-cost or velocity gains justify the engineering.
Realistic duration: begins as soon as the first wave is live and continues for weeks to months past the final cutover — it overlaps the tail of Migrate rather than starting after it. Treating Optimize as optional is why some migrations finish "on time" but the bill creeps up: the savings that justify the whole project show up here, and under MAP the optimization work is typically bundled into the partner engagement.
On a typical mid-size migration the rough split is Assess ~10–15%, Mobilize ~15–20%, Migrate ~50–60% (the waves), with Optimize overlapping the final third. 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.
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 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.
The AWS Migration Acceleration Program (MAP) and an experienced partner do not just fund a migration — they shorten it, by removing the slowest parts: a fast-tracked assessment, a proven landing zone, and runbooks executed many times before.
MAP runs in three phases — Assess, Mobilize, and Migrate & Modernize — that map directly onto the four-phase timeline above (Optimize is folded into Migrate & Modernize as the continuous tail). For qualifying migrations AWS funds a large share of the cost, and just as importantly it fast-tracks the Assess phase, which is the gate on everything after it. AWS wants to de-risk its own funding decision, so the readiness assessment that might take a self-funded team weeks of calendar negotiation gets prioritized.
The bigger time saving is the partner. A vetted, MAP-eligible partner (Advanced or Premier tier, migration track record) attacks the slowest drags directly — landing-zone build time, the cost of an unproven cutover pattern, and limited team availability — through the levers below.
The honest framing: MAP applies to qualifying migrations with a meaningful committed post-migration AWS spend — small migrations below the threshold do not get MAP funding. But the partner-driven timeline compression applies regardless: even a sub-threshold migration finishes faster with a partner who has done it before. CloudRoute routes you to that partner — matched to your stack, region, and compliance needs — typically within 24 hours, so the clock on Assess starts immediately rather than after weeks of vendor selection.
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.
Inventory and dependency mapping, TCO model, per-workload 7-Rs disposition, and the wave plan itself — the AWS-funded, fast-tracked phase under MAP. Output: a sequenced, dependency-aware wave plan that everything below follows.
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.
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.
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.
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+.
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 across the wire (throughput is finite, though Snow Family parallelizes large estates offline), heterogeneous 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 — a cross-engine conversion shipped without enough testing is a production incident, not a saved week.
The realistic posture: size your estate honestly, expect the band the size implies, then use a MAP-funded partner to land toward the fast end rather than believing you can skip a phase. The single fastest thing you can do is get matched to a partner so the Assess phase — the gate on everything else — begins now instead of after weeks of vendor selection. That first match is what CloudRoute does in under 24 hours.
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 |
Situation: An internal estimate put the migration at 12–15 months because the engineering team could only spare ~30% of its time and had never built an AWS landing zone or run a cross-engine database conversion. Leadership wanted off the current cloud before the next renewal — roughly 7 months out — and feared an unproven cutover taking down production during their peak quarter.
What CloudRoute did: Routed within 24 hours to an Advanced-tier AWS partner with an Oracle-to-Aurora and MAP track record. The partner ran the AWS-funded, fast-tracked Assess (4 weeks, producing a dependency-aware wave plan), dropped in a pre-built well-architected landing zone in Mobilize (under 3 weeks instead of the months the internal team had budgeted), then executed six overlapping waves on AWS MGN with minutes-long cutovers. The Oracle → Aurora conversion was scheduled mid-program via SCT + DMS with a tested rollback. The peak-quarter freeze was sequenced around, not through.
Outcome: Total elapsed time: ~5.5 months — comfortably inside the renewal deadline and roughly half the internal 12–15-month estimate. Dual-running was held to ~6 weeks via continuous replication. Optimize ran alongside the back half; post-migration right-sizing + Savings Plans landed the run-rate ~30% lower. MAP funded the bulk of the cost, and CloudRoute's commission was paid by the partner from AWS engagement funding — the customer paid CloudRoute $0.
internal estimate: 12–15 months · delivered: ~5.5 months · dual-run: ~6 weeks · run-rate ~30% lower · routing cost: $0
CloudRoute routes you to a vetted, MAP-eligible AWS partner who sizes your estate, gives you a phase-by-phase timeline, and runs the migration. For qualifying migrations AWS funds the cost, and you pay CloudRoute nothing.