A practical two-week cloud readiness review

A cloud readiness review should support one decision: what the team needs to change first. For many mid-market teams, three outputs cover that decision: a current-state map, ranked risks, and a 90-day plan with owners.

Two weeks gives a focused team enough time to inspect the live estate, reconstruct recent change and recovery work, and agree on the first sequence. The scope must name the decision before evidence collection begins.

Name the decision

A board evaluating a new region needs evidence about data boundaries, recovery, and operating capacity. An engineering lead facing painful releases needs deployment, ownership, and rollback evidence. Write the decision in one sentence on the first page of the brief.

Use that sentence to reject evidence that cannot affect the decision. This keeps interviews short and prevents a broad control catalogue from replacing the implementation plan.

Collect evidence from five areas

Start with the parts of the estate that determine how teams deploy, observe, and recover services. Widen the review when those findings expose a dependency outside the initial scope.

• Inventory: deployed services, accounts, environments, and external dependencies.
• Ownership: named teams for each service, identity boundary, network, and backup path.
• Observability: signals that explain a customer-facing failure from request to dependency.
• Recovery: restore evidence, rollback conditions, and the date of the last recovery test.
• Change: release approvals, deployment steps, failure handling, and change windows.

Record each risk with a service owner, a failure mode, supporting evidence, and a next action. A risk without one of those fields needs more investigation before the team can prioritize it.

Use a two-week sequence

During week one, inspect the deployed architecture, interview the engineers who handled the last incident, and reconstruct three recent releases. Compare diagrams with the resources and traffic paths running in production.

During week two, rank risks by service impact and recovery cost. Draft a target foundation, assign an owner to each first action, and review the sequence with the team that will deliver it. Record the options the group declined and the evidence behind each choice.

Prepare the handoff

The current-state brief explains the deployed system and its owners. The risk register ties evidence to impact. The 90-day plan names the first changes, dependencies, owners, and validation checks.

Use maturity scores only when a specific decision requires comparison across teams or regions. A direct description of the failure mode gives an engineering lead more information for staffing work.

Keep the review tied to this estate

Treat the cloud provider checklist as an input. Base priorities on this company’s incidents, releases, ownership, and recovery evidence. Recommend replacement only where the current system blocks a safe change path after the team addresses those operating gaps.