Structure your AWS, Azure, or GCP migration timeline with a Gantt chart covering discovery, architecture, phased workload migration, and hypercare after go-live.
Cloud migrations look straightforward on a slide: move workloads to AWS, Azure, or GCP, reduce infrastructure costs, improve reliability. The reality is that most cloud migrations run 40–60% over their original timeline — not because the cloud is complicated, but because the dependencies between services, the organizational change management work, and the assessment gaps from discovery are underestimated from day one.
A Gantt chart built for a cloud migration does more than track tasks. It maps service dependencies that determine migration batch order, it makes the lift-and-shift vs. refactor trade-off visible at the timeline level, and it creates the shared reference that keeps cloud architects, application teams, security, networking, and business stakeholders synchronized across a project that can run 6–18 months.
This guide covers how to build a cloud migration Gantt chart, how to structure the migration batches, and the dependency patterns that cause most cloud migrations to slip.
A cloud migration is not a single project — it is a portfolio of related sub-projects that must execute in the right sequence. The order matters because applications depend on each other.
If your data warehouse depends on a legacy ETL pipeline running on an on-premise server, migrating the data warehouse before migrating the ETL pipeline (or rebuilding it as a cloud-native service) creates a broken dependency. If your web application connects to an on-premise Active Directory for authentication, migrating the application before setting up Azure AD or AWS IAM federation leaves users unable to log in.
These dependencies do not show up in a task checklist. They show up in a Gantt chart when you draw the predecessor lines — and a circular dependency between two services that were supposed to migrate in different batches becomes visible before it becomes a production outage.
Circular dependency detection
Before finalizing migration batch sequencing, build a service dependency map: a directed graph showing which application connects to which service. Import this into your Gantt chart as predecessor relationships.
When you find that Service A depends on Service B and Service B depends on Service A, you have a circular dependency. Resolution options:
Circular dependencies are common in monolithic systems and in applications that share databases. Finding them in the discovery phase costs 2–3 days. Finding them during cutover costs the migration window and potentially the project timeline.
Infrastructure inventory (weeks 1–2)
Document every server, application, database, and service in scope. For most mid-size companies (100–1,000 servers), this takes 2 weeks using a combination of automated discovery tools (AWS Application Discovery Service, Azure Migrate, CloudAmize) and manual interviews with application owners.
The inventory output for each workload:
Application dependency mapping (weeks 2–4)
Use network flow analysis to discover actual runtime dependencies — not what the architecture diagram says, but what traffic actually flows between systems. Tools: AWS Application Discovery Service agentless collector, Azure Migrate dependency analysis, or a purpose-built tool like Cloudscape or Dynatrace.
Dependency mapping reveals connections that nobody documented: a finance application making API calls to an HR system, a reporting database replicating from three application databases that were never mentioned in the app owner interview, a batch job running nightly on a server that has no application owner assigned.
Lift-and-shift vs. refactor assessment (weeks 3–5)
For each application in the inventory, make the migration strategy decision:
| Strategy | Description | When to Use | Timeline Impact |
|---|---|---|---|
| Rehost (lift-and-shift) | Move VM to cloud with minimal changes | Legacy apps with no cloud-native requirements | Fast: 2–8 weeks per batch |
| Replatform | Move to managed service (e.g., migrate MySQL to RDS) | Apps that benefit from managed services without code changes | Moderate: 4–12 weeks per batch |
| Refactor | Redesign for cloud-native architecture | Apps with scalability requirements, microservices targets | Slow: 3–12 months per app |
| Retire | Decommission — no migration needed | Duplicate apps, unused systems | Immediate savings |
| Retain | Keep on-premise | Apps with compliance constraints, high refactor cost, near-EOL | No cloud cost |
The strategic decision here is not just technical. A refactor requires budget, development time, and testing that a lift-and-shift does not. For a migration driven by data center contract expiration, refactoring everything is not an option — the deadline is fixed. Build the timeline around the realistic mix: typically 60–70% rehost, 20–30% replatform, 5–10% refactor.
Total cost of ownership analysis (weeks 4–6)
Size the cloud environment: map each server to an appropriate cloud instance type based on CPU, RAM, and storage utilization. Factor in reserved instance pricing (1-year or 3-year commitments reduce compute costs 30–40% versus on-demand). Include licensing costs: Windows Server and SQL Server licensing in the cloud is a significant variable — Azure Hybrid Benefit and AWS License Mobility can substantially reduce this cost if the organization has active Software Assurance.
The TCO analysis is not optional. It is a prerequisite for the business case that justifies the migration investment and gets project approval from finance.
Cloud landing zone design (weeks 5–8)
The landing zone is the foundational cloud infrastructure that all migrated workloads run on: account structure, networking, identity, security controls, monitoring, and cost management. Getting this right before migrating workloads is critical — retrofitting security controls or network architecture after workloads are running in production is expensive and disruptive.
Key decisions documented in this phase:
The landing zone must be fully deployed and validated before any production workload migration begins. Add 2–3 weeks of buffer for security review — most enterprises require sign-off from information security before production traffic touches the cloud.
Network connectivity (weeks 6–10)
For hybrid migrations where on-premise systems and cloud systems coexist during the transition (which is every migration of meaningful scale), network connectivity between the data center and cloud is on the critical path.
AWS Direct Connect, Azure ExpressRoute, and GCP Cloud Interconnect all require 4–12 weeks for physical provisioning. Order the circuit immediately when the architecture design is complete — this is the most common source of delay in cloud migration projects.
Bandwidth requirement: calculate based on the replication volume during migration (not just steady-state traffic). If you are replicating 20 TB of database data over a 2-week migration window, that is approximately 1.5 Gbps of sustained throughput. Size the circuit accordingly.
Wave planning
Organize workloads into migration waves based on:
Typical wave structure for a 200-server migration:
| Wave | Workloads | Approach | Duration | Environment |
|---|---|---|---|---|
| Wave 0 | Dev, test, QA environments | Rehost | 4 weeks | Non-production |
| Wave 1 | Low-criticality business apps | Rehost / Replatform | 6 weeks | Production |
| Wave 2 | Mid-criticality apps, shared services | Rehost / Replatform | 8 weeks | Production |
| Wave 3 | Core business systems, databases | Rehost + targeted refactor | 10 weeks | Production |
| Wave 4 | Mission-critical systems, ERP | Replatform + careful cutover | 12 weeks | Production |
Wave 0 (dev/test environments) is a dress rehearsal. It validates the migration tooling, the landing zone configuration, and the cutover process in an environment where failure has no business impact. Do not skip wave 0 by going straight to production.
Database migration specifics
Database migrations are the highest-risk component of any cloud migration. Options and timeline implications:
Each wave's Gantt structure
Each migration wave runs as its own sub-project within the master Gantt:
Applications selected for refactor run as parallel workstreams alongside the rehost waves. They move at their own pace and typically don't block other waves — unless a refactor application is a shared service that other applications depend on.
Common refactor patterns and timeline estimates:
For most migration projects, refactor work is scoped to 2–3 high-value applications and runs in parallel with the main migration. It should not be on the critical path.
Hypercare period
The 4 weeks following the final production wave cutover are hypercare: cloud operations team on-call, daily check-ins with application teams, and performance monitoring compared to on-premise baselines.
Expected issues in hypercare:
Decommission sequence
On-premise servers are decommissioned in reverse migration order: wave 5 systems decommission after wave 5 hypercare, then wave 4, and so on. Maintain on-premise infrastructure in a powered-off but recoverable state for 30 days after each wave's hypercare period ends. This provides a rollback option if a critical issue surfaces after hypercare closes.
The decommission plan drives cost realization — on-premise infrastructure costs (colocation fees, maintenance contracts, power) stop accruing only when equipment is decommissioned and the cage/rack is vacated.
In gantt-chart.io, structure a cloud migration as a hierarchical project:
Export the master Gantt as a shared reference for weekly steering committee reviews. For each meeting, advance completed tasks, flag tasks at risk, and update the critical path. A cloud migration that runs without a shared, visible timeline is managed by informal communication — which is why so many of them miss their dates.
How long does a cloud migration take?
A 50-server migration for a small company: 3–6 months. A 500-server enterprise migration: 12–24 months. The key variables are dependency complexity, application refactor requirements, and how quickly the landing zone can pass security review. Single-tenant SaaS migrations and data-center-exit projects with fixed deadlines typically compress these timelines by running more waves in parallel with larger teams.
Should we refactor before or during the migration?
Unless the refactor is required to run in the cloud at all (for example, an application with a Windows-only dependency that you're moving to a Linux-based cloud service), defer refactoring until after the rehost migration is complete. Combining a refactor with a migration doubles the failure surface. Get to the cloud first, then optimize.
How do we handle compliance requirements during migration?
Compliance requirements (PCI DSS, HIPAA, SOC 2, ISO 27001) affect landing zone design, not migration sequencing. Build compliance controls into the landing zone before migrating any regulated workload. Most cloud providers have compliance-ready reference architectures — use them as the starting point. Schedule a compliance review milestone in the Gantt chart after landing zone completion and before the first regulated workload migrates.
What's the biggest risk to timeline?
Network circuit provisioning. Direct Connect, ExpressRoute, and Cloud Interconnect require 4–12 weeks for physical installation by the carrier. This is the most common single cause of migration timeline delays because teams order the circuit 2–3 weeks into the project after architecture design is "complete" — when they should have started the order in week 1 based on the approximate bandwidth requirement.