Most cloud migrations don't fail because someone picked the wrong provider. They fail because a team started moving workloads before it had a plan, and only found out about the data integrity gaps, the unplanned downtime and the runaway bill once it was too late to plan around them.
A proper migration roadmap does more than keep a project on schedule. It forces the hard questions to the surface early: which workloads move first, what your data actually looks like once you go and check it, and whether your organisation can actually run cloud infrastructure day to day once it lands. Skip those questions and you join the long list of enterprises paying for two environments at once, on-premise and cloud, with neither one working properly.
We build data foundations and cloud platforms for enterprise clients at Shipshape Data, and this is the guide we wish more teams had before they started. It walks through every stage of planning a cloud migration, from the first environment audit to the rollback plan you hope never to use, with enough detail that you can actually build a roadmap from it rather than just nod along.
What a cloud migration roadmap actually has to cover
A lot of teams treat migration planning as a technical exercise: pick a strategy, pick a provider, start moving servers. The migrations that go well treat it as an organisational programme instead, one with commercial and operational dimensions as well as technical ones. Before you sketch a single migration wave, get clear on what the roadmap needs to answer.
Business objectives and scope
Start with a plain link between the migration and outcomes someone can measure. Are you cutting infrastructure spend? Improving reliability? Building the cloud-native platform that AI and analytics work needs? Write it down. Without an objective tied to a number, every migration decision becomes a matter of opinion, and opinions don't survive a budget review.
Scope needs the same discipline. Decide upfront which workloads, applications and datasets are in and which are out, and why. Note the legacy systems you plan to retire alongside the ones you're moving, and flag anything locked to on-premise by contract or by technical debt so nobody tries to move it by accident six months in. Get scope wrong at the start and you get scope creep halfway through, which is one of the more common ways migrations blow their budget and their timeline together.
Technical inventory and dependency mapping
You cannot plan what you have not catalogued. The roadmap needs a full inventory of the current environment: servers, databases, storage, networking, and the applications that lean on all of it. Dependency mapping tells you which systems are coupled, so you don't move one workload and quietly break something upstream that never showed up in a spreadsheet.
This is also where technical debt surfaces. Older applications sometimes need refactoring before they behave in the cloud. Databases with years of stored procedures bolted on may need schema work before they'll move cleanly. Better to find that out now, at the planning stage, than three weeks into a wave when the timeline is already public.
Migration strategy, governance and risk controls
The roadmap needs a defined approach for each workload category (rehost, replatform, refactor, replace or retire, more on that below), the cloud model you're targeting, and a governance structure that owns decisions for the length of the programme.
Risk controls are not optional extras. Every wave needs a rollback procedure, data validation checkpoints, and an escalation path that's clear before anything breaks, not invented in the moment. Someone needs to own each decision, the approval process needs to be written down, and the business needs to know in advance how you'll communicate an outage or a delay. A proper governance layer is the difference between a controlled migration and a recovery exercise that eats the rest of the quarter.
Step 1: assess readiness, inventory and constraints
Before the roadmap takes shape, you need an honest picture of what you're actually working with. This step gathers the facts everything else depends on: what exists in the current environment, what's fit to move as it stands, and what constraints will bend the plan around them. Skip it and you end up migrating systems that should have been retired years ago, or hitting a dependency failure nobody flagged because nobody looked.
Run a full environment audit
Catalogue every asset in scope: servers, databases, storage systems, and the applications that depend on them. Discovery tooling can automate a good chunk of this, but validate the output by hand for anything business-critical; automated scans miss context a person would catch in ten seconds. AWS, Azure and Google Cloud all offer 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 tells you.
Once the inventory exists, classify each workload by complexity and business criticality, then assign it a rough migration priority. A CRM system might land as medium complexity and high criticality, which puts it in a middle wave once the process is proven. An internal reporting database, low complexity and only medium criticality, is a sensible candidate for the first wave, low stakes, useful for shaking out the process. A legacy ERP system, high complexity and high criticality, waits until the third wave or later, once everything else about the migration has been tested on something that matters less.
One thing automated discovery tools reliably miss: shadow IT. The database a marketing team spun up on a spare server three years ago, the reporting script that quietly reads from a production replica every night, the integration someone built in a weekend that half the finance team now depends on without knowing it exists. None of that shows up on an asset register unless someone goes looking, and it's exactly the kind of thing that breaks a wave when it turns out three other systems were relying on it. Interview the teams who actually use the systems, not just the ones who administer them.
Evaluate organisational and technical readiness
Skills gaps and team capacity derail migrations as often as any technical problem does. Work out honestly whether your internal team can run cloud infrastructure day to day, or whether you need outside support in place before the first workload moves. Document the security and compliance requirements specific to your industry too: data residency rules, encryption standards, audit logging obligations. Capture these now, because they shape the platform design in Step 3, and finding them late means expensive rework.
Readiness assessment is not a box-ticking exercise. It is the thing that decides whether your migration stays on plan or turns into a recovery project.
Step 2: choose your migration strategy and cloud model
With the inventory done, the next call is how each workload moves and which cloud model will actually support how you operate. Both decisions shape the architecture, the cost and the engineering effort each wave demands, and getting them right now is far cheaper than refactoring a workload that's already live in the cloud.
The six ways to move a workload
The industry shorthand for this is the "6 Rs", and it's a genuinely useful way to force a decision on every single workload rather than defaulting to whatever's easiest:
- Rehost: lift and shift onto cloud virtual machines, unchanged. Fast, and the right call for simple applications on a tight timeline.
- Replatform: move with minor optimisations along the way, typically databases and web servers that benefit from a managed service without a full redesign.
- Refactor: redesign for a cloud-native architecture. Worth the effort for high-priority applications that genuinely need the scale.
- Repurchase: switch to a SaaS alternative rather than migrating the legacy software at all, when a modern equivalent already exists.
- Retire: decommission it. Every environment has redundant or unused systems still running because nobody's had the conversation about switching them off.
- Retain: keep it on-premise for now, usually because it's compliance-locked or too high-risk to move yet.
Assign a strategy to every workload in the inventory and write down the reasoning behind each one, so the delivery team has instructions rather than assumptions to build from.
Select your cloud model
Public cloud, AWS, Azure or Google Cloud, suits most enterprise workloads and gives you the widest range of managed services to build on. Hybrid or multi-cloud models earn their complexity when regulation forces certain data to stay on-premise, or when avoiding vendor lock-in on critical systems matters more than simplicity. Decide the model before platform design starts in Step 3: it sets the networking architecture, the identity management approach and the cost structure from the ground up, and reversing that decision later is expensive. If you operate across multiple regions, confirm your chosen provider actually covers the data residency requirements for your industry and geography before you commit, not after.
Step 3: design the target platform and governance
With strategy and cloud model settled, the roadmap moves into platform design. This step turns the decisions from Steps 1 and 2 into a concrete target architecture your engineering team can actually build against, and it sets up the governance that controls how resources get provisioned, accessed and watched for the rest of the programme. Skip this and workloads start moving into inconsistent configurations, security gaps you find out about later, and infrastructure costs nobody can fully explain.
Define your target architecture
The target architecture specifies networking topology, compute configuration, storage tiers and managed services for each workload category. Start 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 you can adapt rather than build from scratch, which saves weeks.
Document the actual decisions somewhere lightweight rather than leaving them in someone's head. That means writing down, for example, that identity management runs through Azure AD or AWS IAM for centralised access control, that the network topology is hub-and-spoke for segmentation and traffic control, that storage splits across object storage and a managed database for a sensible balance of cost and performance, and that logging routes to a single centralised sink so there's one place to look during an incident rather than five.
Establish governance and access controls
Governance defines who can provision resources, what spending limits apply, and how policy violations get flagged before they turn into incidents. Use your cloud provider's native policy tools, Azure Policy or AWS Service Control Policies, to enforce guardrails automatically rather than relying on people remembering the rules. Assign clear ownership for each environment, development, staging and production, and set budget alerts from day one so a cost overrun surfaces the week it happens rather than on the month-end bill, by which point it's a much harder conversation.
Model your costs before you commit
Cloud spend surprises almost every enterprise that migrates without modelling it first, usually because the comparison to on-premise costs was never done properly. On-premise cost is easy to underestimate: it hides in depreciated hardware, facilities, and staff time that nobody bothers to itemise because it's already sunk. Cloud cost is the opposite problem, it's all visible on a bill, which makes it feel bigger even when the underlying number is similar or better.
Build a per-workload cost model before you migrate anything, using each provider's pricing calculator against your actual usage data from the environment audit, not rough estimates. Include the boring line items that get 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're bringing with you rather than repurchasing as SaaS. Reserved capacity and committed-use discounts can cut a meaningful chunk off the run rate, but only if you're confident in the usage pattern, and confidence at this stage usually means you've already done 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
Build the wave plan around business risk and workload complexity, not speed. Wave 1 should be low-complexity, non-critical systems, internal reporting databases and dev environments are a reasonable starting point, that let the team test the process and build confidence without much at stake. Only move business-critical or technically complex workloads once the landing zone, tooling and operational procedures have proven themselves on the earlier waves. A typical shape looks like this: Wave 1 covers low-complexity systems over the first month; Wave 2 brings in medium-complexity workloads like CRM and collaboration tools over the following month or so; Wave 3 and beyond handles the high-complexity, high-stakes systems, ERPs and data warehouses, once everything before it has gone to plan.
Plan data migration and rollback
Data migration needs its own plan, separate from the application migration it sits alongside. For every dataset, document the transfer method (database replication, bulk export, or a managed migration service), the validation checkpoints that confirm data integrity once it's moved, and the maximum data loss window you're willing to accept. Validation should mean something concrete: row counts that match between source and target, checksums on critical tables, and a reconciliation report that someone actually reads rather than a script that silently passes. Before any wave goes live, define the rollback trigger: the specific condition that tells the team to revert, and the exact steps to do it, written down in advance rather than worked out under pressure.
Assign each wave a named rollback owner and a tested procedure, not a theoretical one. Run a dry-run migration for Wave 1 in a staging environment before touching production, and actually review the results with the team before committing to the live cutover. It's a small amount of extra time against a genuinely bad week if the first live wave goes wrong in front of the business.
Where migrations actually come off the rails
Most of the migrations we get called into after the fact didn't fail on the technology. They failed because someone skipped Step 1, or because the governance layer got bolted on after workloads had already landed, or because a wave moved a system nobody had properly mapped the dependencies for. The pattern repeats often enough that it's worth saying plainly: the technical work in a cloud migration is rarely the hard part. Sequencing, governance and honest readiness assessment are.
The other pattern worth naming 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 actually 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.
What to do next
A solid cloud migration roadmap takes you through assessment, strategy, platform design and wave sequencing in that order, so each phase builds on the last instead of creating rework two steps later. Rushing the sequence, or skipping straight to picking a provider, is how a manageable migration turns into a costly recovery project.
The honest starting point is an assessment of where your data and infrastructure actually stand today, before a single workload moves. That's the work we do at Shipshape Data: mapping the real state of an enterprise's data and platforms, and telling clients plainly what needs fixing before migration begins rather than after. If you want a straight read on what your cloud migration will actually require, talk to us and we'll give you one grounded in your own environment, not a vendor demo.