All insights

Cloud Migration Roadmap: How to Plan Your Move Step by Step

2026-10-20 · 7 min read · Baywater Consulting

A cloud migration roadmap is the plan that turns "we should move to the cloud" into a sequence of dated, owned, low-risk steps. Without one, migrations drift: workloads move in the wrong order, costs climb and the business loses confidence. This guide sets out the stages of a sound roadmap and what to look for if you bring in a cloud migration consultant.

What is a cloud migration roadmap?

A roadmap is a phased plan covering what moves to the cloud, in what order, using which approach, by whom and by when. It links the technical work to business goals such as closing a data centre, cutting cost, improving resilience or meeting security requirements.

It is different from a one-off lift-and-shift project plan. A roadmap covers the preparation before the first workload moves and the operating model after the last one does.

Stage 1: Set goals and constraints

Start with why you are migrating. Different goals lead to different roadmaps: an exit from a data centre with a fixed contract end date needs speed, while a modernisation goal justifies more re-architecture.

  • Business drivers: cost, resilience, speed of delivery, end of hardware support or contract expiry.
  • Hard deadlines and budget range.
  • Security, data residency and compliance obligations (for example UK GDPR and sector rules).
  • Downtime tolerance for each major service.

Stage 2: Discover and assess your estate

List every application, server, database and integration, who owns each, and what depends on what. Discovery often turns up systems nobody uses and undocumented dependencies, both of which change the plan.

For each workload, record its business criticality, data sensitivity, technical stack, current running cost and any licensing restrictions.

Stage 3: Choose the approach for each workload

Assign a migration strategy to every workload: rehost, replatform, repurchase, refactor, retire or retain. We explain these in our guide to the 6 Rs of cloud migration. The result is a short list of workloads with a clear decision and a reason for each.

Stage 4: Design the landing zone

Before anything moves, build the foundation in Azure, AWS or Google Cloud: account or subscription structure, identity and access, networking, security controls, logging and cost governance. Getting this right first prevents expensive rework later.

Stage 5: Plan the waves

Group workloads into waves. Begin with low-risk, low-dependency systems so the team learns and the process is proven before critical systems move. Each wave should have an owner, a test plan, a cutover plan and a rollback plan.

  • Wave 0: pilot with one or two simple workloads.
  • Middle waves: groups of related applications moved together.
  • Final waves: complex, high-criticality systems with the most testing.

Stage 6: Migrate, test and cut over

Migrate each wave, then test functionality, performance and security before switching users over. Keep the old environment available for a defined period so you can roll back if something fails, then decommission it so you stop paying for both.

Stage 7: Optimise and operate

Go-live is not the finish. Right-size resources, apply commitment discounts for steady workloads, set budgets and alerts, and agree who supports the environment day to day. Cloud costs and security posture need regular review, which our cloud cost optimisation guide covers in more detail.

What a good roadmap document contains

Ask to see these elements in any roadmap you are given.

  • Inventory of workloads with a chosen strategy and rationale for each.
  • Target architecture and landing zone design.
  • Wave plan with timings, dependencies and owners.
  • Risk register with mitigations and rollback plans.
  • Cost estimate covering migration effort and ongoing running costs.
  • Security and compliance approach.
  • Skills and support plan for after go-live.

How to choose a cloud migration consultant

A consultant should reduce your risk, not add to it. Look for evidence rather than promises.

  • Experience on the platform you are moving to (Azure, AWS or Google Cloud), not general IT experience.
  • A clear discovery phase before they quote a number.
  • Named people who will do the work, and how they handle knowledge transfer to your team.
  • How they treat security, testing and cutover, and what happens if something goes wrong.
  • A route to buy: UK public sector organisations can procure through frameworks such as G-Cloud 15, which can remove the need for a full tender.

Planning a migration with Baywater Consulting

Our cloud migration planning service covers discovery, workload strategy and a phased roadmap, and we can then deliver the set-up and migration and support the environment afterwards. We work with UK organisations and international clients on Azure, AWS and Google Cloud, and our services are listed on G-Cloud 15 for public sector buyers. Book a free consultation and we will give you an honest view of what your roadmap would look like.

Ready when you are

Ready to see what an improvement partner can do?

Tell us where you are today — we'll tell you what a better software & cloud environment looks like from here.