Cloud

Planning a cloud migration in waves: the first 90 days

A month-by-month plan for the first 90 days of a cloud migration, from discovery and the landing zone to the first production waves.

Published
Reading time
3 minutes
Written by
Plurentoo Systems

Cloud migrations rarely fail because a server will not boot in the new environment. They fail because dependencies were missed, costs were guessed and the business was surprised by downtime. The first 90 days decide which of those problems you will have. Here is how we plan them.

Days 1 to 30: discover and decide

The goal of the first month is a decision you can defend: what moves, how it moves and in what order.

  • Inventory everything. Servers, databases, storage, licenses, network flows and scheduled jobs. Use discovery tools, but confirm results with application owners.
  • Map dependencies. Applications that talk to each other often need to move together, or need a plan for the time they are split.
  • Choose a path for each workload. The 7 Rs framework helps: retire, retain, rehost, relocate, replatform, repurchase or refactor. Most estates end up with a mix.
  • Build the business case. Compare current costs with projected cloud costs, including licensing, support, data transfer and the people needed to run the new platform.
  • Group workloads into waves. Early waves should be low risk and high learning. Save tightly coupled, business-critical systems for later, when the team and tooling are proven.

The output is a wave plan with dates, owners, cutover windows and success criteria for each workload.

Days 31 to 60: build the landing zone and prove it

A landing zone is the foundation every workload will sit on. Building it properly before the first move is one of the best predictors of a calm migration.

  • Accounts or subscriptions structured by environment and business unit.
  • Identity integrated with your directory, with multi-factor authentication and role-based access.
  • Networking with a hub-and-spoke or similar topology, private connectivity to your offices and data centers, and clear segmentation.
  • Guardrails such as policies that block public storage, enforce encryption and require tags.
  • Observability with central logging, metrics and alerting from day one.
  • Backup and recovery configured and tested, not just enabled.
  • Infrastructure as code, so the landing zone can be reviewed, repeated and audited.

Finish the month with a pilot: move one or two low-risk workloads end to end, including monitoring, backup and support handover. Write down everything that surprised you.

Days 61 to 90: run the first waves

With the foundation proven, the team moves into a repeatable rhythm.

  1. Prepare: confirm the runbook, test plan, rollback steps and communication plan for each workload.
  2. Replicate: copy data and servers ahead of the cutover window to keep downtime short.
  3. Cut over: switch traffic during the agreed window, with application owners on hand.
  4. Validate: run functional and performance tests, and compare results with the baseline.
  5. Hypercare: watch closely for one to two weeks, then hand over to steady-state operations.

After each wave, hold a short retrospective and update the runbook. By the third wave, the process should feel routine, which is exactly the point.

Do not leave cost control for later

Cloud bills grow quietly. Tag every resource with an owner and cost center from the start, set budgets and anomaly alerts, and review rightsizing opportunities after each wave. Commitments such as reserved capacity or savings plans make sense once usage has settled, not before.

A short checklist

  • Inventory and dependency map confirmed by application owners
  • Migration path chosen for every workload
  • Wave plan with dates, owners and cutover windows
  • Landing zone deployed as code, with guardrails and logging
  • Backups tested with a real restore
  • Pilot workload migrated and supported
  • Runbooks and rollback steps for each wave
  • Tagging, budgets and cost alerts in place

Need a second pair of hands?

Our cloud services team runs assessments, builds landing zones and migrates workloads on AWS, Microsoft Azure and Google Cloud. If part of your estate needs to stay on premises, our data center team can plan the hybrid design. Get in touch to discuss your estate.

Keep reading

More insights

Want to apply this to your own systems?

Tell us where you are starting from and what you need to decide. A real person from our delivery team will reply with questions and options.