AWS MAP Timeline: How Long Does a MAP Engagement Actually Take

How Long Does the MAP Assess Phase Take?

The Assess phase runs 2–8 weeks for most organizations. A small company with under 50 workloads and simple infrastructure can complete assessment in two weeks. An enterprise with 500+ workloads, multiple data centers, and complex application dependencies needs six to eight weeks.

During Assess, three parallel workstreams run simultaneously. The first is portfolio discovery: deploying AWS Application Discovery Service or partner tools to inventory all servers, map dependencies, and measure resource utilization. The second is business case development: calculating TCO comparisons, MAP credit estimates, and payback timelines. For guidance on this calculation, see our MAP ROI calculator guide.

The third workstream is migration strategy assignment. Each application receives one of the 7 Rs: Rehost, Replatform, Refactor, Repurchase, Retire, Retain, or Relocate. Strategy assignment directly impacts the Migrate phase timeline — refactored workloads take 3–5x longer than rehosted ones. Rushing this assignment leads to mid-migration strategy changes, which are the most expensive type of project rework.

The most common Assess phase delay is incomplete application dependency mapping. Legacy applications often have undocumented dependencies — a payroll system calling a tax calculation service that calls a database on a different server. Automated discovery tools catch 70–80% of dependencies. The remaining 20–30% require manual interviews with application teams, which can extend the phase by one to two weeks.

What Happens During the Mobilize Phase?

The Mobilize phase runs 4–16 weeks and produces the operational foundation for migration. This is where cloud infrastructure, security controls, networking, and operations tooling are built and validated. Many organizations underestimate Mobilize because it produces infrastructure rather than migrated workloads — but cutting it short guarantees problems during migration.

Key Mobilize deliverables include: AWS Landing Zone deployment (via AWS Control Tower or custom), network connectivity setup (Direct Connect or VPN), IAM role hierarchy, security tooling (GuardDuty, Security Hub, Config rules), CI/CD pipeline configuration, and monitoring/alerting setup with CloudWatch. For regulated industries, add compliance automation and audit trail configuration.

The Mobilize phase should also include at least one pilot migration — a non-critical workload migrated end-to-end to validate the process. The pilot reveals gaps in tooling, runbooks, and team skills before they impact production workloads. A pilot migration typically takes one to two weeks and should exercise the full migration workflow: provisioning, data transfer, testing, DNS cutover, and rollback procedures.

Mobilize delays most commonly stem from network connectivity. AWS Direct Connect provisioning requires coordination between AWS, the customer, and a colocation provider. Lead times for Direct Connect range from two weeks (in regions with existing cross-connects) to eight weeks (for new physical connections). Starting the Direct Connect order during or even before the Assess phase can save weeks of idle time during Mobilize.

How Long Does the Migrate and Modernize Phase Actually Take?

Migrate & Modernize is the longest phase, running 3–18 months depending on portfolio size, migration strategies, and team capacity. Organizations typically execute migration in waves, with each wave containing 5–30 workloads grouped by dependency, business domain, or migration strategy.

Wave cadence determines overall migration velocity. Mature migration teams execute waves every 2–4 weeks, migrating 10–20 workloads per wave. This translates to 40–80 workloads per quarter. At this pace, a 200-workload portfolio completes in 6–12 months. A 500-workload portfolio needs 15–18 months. Initial waves are slower as teams build muscle memory — expect the first two waves to take 3–4 weeks each.

Migration strategy significantly affects per-workload duration. A rehost (lift-and-shift) takes 1–2 days per server. A replatform (e.g., moving from self-managed MySQL to Amazon RDS) takes 1–2 weeks per application. A full refactor to cloud-native architecture takes 2–6 months per application. Most portfolios contain a mix: 40–50% rehost, 30–40% replatform, and 10–20% refactor.

The AWS MAP program provides tools to accelerate each strategy. AWS Migration Hub tracks progress across all workloads. AWS Application Migration Service automates server rehosting. AWS Database Migration Service handles database replatforming. These tools reduce manual effort and shorten per-workload timelines by 30–50%.

What Factors Most Affect MAP Timeline?

Five factors have the largest impact on overall MAP duration. First, workload count and complexity. A portfolio of 50 simple web servers migrates in three months. A portfolio of 300 applications with complex interdependencies, legacy databases, and custom middleware takes 18 months or more.

Second, regulatory requirements. Healthcare organizations subject to HIPAA add 4–8 weeks for compliance validation. Financial institutions meeting PCI DSS and SOC 2 requirements add 6–12 weeks. For industry-specific timelines, see our guides on MAP for healthcare and MAP for financial services.

