Cloud migration readiness: what to decide before moving workloads

1. Write down the business reason

Cloud is a means, not an outcome. A migration should be tied to a problem the organization can recognize: slow environment provisioning, capacity constraints, resilience gaps, aging hardware, inconsistent deployments, geographic expansion, or a need to retire a data centre. If the only objective is ‘move to cloud,’ architecture and spending decisions have no reliable way to resolve tradeoffs.

Choose a small set of measures such as deployment lead time, recovery performance, service availability, infrastructure effort, or unit cost. Capture the current baseline where possible. Cost reduction may be a valid goal, but a lift-and-shift migration does not automatically reduce cost; cloud economics reward active sizing, scheduling, and ownership.

2. Build an application and dependency inventory

List applications, databases, queues, file stores, identity providers, scheduled jobs, external partners, certificates, DNS records, and network dependencies. Add business criticality, data classification, support owner, maintenance windows, current capacity, licensing constraints, and known technical debt.

Dependency discovery is where many plans become realistic. An apparently independent application may rely on an on-premises directory, hard-coded address, vendor allowlist, or nightly file transfer. Diagram traffic and data flows for critical services, then validate the diagram with application owners and observed telemetry rather than memory alone.

• Identify systems that must move together and systems that cannot move yet.
• Record data residency, retention, encryption, and contractual constraints.
• Mark every unknown explicitly; hidden uncertainty is more dangerous than a known limitation.

3. Choose a path for each workload

Different workloads deserve different treatments. Retire systems that no longer provide value. Retain workloads with a clear constraint. Rehost when speed matters and change must be limited. Replatform when a managed database, container service, or deployment change offers a bounded benefit. Refactor only where business value justifies deeper application work.

Avoid choosing one strategy for the entire estate. A portfolio plan should explain why each decision is proportionate to the workload’s value, risk, lifespan, and dependencies. Start with a representative but recoverable workload to test identity, networking, logging, deployment, and support processes before migrating the most critical service.

4. Establish the cloud foundation first

Before application teams deploy, define account or subscription structure, identity federation, privileged access, network patterns, logging, key management, backup expectations, tagging, budget alerts, and policy enforcement. This foundation is often called a landing zone. It should make the safe path easier, not surround every change with manual gates.

Use infrastructure as code for repeatable environments and peer-reviewed changes. Centralize the logs needed for security and operations, and test that alerts reach an owned response process. Decide who can create public endpoints, change network policy, access production data, and approve exceptions.

5. Design validation, cutover, and rollback together

A cutover plan should state entry criteria, data synchronization method, validation checks, decision owners, user communications, observation period, and rollback threshold. ‘Rollback if there is a problem’ is not enough; teams need to know which signals matter and how long reversal remains possible.

Validate more than page availability. Test authorization, integrations, batch jobs, backup, monitoring, performance under representative demand, and operational access. After cutover, keep a defined hypercare period with faster escalation and a daily review of errors, latency, spending, and user reports.

6. Make the future operating model explicit

Cloud services create continuing responsibilities. Define service ownership, on-call expectations, patch boundaries, vulnerability response, backup testing, capacity reviews, cost review, and provider support escalation. Managed services shift some tasks to the provider, but accountability for configuration, data, access, and application behaviour remains with the customer.

Review the migration against the original business measures after workloads stabilize. This distinguishes completion from success and creates a prioritized optimization backlog based on observed evidence rather than assumptions made before the move.