Cloud programs often begin with a destination: a provider, a target date or a mandate to leave a data centre. Those decisions can create momentum, but they do not establish readiness. Readiness is the ability to move a workload and operate it safely afterward without transferring unresolved problems into a new environment.
The assessment should produce decisions, not a score for a presentation. It should explain which workloads should move, which should change first, what foundations are missing and what the organization must learn or own.
Start with the outcome and constraints
Before inventorying technology, clarify why change is needed. Common drivers include capacity, resilience, delivery speed, geographic reach, supportability, cost visibility or the retirement of aging infrastructure. Each driver suggests different priorities.
Document constraints at the same time: regulatory requirements, data location, latency, licensing, contractual commitments, skills, budget timing and acceptable downtime. A migration path that ignores these constraints is only a diagram.
Understand the application portfolio
A server list is not an application portfolio. Readiness depends on how services support business processes, who owns them and what they depend on. For each meaningful workload, establish:
- business criticality and tolerated disruption;
- technical owner and operational owner;
- runtime, data stores, integrations and identity dependencies;
- current availability, performance and recovery expectations;
- release frequency and change process;
- security, privacy and licensing constraints; and
- known technical debt or unsupported components.
Dependency mapping matters because migrations fail at the seams. A web application may be easy to move until an undocumented file share, fixed IP allowlist or overnight batch process appears.
Assess the operating model—not only the architecture
Cloud changes how infrastructure is requested, secured, observed and paid for. If every change still depends on manual tickets and unclear approvals, elastic infrastructure will not automatically create faster delivery.
Review identity administration, incident response, monitoring, backup ownership, patching, change control, cost allocation and after-hours support. Decide who will own the landing zone, reusable infrastructure modules and platform policies. The goal is not to copy an internet maturity model; it is to expose work that must exist after migration.
Build foundations before broad movement
A minimum cloud foundation usually includes account or subscription structure, identity federation, privileged access, network connectivity, logging, security baselines, resource naming, tagging, backup expectations and cost visibility. These elements should be automated and reviewable where practical.
Do not attempt to perfect every policy before learning from a workload. Build enough foundation to run a controlled pilot, then improve it using evidence from delivery and operations.
Choose a path workload by workload
“Migration” covers different changes. Rehosting can reduce immediate infrastructure risk but may preserve operational limitations. Replatforming can adopt managed services without redesigning the whole product. Refactoring may improve scale or delivery flexibility, but it requires stronger product justification and carries more change risk. Retaining or retiring a workload is also a valid decision.
Choose based on the outcome, remaining life of the system, dependency complexity and team capacity. Applying one pattern to the whole estate makes planning simpler but execution harder.
Create an evidence-backed sequence
Select an initial workload that is meaningful enough to exercise the platform but bounded enough to recover from mistakes. Define entry criteria, migration steps, validation, rollback, security checks and operational acceptance. Record what the pilot proves and what remains unknown.
The output of readiness work should be a decision map: foundations to build, workloads grouped by path, key dependencies, owners, risks and the next few increments. That gives leaders a basis for investment and gives delivery teams a sequence they can execute.
Readiness is a managed capability
Cloud readiness is not a one-time gate. Applications, teams and provider capabilities change. Revisit assumptions after pilots and major releases. When ownership, automation and feedback improve alongside the architecture, migration becomes a controlled modernization program rather than a relocation exercise.