Cloud readiness is more than moving servers.

Understand the workload

Start with an inventory of applications, data, integrations, users, and dependencies. Identify critical periods, latency requirements, licensing constraints, and systems that cannot move together.

Some workloads suit managed services. Others may need a phased transition or an architectural change. Keeping a workload in place can also be a reasonable outcome if the evidence supports it.

Define the operating model

Someone needs to own access, updates, incidents, cost, and recovery. Moving to a cloud provider does not transfer every responsibility. The division depends on the services selected and how they are configured.

• Identity: how access is granted, reviewed, and removed.
• Environments: how production is separated from development.
• Change: how releases are tested and rolled back.
• Observability: which alerts require action and who receives them.
• Recovery: what is backed up and how restoration is tested.

Make costs explainable

A price estimate should state its assumptions about compute, storage, requests, traffic, backups, and support. Include likely growth and the effect of development or test environments.

Use budgets, ownership tags where supported, and a regular cost review. A low starting estimate does not replace a process for understanding actual consumption.

Test the exit and the recovery

Understand how data can be exported, which services create strong dependencies, and how the system would recover from a failure. Portability does not mean avoiding every managed service; it means making the tradeoff explicit.

Run a realistic recovery exercise before treating backups as a complete resilience plan. Record the actual recovery time, any missing access, and the steps that needed undocumented knowledge.