The majority of cloud migrations fail for causes that are not related to the provider selection. These initiatives usually fail because teams start shifting workloads without a defined strategy. They discover problems with data integrity, unplanned downtime, and high costs only after it is too late to resolve them through proper planning.
A cloud migration roadmap provides a stepwise plan for transitioning to the cloud. It starts with a readiness assessment and proceeds through execution. The process involves auditing the existing environment and choosing a strategy for each workload, for example rehosting or refactoring. It also requires designing the target architecture and the governance structures. The migration is carried out in waves and includes a tested rollback plan for each stage.
Skipping any migration stage will likely cause the process to fail and necessitate a recovery project.
A migration roadmap does more than just keep a project schedule. It forces you to tackle difficult issues at the beginning of the process. You need to decide which workloads to move first, confirm the actual state of your data, and ensure your organisation can manage cloud infrastructure on a daily basis. If you neglect these requirements, your company will probably pay for both on-premise and cloud environments at the same time, with neither system operating correctly.
Shipshape Data constructs data foundations and cloud platforms for enterprise clients. This guide includes the information we think teams need before beginning a project. It addresses each stage of planning a cloud migration, such as the initial environment audit and the rollback plan. The detail supplied is enough for you to create a complete roadmap.
Components of a cloud migration roadmap
Many teams treat migration planning as a purely technical task. They select a strategy and a provider, then start moving servers. Successful migrations are run as organisational programmes that incorporate commercial and operational factors together with technical work. You need to define the questions your roadmap must answer before planning any specific migration waves.
Business objectives and scope
Link the migration to measurable outcomes. State clearly whether the goal is to reduce infrastructure costs, improve reliability, or build a cloud-native platform for AI and analytics. Record these objectives. If you fail to link the migration to specific metrics, decisions will rely on personal opinions. These opinions are hard to justify during budget reviews.
You need to apply discipline to the project scope. Determine at the start which workloads, applications, and datasets are included or excluded, and record the reasons for those decisions. List the legacy systems you plan to retire and the ones you will move. Identify any systems that must stay on-premise because of contracts or technical debt to avoid accidental migration attempts later. Incorrect scoping at the start causes scope creep during the project. This often causes migrations to exceed both their budgets and schedules.
Technical inventory and dependency mapping
You need to create an inventory of your items before beginning the planning process.
The roadmap requires a complete inventory of the current environment: servers, databases, storage, networking, and the applications that depend on them. Dependency mapping shows which systems are coupled, preventing you from moving one workload and silently breaking an upstream component that never appeared in a spreadsheet.
Technical debt emerges during this process. Older applications may need refactoring to operate correctly in a cloud environment. Databases with many stored procedures often require schema adjustments to ensure a successful migration. Identifying these requirements during the planning phase is more effective than doing so during a migration wave when the schedule is already public.
Migration strategy, governance, and risk controls
The roadmap requires a defined approach for each workload category (rehost, replatform, refactor, replace, or retire, more on that below), the cloud model you target, and a governance structure that owns decisions for the programme length.
Risk controls are not optional extras.
Each wave must include a rollback procedure, data validation checkpoints, and an escalation path. These must be set up before any issues arise, not during an incident. A designated person must be responsible for each decision, and the approval process must be documented. The business needs to know in advance how you will communicate an outage or a delay. Implementing a governance layer keeps the migration controlled rather than turning it into a recovery project that consumes the rest of the quarter.
Step 1: assess readiness, inventory, and constraints
You need to establish an accurate view of your current environment before creating a roadmap. This step includes identifying existing assets, determining which systems are ready for migration, and documenting all relevant constraints. If you skip this process, you risk migrating obsolete systems or facing dependency failures that were not identified during the planning phase.
Conduct a complete audit of the environment
Catalogue every asset in scope: servers, databases, storage systems, and the applications that rely on them. Discovery tooling can automate much of this, but you should validate the output manually for anything business-critical; automated scans miss context that a person would catch in ten seconds. AWS, Azure, and Google Cloud all provide migration assessment tools that crawl your environment and surface dependency maps, utilisation data, and compatibility flags, which is a reasonable starting point even if you end up correcting half of what it reports.
After creating the inventory, categorise each workload by its complexity and business criticality. Use these categories to set the migration priority. A CRM system with medium complexity and high criticality should be migrated in a middle wave once the process is established. An internal reporting database with low complexity and medium criticality is a good candidate for the first wave. This lets you test the process with lower stakes. A legacy ERP system with high complexity and high criticality should wait until the third wave or later. This ensures the migration process is fully tested on less critical systems first.
Automated discovery tools often miss shadow IT. Examples include databases created by marketing teams on unofficial servers, nightly reporting scripts that read from production replicas, or weekend integrations that finance teams now rely on. These assets do not appear on official registers unless they are specifically sought. These undocumented dependencies often cause system failures when they are unexpectedly interrupted. You should interview the people who use these systems rather than only speaking with administrators.
Evaluate organisational and technical readiness
Skills gaps and team capacity derail migrations as often as any technical problem. Honestly assess whether your internal team can run cloud infrastructure day to day, or if you need outside support before the first workload moves. Document the security and compliance requirements specific to your industry as well: data residency rules, encryption standards, audit logging obligations. Capture these now, because they shape the platform design in Step 3, and discovering them late leads to expensive rework.
Readiness assessment determines whether a migration stays on schedule or needs a recovery project. It goes beyond a routine administrative task.
Step 2: select your migration strategy and cloud model
After finishing the inventory, you need to decide how each workload will be moved and which cloud model will support your operations. These choices set the architecture, cost, and engineering effort needed for each phase. Making these decisions correctly now is more cost-effective than redesigning a workload after it is running in the cloud.
Six strategies for migrating workloads
The industry uses the "6 Rs" as a standard framework to decide the strategy for each workload:
- Rehost: lift and shift onto cloud virtual machines without changes. Fast and suitable for simple applications on a tight timeline.
- Replatform: move the application with minor optimisations. This usually involves moving databases and web servers to managed services to obtain benefits without a full redesign.
- Refactor: Redesign the application for a cloud-native architecture. This approach is appropriate for high-priority applications that need significant scalability.
- Repurchase: replace the current system with a SaaS alternative when a modern equivalent is available.
- Retire: Decommission the system. Most environments have redundant or unused systems that stay active because no one has discussed turning them off.
- Retain: keep this on-site for now. This is usually done because compliance requirements or high security risks prevent migration at this stage.
Assign a strategy to each workload in the inventory. Document the reasoning for each choice to give the delivery team clear instructions for their work.
Select your cloud model
Public cloud providers such as AWS, Azure, or Google Cloud suit most enterprise workloads. These platforms provide many managed services for building applications. Hybrid or multi-cloud models are more complex, yet they are required when regulations mandate keeping data on-premise or when you must avoid vendor lock-in for critical systems. You should select your model before starting the platform design in Step 3. This choice defines your networking architecture, identity management, and cost structure. Changing the model later is costly. If your operations cover multiple regions, confirm that your provider meets the data residency requirements for your industry and location before committing to the service.
Step 3: design the target platform and governance
With strategy and cloud model settled, the roadmap proceeds to platform design. This step converts the decisions from Steps 1 and 2 into a concrete target architecture that your engineering team can build against, and it establishes the governance that controls how resources are provisioned, accessed, and monitored for the rest of the programme. Skipping this causes workloads to move into inconsistent configurations, security gaps that appear later, and infrastructure costs that are difficult to explain.
Define your target architecture
The target architecture defines networking topology, compute configuration, storage tiers, and managed services for each workload category. Begin with the landing zone, the pre-configured cloud environment that enforces security baselines and naming conventions before the first workload arrives. Both AWS and Microsoft Azure publish landing zone frameworks that you can adapt, saving weeks.
Document your technical decisions in a simple format. Do not rely solely on memory. For example, document that identity management uses Azure AD or AWS IAM for centralised access control. State that the network follows a hub-and-spoke topology to manage segmentation and traffic. Note that storage is split between object storage and a managed database to balance cost and performance. Finally, record that logging is sent to a single central sink to provide one location for incident reviews.
Create governance policies and access controls
Governance defines who may create resources, what spending limits exist, and how policy breaches are identified before they cause problems. Use the policy tools from your cloud provider, such as Azure Policy or AWS Service Control Policies, to automatically enforce these limits. Do not rely on individuals to follow the rules manually. Clearly assign responsibility for each environment-development, staging, and production-and set up budget alerts from the start. This ensures a cost increase is noticed within a week, rather than on the monthly bill, when fixing it becomes harder.
Model your costs before you commit
Most companies that migrate to the cloud without first modelling their expenses end up surprised by the cost. This usually occurs because they did not perform a proper comparison with their on-premise expenses. It is easy to underestimate on-premise costs because they are often hidden in depreciated hardware, facility fees, and staff labour that is not itemised. Cloud costs present the opposite issue. Every expense appears on a bill, making the total seem larger even if the actual cost is similar to or lower than previous spending.
Build a per-workload cost model before migrating anything, using each provider's pricing calculator against your actual usage data from the environment audit, not rough estimates. Include the line items that are often forgotten: data egress charges, reserved instance commitments, storage tier costs for anything that needs to stay hot, and the licensing terms for any software you are bringing with you. Reserved capacity and committed-use discounts can reduce the run rate significantly, but only if you are confident in the usage pattern, and confidence at this stage usually means you have already completed Step 1 properly.
Step 4: sequence waves, plan data moves, and build in rollback
The last structural piece of the roadmap is the order workloads move in and how the data gets there safely. Wave sequencing stops you migrating a high-risk system before you've proven the process on something simpler, and a documented rollback plan turns a failed migration into a recoverable setback instead of a production outage that lands on someone's desk at 2am.
Sequence migration waves
Create the wave plan based on business risk and workload complexity rather than speed. Wave 1 should include low-complexity, non-critical systems, such as internal reporting databases and development environments. These allow the team to test the process and build confidence without significant risk. Do not move business-critical or technically complex workloads until the landing zone, tooling, and operational procedures have been verified in the initial waves. A typical schedule follows this structure: Wave 1 includes low-complexity systems during the first month. Wave 2 includes medium-complexity workloads, such as CRM and collaboration tools, during the following month. Wave 3 and later phases handle high-complexity, high-stakes systems like ERPs and data warehouses after the previous stages have succeeded.
Plan data migration and rollback
Data migration needs its own plan, distinct from the supporting application migration. For each dataset, record the method of transfer, whether database replication, bulk export, or a managed migration service, and list the validation steps to verify data integrity after the transfer. Also note the maximum data loss you can tolerate. Validation must be specific: ensure row counts match between source and target systems, check checksums on key tables, and produce a reconciliation report for review. Before each migration wave, define a rollback trigger, the specific condition that starts a revert, and record the exact rollback steps in advance.
Assign a named rollback owner and a tested procedure for each wave. Execute a dry-run migration for Wave 1 in a staging environment prior to altering production, and review the outcomes with the team before committing to the live cutover. This time investment is minor compared to the impact of a failed first live wave on the business.
Where migrations fail
Most of the migrations we are called into after the fact did not fail because of the technology. They failed because someone skipped Step 1, or because the governance layer was added after workloads had already landed, or because a wave moved a system whose dependencies were not properly mapped. The pattern repeats often enough that it is worth stating plainly: the technical work in a cloud migration is rarely the hard part.
Sequencing, governance, and honest readiness assessment are.
The other common pattern is the migration that never really finishes. Workloads move, the project gets marked complete, and eighteen months later the organisation is still paying for on-premise capacity nobody decommissioned, because retirement was never assigned to a wave. Build retirement into the plan from Step 1, with the same rigour as the workloads you're actively moving, or it simply won't happen.
Next steps
A solid cloud migration roadmap guides you through assessment, strategy, platform design, and wave sequencing in that order, so each phase builds on the previous. Rushing the sequence or skipping directly to selecting a provider is how a manageable migration becomes a costly recovery project.
The first step is to assess your current data and infrastructure before moving any workloads. Shipshape Data maps the actual state of an enterprise's data and platforms. We inform clients what they must fix before starting a migration. If you want an accurate assessment of what your cloud migration requires, talk to us. We will provide a report based on your specific environment instead of a vendor demonstration.
Turning a roadmap like this into a real migration plan is exactly what our data migration service does, phased, reconciled, and with a rollback path.
Consult our guide to the eight drivers behind a migration quote before you set a budget for each stage.
A specific plan is required for models that read migrated tables. Our guide on moving models across data platforms and re-validating them provides the instructions for this.
If your migration includes choosing a target platform, a two-week method for deciding between Fabric and Snowflake sets out what to test.
Frequently asked questions
Public cloud vs private cloud: what is the difference?
Public cloud runs entirely on a provider's infrastructure, AWS, Azure, or Google Cloud, giving you the widest range of managed services without owning any of the hardware. Private cloud is dedicated infrastructure, hosted on your premises or by a third party, and it suits regulated industries with strict data residency rules that public cloud cannot satisfy on its own.
Azure vs AWS vs Google Cloud: how do they compare?
These three public cloud models suit most enterprise workloads. Choosing between them usually depends on your current business commitments rather than on a comparison of specific features. You should verify that your preferred provider meets the data residency requirements for your industry and region before committing, since changing providers later is a costly process.
Google Cloud vs AWS: which should you choose?
Choosing between Google Cloud and AWS is rarely about raw capability, as both provide the managed databases, compute, and storage an enterprise migration needs. The roadmap treats this as a cloud model decision made in Step 2, before platform design begins, because it determines the networking architecture and identity management approach for everything that follows.
Cloud computing vs VPS: what is the difference?
Cloud migration moves workloads onto a public, private, or hybrid cloud model with managed services, elastic scaling and provider-run resilience built in, rather than a single rented server you configure and maintain yourself. That difference is exactly why a roadmap treats cloud model choice as a strategic decision, not simply a hosting swap.
What does cloud native mean in a migration roadmap?
The refactor strategy in the six Rs creates a cloud-native architecture. This involves redesigning an application rather than moving it without changes. This process benefits workloads that are central to your data and AI strategy. Refactored, cloud-native systems integrate more effectively with managed platforms and have lower operating costs at scale.