“Move to the cloud” stopped being a strategy years ago — most growing companies are already in the cloud, usually in several places at once, often by accident. The real questions are quieter: are the workloads in the right place, does anyone control spend and access, and would the environment survive a bad day?
This checklist is the assessment we run before any migration or platform engagement. It works equally well as a self-audit. None of it requires buzzwords; all of it requires honesty.
1. Know what you actually run
Cloud readiness starts with an inventory most companies believe they have and few actually do: every application and service, where it runs, what it depends on, who owns it, and what happens to the business if it stops. Shadow systems — the database under someone's desk, the SaaS tool one department adopted, the script a former employee automated — belong on the list precisely because they never appear on it.
For each workload, three classifications matter: criticality (what breaks if it's down for an hour, a day, a week), data sensitivity (customer data, financial records, credentials), and coupling (what else must move if this moves). This triage drives every later decision — what migrates first, what needs redundancy, and what should honestly just be retired.
2. Identity before infrastructure
The most common weakness we find in cloud environments isn't architecture — it's access. Shared admin accounts, credentials in spreadsheets, former employees with live logins, and root access used for daily work. Cloud platforms make it easy to move fast and equally easy to accumulate invisible risk.
Readiness means: single sign-on in front of your critical systems, multi-factor authentication enforced rather than encouraged, roles scoped to what people actually need, break-glass admin accounts that are monitored and never used casually, and an offboarding process that revokes everything on the day someone leaves. If that list feels heavy, note that it is mostly configuration, not purchase — the effort is decision-making, and it is dramatically cheaper before an incident than after.
3. Make spend legible
Cloud spend grows the way weeds do — nobody plants it, everybody waters it. Readiness doesn't require a FinOps department; it requires legibility: resources tagged by system and owner, monthly spend reviewed against a budget someone is accountable for, alerts on anomalies, and a habit of retiring what nothing uses.
Two questions expose your current state quickly. Can you say what your top five workloads cost to run last month? And if a bill doubled, would you find out from a dashboard alert or from finance at month-end? If the answers are no and finance, address that before adding anything new — every future decision improves once cost is visible.
You can't right-size, negotiate, or prioritize what you can't see. Cost visibility precedes cost optimization.
4. Reproducibility and delivery
A cloud environment clicked together in a console is a liability wearing a success costume: it cannot be rebuilt, reviewed, or safely changed. The readiness bar is that environments are declared as code, changes go through review, and deployments are automated enough that releasing isn't an event requiring a calendar invite and courage.
This is also the honest prerequisite for most things companies want from the cloud — scaling, resilience, faster shipping. Autoscaling hand-built servers is folklore; autoscaling declared infrastructure is a checkbox. If your team is not there yet, a focused infrastructure-as-code effort on your most critical workload is the highest-leverage first step, and it teaches the practices everything else builds on.
5. The recovery questions everyone skips
Cloud providers run reliable data centers; they do not protect you from yourself. Deleted data, misconfigurations, compromised credentials, and ransomware all replicate to the cloud as faithfully as legitimate work. Managed infrastructure is not a backup strategy.
Readiness here is answering four questions with evidence rather than belief:
- Are backups isolated?. A backup reachable with the same credentials as production is part of the blast radius, not protection against it. Immutability or separate credentials are the bar.
- Has a restore been rehearsed?. Until a full restore has actually been performed, recovery time is a guess. Measure it once and the whole plan becomes real.
- Is SaaS data covered?. Your CRM, email, and shared drives hold critical business records. Most SaaS terms make data protection your responsibility, not theirs.
- Is there an order of recovery?. When multiple systems are down, dependencies dictate sequence — identity and DNS before applications. Writing the order down turns a crisis into a procedure.
Sequencing the work
If the checklist surfaced gaps everywhere, resist the urge to fix everything at once. The sequence that works: identity and access first, because it reduces risk across everything else and costs mostly decisions; then backup isolation and one rehearsed restore, because it caps your worst-case scenario; then cost visibility, because it funds the rest; then infrastructure-as-code and delivery pipelines workload by workload, starting with the most critical.
Treated this way, cloud readiness is not a project with an end date. It is an operating standard — and companies that hold it find that migrations, scaling events, audits, and even incidents become notably less dramatic than their reputation suggests.
Key takeaways
- Inventory workloads with criticality, sensitivity, and coupling before making any migration decision.
- Fix identity and access first — it's mostly configuration effort and reduces risk across the entire estate.
- Backups must be isolated and restores rehearsed; managed infrastructure is not a recovery strategy.
- Declare infrastructure as code before pursuing scaling or resilience goals that quietly depend on it.
- Sequence: identity → recovery → cost visibility → delivery pipelines. Standards, not a one-time project.
Relevant Xolkit services