Third, team capacity and skills. Organizations with experienced cloud engineers execute faster than those building cloud skills during the migration. A dedicated migration team of 5–8 engineers can sustain 15–20 workloads per wave. Shared teams that split time between migration and operations typically manage 5–8 workloads per wave.

Fourth, organizational change management. Migrations require application owners to validate functionality, update procedures, and retrain staff. If application teams are not engaged early, validation bottlenecks delay each wave. Fifth, third-party vendor dependencies. Enterprise software vendors (SAP, Oracle, Epic) have specific cloud deployment requirements and certification processes that can add weeks to individual workload timelines.

How Can You Accelerate a MAP Engagement?

The single most effective acceleration strategy is parallelization. Run the Assess and Mobilize phases concurrently rather than sequentially. While the portfolio assessment proceeds, begin setting up the AWS Landing Zone, ordering Direct Connect, and training teams. This overlap can save 4–8 weeks on the overall timeline.

Automation is the second lever. Use AWS Application Migration Service for automated server replication. Deploy CloudFormation or Terraform templates for infrastructure provisioning. Automate testing with CI/CD pipelines that validate migrated workloads against pre-defined acceptance criteria. Organizations with mature automation migrate 50–100% faster per wave than those relying on manual processes.

Third, establish clear decision-making authority. Migrations stall when every decision requires executive committee approval. Define a decision matrix upfront: application owners approve functional changes, the cloud team approves architecture decisions, and the steering committee handles only cross-business-unit conflicts and budget changes exceeding a defined threshold.

Fourth, batch similar workloads. Migrating all .NET applications together, then all Java applications, then all databases leverages specialization. Teams build efficiency through repetition. Mixed waves that combine different technologies force context-switching and slow execution.

What Does a Realistic MAP Timeline Look Like?

For a mid-market organization with 150 workloads, moderate complexity, and no heavy regulatory requirements, a realistic timeline follows this pattern. Weeks 1–4: Assess phase (portfolio discovery, business case, strategy assignment). Weeks 3–10: Mobilize phase (overlapping with late Assess), including Landing Zone, connectivity, security, and pilot migration.

Weeks 10–14: Wave 1 migration (10 low-risk workloads, learning phase). Weeks 14–18: Wave 2 (15 workloads, improved velocity). Weeks 18–22: Wave 3 (20 workloads, hitting stride). Waves continue every 3–4 weeks through week 48–52, with increasing workloads per wave as the team matures. Post-migration optimization runs concurrently from wave 3 onward.

Total duration: 12–14 months. This timeline assumes a dedicated migration team of 6 engineers, engaged application owners, and no major regulatory hurdles. Adding HIPAA compliance extends it to 16–18 months. Adding PCI DSS extends it to 18–20 months. Adding both can push beyond 24 months for larger portfolios.

How Do You Track Progress Against the MAP Timeline?

AWS Migration Hub provides a centralized dashboard showing migration status for every workload. Each workload tracks through defined stages: not started, in progress, completed, or blocked. The hub integrates with Application Migration Service, Database Migration Service, and partner tools to provide real-time progress visibility.

Beyond the hub, establish weekly migration stand-ups and monthly steering committee reviews. Weekly stand-ups focus on current wave execution: blockers, risk items, and task completion. Monthly reviews evaluate overall program health: velocity trends, credit utilization, cost variance, and timeline adherence. For a complete framework on what to measure, see our guide on MAP success metrics and KPI tracking.

Track three velocity metrics: workloads migrated per wave, workloads migrated per month, and average time per workload by strategy type. Plotting these metrics over time reveals whether the team is accelerating (normal), plateauing (needs intervention), or decelerating (a problem). Deceleration usually indicates team fatigue, accumulation of complex workloads in later waves, or unresolved technical debt from earlier waves.

Frequently Asked Questions

Can a MAP engagement be paused and resumed?

Yes, but it is not advisable. Pausing loses team momentum, and staff may be reassigned to other projects. MAP credits have utilization windows, so pausing can result in expired credits. If a pause is unavoidable, document all in-progress work and maintain the cloud foundation to avoid rework on resumption.

How many workloads should be in the first migration wave?

The first wave should contain 5–10 low-risk, well-understood workloads. These serve as learning opportunities. Common first-wave candidates include static websites, development environments, and non-production databases. Avoid migrating business-critical or customer-facing systems in wave one.

What if the migration takes longer than the MAP credit window?

Contact your AWS account team early if the timeline is extending. In some cases, credit windows can be adjusted. More commonly, accelerate the migration of high-spend workloads to maximize credit consumption within the original window. Your migration partner can help restructure wave plans to optimize credit utilization timing.