Start with a defined next step
Request a cloud readiness assessment
Assess workload fit, data, dependencies, requirements, resilience and economics before migration.
Page purpose
Know what you provide and what you receive when you request a cloud readiness assessment.
Choose a cloud readiness assessment when the bounded decision is where and how identified workloads should run. Unlike the broader enterprise systems assessment, this route compares workload placement and modernization options using business criticality, architecture, dependencies, data, security inputs, resilience, operations, client-supplied licensing constraints, usage, and economic assumptions; it does not presume that every workload should move.
Initial inputs: workload names or categories, business purpose, current placement, known dependencies, service windows, broad data sensitivity, and program objectives. Immediate output: fit, clarifying questions, a proposed workload boundary, and an evidence checklist. If commissioned, outputs can include workload dispositions, dependency waves, target guardrails, risk treatments, economic assumptions, and a validation plan. Detailed configurations, billing or consumption exports, contracts, diagrams, security evidence, credentials, and keys require an approved route after scoping.
When to use this step
When is this the appropriate next step?
- A migration target is announced before workload fit and dependencies are assessed.
- Lift-and-shift expectations ignore architecture, resilience, licensing, and operating change.
- Economic comparisons use incomplete utilization, support, or transition assumptions.
What you receive
What you receive after fit is reviewed.
- Initial output: fit response, proposed workload scope, and input checklist.
- Commissioned output: workload inventory, dependency view, and readiness findings.
- Disposition recommendations such as retain, rehost, replatform, refactor, replace, or retire.
- Migration waves, target guardrails, risk treatments, and validation requirements.
- Economic assumptions and exclusions rather than unsupported savings claims.
What happens next
What happens after the request is submitted.
- Define program objectives, workloads, and decision criteria.
- Collect proportionate architecture, data, dependency, resilience, security, and cost evidence.
- Assess placement and modernization options per workload.
- Group workloads into viable transition waves and identify foundation needs.
- Validate assumptions through targeted discovery, rehearsal, or proof work.
What to prepare
Information that makes the conversation useful.
- Which workloads, environments, and shared services are in scope.
- What placement constraints and client-approved requirements apply.
- Which assumptions require proof before a migration commitment.
Information safety
Information that should not be sent through a public form.
- Submitting cloud credentials, sensitive billing exports, or production configuration through the public form.
- Moving tightly coupled workloads before dependencies and latency needs are understood.
- Presenting modeled costs or benefits as guaranteed outcomes.
Decision questions
Know the boundaries of the next step.
How does the assessment treat cloud as an option?
Cloud is one placement and modernization option to test against the agreed criteria. Retaining or improving a workload in its current environment may be valid when the evidence supports it.
What should not be included in the first request?
Do not include access keys, passwords, detailed network topology, production configuration dumps, billing exports, contracts, personal data, or restricted security evidence. Provide high-level ranges and constraints first.