1. Define the reason for change
Begin with the constraint that matters: slow product delivery, resilience risk, data-centre exit, security control, global reach or cost visibility. “Move to cloud” is not a measurable outcome. Record the decision owner, target business capability and evidence that will show improvement.
2. Build an application evidence base
Inventory workloads together with their users, criticality, lifecycle, dependencies, data sensitivity, recovery objectives, licensing and operational ownership. Combine documentation with runtime evidence such as traffic, batch schedules, network flows and incident history.
- Identify unsupported technology and upcoming renewal dates.
- Map inbound, outbound and human dependencies.
- Classify data and residency obligations.
- Confirm peak demand, latency and availability requirements.
- Record who can validate each assumption.
3. Choose a disposition deliberately
Assess whether each workload should be retired, retained, repurchased, rehosted, replatformed, refactored or relocated. Use the simplest path that achieves the target outcome. Refactoring every application before migration expands risk; rehosting everything can preserve the constraints that motivated change.
4. Establish the cloud foundation
Design identity, account or subscription structure, networking, DNS, encryption, secrets, logging, policy, backup and cost allocation before application teams build around inconsistent assumptions. Provision the foundation through reviewed infrastructure as code and test the controls continuously.
5. Define the operating model
Clarify who owns the platform, application, security response, cost review, patching, backup validation and incident coordination. Provide paved-road templates without making the platform an opaque ticket queue. Training and operational rehearsal belong in the migration plan.
6. Plan waves around learning
Select a first wave that is meaningful enough to test the foundation but bounded enough to recover safely. Document entry criteria, cutover method, rollback decision, validation owner and post-migration stabilization period. Feed evidence from each wave into the next plan.
Decision-ready output
A readiness assessment should produce a validated inventory, dependency map, workload dispositions, target foundation, risk register, operating responsibilities, wave plan and cost model with assumptions. If those artifacts cannot support a funding and sequencing decision, discovery is not complete.