Gantt Chart for Cloud Migration Projects

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.

Why Cloud Migrations Need Dependency Mapping

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:

Migrate both in the same batch (eliminates the circular dependency problem)
Create a temporary bridge (legacy interface that both services use during the transition window)
Refactor one service to break the circular dependency before migration

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.

Phase 1: Discovery and Assessment (Weeks 1–6)

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 name and business owner
Server count, CPU, RAM, storage, OS version
Inbound and outbound network connections (what does this application talk to?)
Current availability requirements (SLA, RTO, RPO)
Peak load periods (business hours only? 24/7? seasonal spikes?)
Dependencies on on-premise services that will not migrate (Active Directory, SMTP relays, network file shares)

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.

Phase 2: Architecture and Landing Zone (Weeks 5–10)

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:

Account structure: Single AWS account vs. multi-account organization (recommended for enterprises); Azure management groups and subscription structure; GCP project hierarchy
Networking: VPC/VNet design, IP address ranges, hybrid connectivity (Direct Connect, ExpressRoute, Cloud Interconnect), subnet segmentation
Identity: Azure AD integration, AWS IAM federation with on-premise IdP, GCP Identity, SSO strategy
Security baseline: GuardDuty / Defender for Cloud / Security Command Center enabled, logging to centralized SIEM, encryption requirements, patch management
Cost management: Budget alerts, tagging strategy (cost center, environment, application), Reserved Instance / Savings Plans purchasing authority

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.

Phase 3: Migration Waves (Weeks 10–40+)

Wave planning

Organize workloads into migration waves based on:

Dependency order — services without upstream dependencies migrate first
Risk — lower-risk, non-production workloads first; production last within each batch
Business criticality — high-criticality applications migrate in smaller batches with more testing time
Technical complexity — straightforward lift-and-shift workloads before refactor projects

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:

Backup/restore: Simple but requires extended downtime. Suitable for databases under 100 GB migrating during a maintenance window.
Replication-based migration (AWS DMS, Azure Database Migration Service): Continuous replication with minimal cutover window. Takes 1–3 weeks to set up, validate, and cut over. Recommended for databases over 100 GB or with strict availability requirements.
Storage migration: For very large databases (multi-TB), physical data transfer (AWS Snowball, Azure Data Box) is faster than network transfer. Add 2–4 weeks for device ordering, data loading, and import at the cloud end.

Each wave's Gantt structure

Each migration wave runs as its own sub-project within the master Gantt:

Wave planning and environment preparation (2 weeks)
Migration tool configuration (1 week)
Initial replication and validation in non-production (1–2 weeks)
Production cutover window (1–3 days depending on complexity)
Post-migration validation and hypercare (1–2 weeks)
Decommission planning for migrated source systems (starts after hypercare confirms stability)

Phase 4: Refactor Projects (Concurrent with Waves 1–2)

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:

Containerization (lift-and-shift to Kubernetes/EKS/AKS): 2–4 months per application
Database modernization (Oracle → Aurora PostgreSQL, MSSQL → Azure SQL): 3–6 months including application code changes
Monolith → microservices decomposition: 6–18 months, typically not completed during the migration project itself

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.

Phase 5: Hypercare and Optimization (Weeks X through X+8)

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:

Cost surprises: data transfer costs, Elastic IP charges, NAT Gateway traffic — these are often higher than modeled
Performance variances: applications that ran faster on bare metal may need instance right-sizing or caching layers
Configuration drift: security group rules that were too permissive during migration need tightening
Monitoring gaps: alerting thresholds calibrated for on-premise hardware need recalibration for cloud metrics

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.

Building the Master Gantt Chart

In gantt-chart.io, structure a cloud migration as a hierarchical project:

Top-level phases as summary rows: Discovery, Architecture, Wave 0, Wave 1–N, Refactor Projects, Hypercare, Decommission
Milestones at major gates: Landing zone approved by security, Direct Connect circuit live, Wave 0 cutover complete, Final wave cutover, Decommission complete
Cross-phase dependencies — Wave 1 cannot start before landing zone security approval; production waves cannot start before Wave 0 validates the process
Wave sub-charts — each wave detailed at the task level with cutover steps at day/hour resolution
Parallel tracks — refactor projects run as separate swim lanes with integration points at the dependency milestones

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.

FAQ

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.