What happens when a company announces a “cloud-first” strategy, buys training, and then discovers eighteen months later that half its workloads are still sitting in a data center nobody wants to pay for? That gap between ambition and execution is exactly what a cloud migration roadmap exists to close. Not a slide deck. Not a vendor pitch. A working plan that names what moves, in what order, who owns it, and how anyone will know it worked.
This article walks through how to build one: the phases, the decisions that actually matter, the mistakes that show up again and again, and how to keep the roadmap alive once the first wave of workloads has landed.
What a cloud migration roadmap actually is
A roadmap is a sequenced plan that connects business intent to technical execution. It answers four questions in order: why are we moving, what are we moving, how will each thing move, and how will we run it afterward. Everything else, from budget spreadsheets to org charts, hangs off those four. (9481.org)
The word “cloud” itself deserves precision. The most widely used definition comes from NIST SP 800-145, the NIST definition of cloud computing, which sets out five essential characteristics, three service models (IaaS, PaaS, SaaS), and four deployment models. That sounds academic until you are in a planning meeting where one person means “rent virtual machines” and another means “rewrite everything as serverless functions.” Getting the vocabulary aligned early prevents months of talking past each other.
A useful companion is NIST SP 800-146, the cloud computing synopsis and recommendations, which lays out benefits, risks, and decision factors. It is dated, but the decision framework holds up. Read it during the assessment phase, not after.
Start with the inventory, not the architecture
The single most common failure mode is skipping inventory. Teams jump straight to designing target-state architecture for their flagship application while nobody has counted the batch jobs, the file shares, the licensing servers, or the mystery VM that three people log into and nobody owns.
Before any target-state design, build a workload inventory with at least these fields per workload: owner, business function, criticality tier, dependencies, data classification, current cost, and known technical debt. A structured approach to what to inventory before a cloud migration saves weeks of rediscovery later, because the inventory becomes the source of truth for wave planning.
Practical tips that hold up in real programs:
- Interview the people who get paged at 2 a.m., not just the architects. They know the dependencies that never made it into a diagram.
- Count the integrations, not just the servers. Most migration delays come from a forgotten interface to a payroll system or a partner’s SFTP drop.
- Flag anything with a hardware dependency, a dongle, or an unusual network appliance. Those workloads have a habit of derailing wave plans.
- Record the data classification for every store. It determines which security and compliance gates apply, and it changes the migration pattern.
Choosing a migration pattern for each workload
Once the inventory exists, every workload needs a pattern. The most cited taxonomy is the “6 Rs,” documented in AWS’s explanation of the six application migration strategies: rehost, replatform, repurchase, refactor, retire, and retain. Some organizations add a seventh, relocate, for moving VMware estates to a cloud-based virtual environment without changing anything else.
A fair warning: sources disagree about whether the canonical list has six or seven entries, and about who first formalized it. Pick a variant, state it in the roadmap, and move on. The taxonomy is a communication tool, not a standard.
| Pattern | What it means | Typical fit | Watch out for |
|---|---|---|---|
| Rehost | Lift and shift, minimal change | Legacy apps with unclear internals, tight deadlines | Carrying technical debt and oversized instances into a new bill |
| Replatform | Small changes to use managed services | Databases, app servers, message queues | Hidden coupling that breaks when the managed service behaves differently |
| Repurchase | Move to a SaaS product | Commodity functions like HR, email, CRM | Data migration and integration work often underestimated |
| Refactor | Rearchitect for cloud-native patterns | Differentiating systems with real business value | Cost and time overruns; needs strong engineering leadership |
| Retire | Turn it off | Duplicate or unused systems | Political resistance from owners |
| Retain | Keep where it is, for now | Latency-sensitive, regulated, or not worth moving | “For now” quietly becomes forever |
The pattern mix is the roadmap’s center of gravity. A program that is 80 percent rehost will hit its first milestone fast and then spend years paying down debt. A program that is 80 percent refactor will look brilliant in year one and may never finish. Most healthy roadmaps start rehost-heavy for speed and shift toward replatform and refactor as the team matures.
Phases: what happens, in what order
Vendor methodologies differ in phase counts, and no single standard exists. The three-phase structure used in AWS’s Migration Acceleration Program, assess, mobilize, and migrate-and-modernize, is a reasonable skeleton. Many organizations add an explicit optimize-and-operate phase at the end, which is where most of the long-term value sits.
Phase 1: Assess
Goals: inventory, business case, readiness assessment, risk register, and a first wave plan. Deliverables should include a cost model that compares current run rate with projected cloud spend, including the items people forget: egress, support plans, licensing changes, and the productivity dip during cutover.
Security and compliance belong here, not in phase three. Frameworks such as the NCSC cloud security guidance collection, which sets out principles for secure cloud adoption, give a structured way to ask hard questions early. Public-sector programs often have a formal authorization gate; in the US, FedRAMP is the government-wide program that authorizes cloud services, and it can dominate a roadmap’s timeline if it applies to you.
Phase 2: Mobilize
Goals: build the landing zone, the operating model, and the team. This is where the roadmap stops being a document and becomes a capability.
Concretely, mobilize means: account and network structure, identity and access design, logging and monitoring, a CI/CD pipeline that can deploy to the new environment, a cost tagging standard, and a runbook for the first cutover. It also means deciding how workloads get split across accounts or subscriptions, a decision that shapes blast radius, billing, and permissions for years. A clear method for when to split workloads across cloud accounts prevents the classic end state where one production account contains everything and nobody can safely change anything.
Common mistake in this phase: treating the landing zone as a one-time build. It is a product with an owner, a backlog, and users.
Phase 3: Migrate
Goals: execute waves. Each wave should be small enough to finish in weeks, not quarters, and should include a mix of easy wins and one genuinely hard workload so the team learns.
Every wave needs the same checklist: pre-migration testing, a rollback plan that has actually been rehearsed, a communication plan for business users, a defined success metric, and a decommission date for the old system. That last item is where savings come from. Organizations routinely leave the old environment running “just in case” and then wonder why the cloud bill sits on top of the data center bill instead of replacing it.
Phase 4: Optimize and operate
Goals: cost governance, performance tuning, reliability work, and continuous modernization. Cost management is not a spreadsheet exercise; it is a cycle. The FinOps Framework describes an iterative Inform, Optimize, Operate loop that gives a roadmap a durable structure for cost accountability. A clearer way to track cloud data transfer costs is worth building into that loop early, because network charges are the line item that most often surprises finance teams after cutover.
Sequencing: how to order the waves
Wave order is a strategic decision, and there is no universal right answer. Three sequencing logics dominate:
- Value-first. Move the workloads with the clearest cost or agility payoff. Good for building momentum and executive support.
- Risk-first. Move the hardest, most constrained workloads early while patience and budget are plentiful. Good for regulated environments.
- Dependency-first. Move foundational services (identity, networking, data) before the applications that rely on them. Good for avoiding rework.
Most programs blend all three. A practical heuristic: put two or three low-risk, high-visibility workloads in wave one to prove the operating model, then a hard one in wave two to find the gaps while the program still has political capital.
Two sequencing traps deserve naming. First, migrating a shared database too early strands every application that depends on it. Second, migrating a shared database too late blocks everything else. The resolution is usually a deliberate intermediate step: replicate, dual-run, then cut over application by application.
Governance: keeping the roadmap honest
A roadmap without governance becomes fiction within a quarter. The minimum viable structure is small: a steering group that meets monthly and can make funding and priority calls, a technical review forum that approves patterns and exceptions, and a single owner for the roadmap document itself.
Metrics matter more than meetings. Track migration velocity (workloads per wave), percentage of estate migrated by criticality tier, cost variance against forecast, incident rate in the new environment versus the old, and decommission rate. That last one is the honest measure. If old systems are not being switched off, the migration is not delivering its financial case, whatever the dashboards say.
Roadmaps also need to survive contact with the outside world. Provider announcements, region launches, and regulatory changes all shift plans. Knowing how to read a cloud region announcement helps teams judge whether a new location actually changes their latency, residency, or resilience options, or whether it is just marketing. Similarly, reading an enterprise roadmap with deployment in mind keeps the migration plan aligned with product and platform commitments instead of drifting into a parallel universe.
The mistakes that show up again and again
After enough programs, the failure patterns become predictable:
- No decommission plan. The old estate lingers and the business case evaporates.
- Underestimating data gravity. Moving terabytes is a project; moving petabytes with tight change windows is a program.
- Ignoring the people side. Retraining, role changes, and on-call rotations are roadmap items, not afterthoughts.
- Treating security as a gate at the end. It turns into a rework tax.
- No cost ownership. Without tagging and accountability, spend drifts upward quietly.
- Planning to the last detail. A roadmap that specifies month 18 in weekly increments is theater. Plan the next two waves precisely and the rest at a coarse grain.
What actually works in practice is unglamorous: a maintained inventory, a pattern decision per workload, small waves with rehearsed rollbacks, real decommission dates, and a governance forum with authority to say no.
Conclusion
A cloud migration roadmap is less a prediction of the future than a disciplined way of making the next decision. It starts with an honest inventory, assigns a deliberate pattern to every workload, sequences waves so the team learns without betting the business, and builds the landing zone and operating model before the pressure hits. The organizations that finish are rarely the ones with the most elegant target architecture. They are the ones that decommissioned the old systems, kept cost ownership in the team, and treated the roadmap as a living document with an owner and a review cadence. If you are starting now, the best first move is not a vendor meeting. It is a spreadsheet, a few honest interviews, and a short list of workloads you can move in the next ninety days.
Frequently asked questions
How long does a cloud migration roadmap take to build?
The roadmap document itself usually takes four to eight weeks for a mid-sized estate, assuming the inventory exists or can be assembled quickly. The migration it describes typically runs one to three years, depending on estate size, regulatory constraints, and how much refactoring is planned. Building the roadmap and executing the first wave in parallel is common and usually wise, because real migration work surfaces gaps that planning alone will not.
How many phases should a roadmap have?
There is no standard. Three-phase models (assess, mobilize, migrate) and five-phase models that add plan and optimize are both defensible. What matters is that each phase has entry criteria, exit criteria, and named owners. A phase without a definition of done is just a heading.
Should we rehost first or refactor first?
Most programs should rehost or replatform first to build momentum, establish the operating model, and capture early savings, then shift toward refactoring the systems that genuinely differentiate the business. Refactoring everything from day one is slow and expensive; rehosting everything and never refactoring leaves you with the same technical debt, now billed monthly.
Who should own the migration roadmap?
One accountable owner, typically a director-level engineering or platform leader, with a small steering group for funding and priority decisions. Ownership by committee produces documents nobody updates. The owner should be close enough to the technical work to know when a wave is slipping and senior enough to reallocate resources when it does.
How do we handle compliance and security during migration?
Bring security and compliance into the assessment phase, not the final gate. Map each workload’s data classification to the controls that apply, decide early whether a formal authorization is needed for your sector, and build the evidence collection into the migration pipeline rather than treating it as a separate project. Rework caused by late security review is one of the most predictable cost overruns in cloud programs.
What is the most common reason cloud migrations stall?
Failure to decommission. Teams migrate successfully, keep the old environment running for reassurance, and end up paying for two estates. The financial case collapses, executive support fades, and the program loses momentum. Setting a decommission date at the start of each wave, with a named owner, is the simplest and most effective antidote.
