Manage your cloud migration project timeline with a Gantt chart. Plan assessment, workload prioritization, migration waves, testing, and cutover with clear phase dependencies.
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.
| 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 |
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.
Each wave gets its own section in the chart with sub-rows for:
The wave sign-off milestone gates the next wave. Never start Wave 2 before Wave 1 is signed off.
Cloud migrations have a parallel track that's separate from workload migration: the cloud infrastructure itself.
Add a swim lane for:
These must be ready before Wave 1 starts. Draw dependency arrows from "Network connectivity complete" to "Wave 1 start."
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.
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.
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.
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+ ◆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.