Cloud Migration Roadmap Template: Waves, Workstreams, Example
6 min read ยท 2026-10-08
A cloud migration roadmap template lays out how you move applications and data from on-premises or colocation into AWS, Azure, or Google Cloud in a controlled order: discover what you have, choose a migration strategy per workload, build a secure landing zone, migrate in waves, then optimize. The six-month template below fits a typical first major migration of a portfolio of tens to low hundreds of workloads.
It is written for infrastructure leads, cloud architects, and IT program managers. You will find the phases, the workstreams that need to run alongside the technical moves, an example from a company exiting a data center, and a routine for keeping wave plans current as discovery reveals surprises.
The roadmap at a glance
Goal: Migrate the prioritized application portfolio to the cloud within six months with no unplanned outages and a clear cost baseline. Duration: 6 months
Discovery and Assessment (Weeks 1-4)
Know every workload, dependency, and constraint before committing to migration dates.
- Run automated discovery tooling to capture servers, utilization, and network dependencies.
- Interview application owners about business criticality, data sensitivity, and downtime tolerance.
- Assign each workload a strategy using the 7 Rs: rehost, replatform, refactor, and others.
- Build a total cost of ownership comparison using current and projected cloud costs.
- Flag licensing, compliance, and data residency constraints that limit options.
Milestone: A migration portfolio lists every workload with an owner, strategy, and dependency group.
Landing Zone (Weeks 5-8)
Build a secure, governed cloud foundation that every migrated workload will use.
- Design account or subscription structure, network topology, and connectivity to on-premises.
- Provision the landing zone with infrastructure as code using Terraform or native tooling.
- Integrate identity with the corporate directory and enforce least-privilege roles.
- Configure logging, monitoring, backup policies, and guardrails for security baselines.
- Define tagging standards so costs can be allocated by application and team.
Milestone: A pilot workload deploys into the landing zone and passes a security review.
Pilot Wave (Weeks 9-11)
Migrate a small, low-risk group of workloads to validate tooling and runbooks.
- Select three to five workloads with few dependencies and tolerant owners.
- Write cutover runbooks with rollback criteria and timing for each step.
- Replicate servers or data using the provider's migration service or a third-party tool.
- Run user acceptance and performance tests before switching DNS or traffic.
- Hold a retrospective and update runbooks with lessons learned.
Milestone: Pilot workloads run in production in the cloud with source systems ready to decommission.
Migration Waves (Weeks 12-22)
Move the remaining portfolio in dependency-aware waves at a sustainable pace.
- Group workloads into waves by dependency cluster and business calendar constraints.
- Schedule cutovers outside peak business periods agreed with application owners.
- Migrate databases with replication to keep downtime windows short.
- Track each wave on a dashboard showing status, blockers, and rollback events.
- Decommission source servers promptly to stop paying for both environments.
Milestone: All in-scope workloads are live in the cloud and source hardware is scheduled for retirement.
Optimize and Operate (Weeks 23-26)
Right-size the new environment and hand over to a sustainable operating model.
- Right-size instances using actual utilization data collected after migration.
- Purchase commitments such as savings plans or reservations for steady workloads.
- Set budgets, anomaly alerts, and monthly FinOps reviews with application owners.
- Document operational runbooks and on-call responsibilities for cloud services.
- Shortlist replatform or refactor candidates for the next roadmap cycle.
Milestone: A monthly cloud cost report by application is reviewed with owners and trends are tracked.
Who This Template Is For
Use this template if you are planning a data center exit, a hardware refresh avoidance, or a consolidation of scattered cloud experiments into a governed environment. It works best for portfolios where most workloads will be rehosted or replatformed in the first pass, with deeper refactoring planned later.
If you are building a new cloud-native product, you need a product roadmap, not a migration roadmap. And if you have only a few workloads, compress the phases: discovery and landing zone can happen in a couple of weeks, but do not skip them.
Workstreams Beyond the Technical Moves
Server moves are only one lane. Migrations slip most often because security approval, finance, or application teams were brought in too late. Put these workstreams on the roadmap explicitly so their work has dates and owners.
Each workstream should have deliverables tied to phases. For example, security must approve the landing zone before the pilot wave, and finance must agree on the cost allocation model before optimization reviews start.
- Platform Engineering: landing zone, networking, infrastructure as code.
- Application Migration: wave planning, runbooks, cutovers, testing.
- Security and Compliance: guardrails, identity, audit evidence.
- FinOps: cost baseline, tagging, commitments, budgets.
- Operations and Skills: monitoring, on-call, training and certifications.
- Communications: change windows, stakeholder updates, user notices.
Example: Exiting a Colocation Facility
Picture a company with around 120 virtual machines in a colocation facility whose contract ends in nine months. Discovery shows most servers are lightly used, a few run a legacy ERP with a large SQL Server database, and several file shares hold sensitive HR data. Strategy assignment rehosts most VMs, replatforms the databases onto a managed service, and retires a set of unused servers outright.
The landing zone uses separate accounts for production, non-production, and shared services. The pilot wave moves internal tools first. Later waves are timed around month-end close so finance systems never cut over during reporting. After migration, right-sizing cuts instance sizes for many servers that were provisioned generously on-premises.
Choosing a Migration Strategy per Workload
The 7 Rs framework gives you a shared vocabulary: retire, retain, rehost, relocate, repurchase, replatform, and refactor. Assign one per workload during discovery and record why. Rehost is fastest but carries on-premises inefficiencies into the cloud. Refactor delivers the most long-term benefit but takes the longest and needs engineering capacity.
A practical rule is to rehost or replatform under deadline pressure, then revisit candidates for refactoring once workloads are stable. Retiring unused applications is the cheapest migration of all, so push owners hard to justify everything on the list.
Keeping the Roadmap Up to Date
Wave plans change constantly as discovery uncovers hidden dependencies or owners request new dates. Review the wave schedule weekly with migration leads and monthly with stakeholders. Keep a visible change log so moved workloads are explained rather than silently rescheduled.
After each wave, update velocity assumptions: how many workloads you actually migrated per week and how often rollbacks occurred. Use those real numbers to re-forecast the remaining waves. If the forecast breaks a hard deadline, raise it early and adjust scope by moving low-priority workloads to a later phase.
Common mistakes to avoid
- Migrating before mapping dependencies breaks applications at cutover; run automated discovery and validate dependencies with owners first.
- Building workloads directly without a landing zone creates security and cost sprawl; finish the governed foundation before the pilot wave.
- Rehosting everything at on-premises sizing inflates cloud bills; right-size using post-migration utilization data.
- Skipping rollback criteria turns small issues into long outages; write explicit go and no-go checkpoints into every runbook.
- Leaving source systems running for months doubles costs; schedule decommissioning as part of each wave.
- Treating training as optional leaves operations teams unable to support the new platform; plan certifications and hands-on labs alongside the waves.
Frequently asked questions
What are the phases of a cloud migration?
Most methodologies, including the AWS, Azure, and Google Cloud frameworks, follow a similar arc: assess the portfolio, mobilize with a landing zone and pilot, migrate in waves, then optimize and operate. This template follows that arc over six months, with explicit milestones for each phase so progress can be checked rather than assumed.
What are the 7 Rs of cloud migration?
Retire, retain, rehost, relocate, repurchase, replatform, and refactor. Each describes a different treatment for a workload, from switching it off to rewriting it as cloud-native. Assigning one per workload during discovery lets you estimate effort, sequence waves, and explain to stakeholders why some applications move quickly while others are deferred.
How do I decide which applications to migrate first?
Start with workloads that have few dependencies, low business criticality, and cooperative owners. They validate your tooling and runbooks with limited risk. Then move dependency clusters together so applications that talk to each other heavily stay close. Save the most complex, critical systems for later waves when the team has practiced.
What is a landing zone in cloud migration?
A landing zone is the pre-configured cloud foundation workloads move into: account or subscription structure, networking, identity integration, logging, security guardrails, and tagging standards. Building it first, ideally with infrastructure as code, keeps every migrated workload consistent and avoids retrofitting security and cost controls later.
How do I control costs after migrating to the cloud?
Enforce tagging so costs map to applications and owners, right-size resources using real utilization, buy commitments for steady workloads, and schedule non-production environments to shut down outside working hours. Hold a recurring FinOps review where owners see their own costs and agree on actions.