How to Manage a Cloud Migration Project Timeline with a Gantt Chart
Why Cloud Migrations Run Over Schedule
Cloud migrations fail on timeline for two reasons: underestimated complexity and missed dependencies. The assessment says "lift and shift" but the database turns out to have 47 stored procedures that need rewriting. The network team isn't ready when the first migration wave starts. The cutover window was never confirmed with operations.
A Gantt chart doesn't prevent these surprises — but it creates a visible structure that surfaces them before they become incidents. When migration waves are mapped to calendar dates with explicit dependencies, a slip in one wave visually cascades to the next wave and to the cutover date. That makes replanning faster and keeps the full team synchronized.
Cloud Migration Project Phases
| Phase | Work | Typical Duration | Dependency |
|---|---|---|---|
| Discovery & Assessment | Inventory all workloads, classify by complexity | 2–4 weeks | None |
| Target Architecture | Design cloud landing zone, network, security baseline | 2–3 weeks | Assessment complete |
| Workload Prioritization | Sort workloads into migration waves by risk/complexity | 1 week | Architecture defined |
| Wave 1: Non-critical workloads | Dev/test environments, low-risk apps | 2–3 weeks | Architecture ready |
| Wave 2: Standard workloads | Production apps with moderate complexity | 3–4 weeks | Wave 1 validated |
| Wave 3: Complex workloads | Databases, stateful apps, legacy systems | 4–6 weeks | Wave 2 validated |
| Testing & Validation | Functional testing, performance baseline, security scan | Ongoing per wave | Per wave completion |
| Cutover | DNS cutover, decommission on-prem systems | 1–2 weeks | All waves validated |
| Post-Migration | Optimization, cost review, decommission old systems | 4+ weeks | Cutover complete |
Prerequisites
- Cloud provider selected and accounts provisioned
- Landing zone architecture decision made (or included as first task)
- Infrastructure team available for migration window
- Rollback plan defined for each wave before migration starts
- Change advisory board (CAB) approval windows confirmed
Building the Cloud Migration Gantt Chart
Step 1: Start with Discovery Output
You can't build an accurate migration timeline until discovery is complete. If you haven't done the assessment yet, create a short "pre-planning" section in the chart: Discovery → Architecture → Prioritization. Only after these three complete can you add realistic wave dates.
Open gantt-chart.io and create the chart with a placeholder note on wave tasks if discovery isn't done yet. Don't make up dates — add "TBD pending discovery" and set a date when discovery will be complete.
Step 2: Create Wave Sections
Each wave gets its own section in the chart with sub-rows for:
- Migration execution (the actual move)
- Functional testing
- Performance baseline
- Security validation
- Wave sign-off milestone
The wave sign-off milestone gates the next wave. Never start Wave 2 before Wave 1 is signed off.
Step 3: Add the Architecture and Networking Track
Cloud migrations have a parallel track that's separate from workload migration: the cloud infrastructure itself.
Add a swim lane for:
- Landing zone setup
- Network connectivity (Direct Connect, VPN, or peering)
- IAM and identity federation
- Monitoring and logging setup
These must be ready before Wave 1 starts. Draw dependency arrows from "Network connectivity complete" to "Wave 1 start."
Step 4: Pin the Cutover Window
Cutover is the highest-risk moment in a migration. It needs a confirmed change window, which often requires CAB approval weeks in advance.
Add a cutover milestone at the fixed change window date. Then check: do all three waves complete before that date? If not, the cutover date needs to move or the wave plan needs to accelerate.
Step 5: Add Decommission Tasks
On-premises decommission is always delayed because "the system is still running as a fallback." Put decommission tasks explicitly in the chart with a start date 30–60 days after cutover. Without a scheduled date, old systems run indefinitely.
Common Mistakes
Building the wave plan before discovery is complete. Wave 1 looks simple until you realize those "non-critical" apps have undocumented dependencies on a shared database. Discovery must be complete before wave dates are finalized.
Not validating each wave before starting the next. Running overlapping waves multiplies the blast radius of any issue. Wave 2 should not start until Wave 1 is fully tested and signed off.
Underestimating database migrations. Databases — especially those with stored procedures, triggers, linked servers, or character encoding edge cases — are the most common source of migration delays. Give them their own wave and double the time estimate.
Ignoring the network track. Cloud connectivity setup (Direct Connect provisioning, BGP configuration, firewall rules) can take 4–8 weeks. If this isn't in the chart as a separate track with a head start, it will delay Wave 1.
No rollback plan in the chart. Every wave needs a rollback procedure. Put it in the Gantt chart as a task that must be documented before the wave starts. "We'll figure out rollback if something goes wrong" is not a plan.
Template: 16-Week Cloud Migration
Pre-Planning
Discovery & Assessment |████░░░░░░░░░░░░░░░░░░░░░░░░░░░░| Weeks 1-3
Target Architecture |░░░░░░████░░░░░░░░░░░░░░░░░░░░░░| Weeks 4-5
Workload Prioritization |░░░░░░░░████░░░░░░░░░░░░░░░░░░░░| Week 6
Infrastructure Track
Landing Zone Setup |░░░░░░████████░░░░░░░░░░░░░░░░░░| Weeks 4-7
Network Connectivity |░░░░░░░░░░████████░░░░░░░░░░░░░░| Weeks 6-9
Monitoring + Logging |░░░░░░░░░░░░░░████░░░░░░░░░░░░░░| Weeks 8-9
Wave 1 (Dev/Test)
Migration Execution |░░░░░░░░░░████░░░░░░░░░░░░░░░░░░| Weeks 6-7
Testing & Validation |░░░░░░░░░░░░████░░░░░░░░░░░░░░░░| Weeks 8-9
Wave 1 Sign-Off Week 9 ◆
Wave 2 (Standard Prod)
Migration Execution |░░░░░░░░░░░░░░░░████░░░░░░░░░░░░| Weeks 10-11
Testing & Validation |░░░░░░░░░░░░░░░░░░████░░░░░░░░░░| Weeks 12-13
Wave 2 Sign-Off Week 13 ◆
Wave 3 (Databases + Legacy)
Migration Execution |░░░░░░░░░░░░░░░░░░░░░░████░░░░░░| Weeks 12-13
Testing & Validation |░░░░░░░░░░░░░░░░░░░░░░░░████░░░░| Weeks 14-15
Wave 3 Sign-Off Week 15 ◆
Cutover
DNS Cutover |░░░░░░░░░░░░░░░░░░░░░░░░░░░░████| Week 16
Decommission On-Prem Scheduled: Week 20+ ◆
Next Steps
Build your cloud migration timeline in gantt-chart.io. Start with discovery completion as the first milestone, then add your wave structure. Share with the infrastructure and operations teams to confirm wave readiness dates before committing to a cutover window.