Migration Readiness and Blockers

Track what is actually ready and what still needs evidence.

Readiness is more than an overall percentage. A workload can be technically feasible but financially or operationally blocked by dependencies, support contracts, unknown ownership or incomplete source inventory.

Readiness dimensions

Review known technical dependencies, security/operational concerns, migration ownership, financial inputs and exception status. Low-confidence dependency information must not be treated as resolved simply because a planning date is approaching.

Resolving a blocker

Record the blocker, its owner and the required action; attach relevant evidence or an authorized exception; update status through the supported workflow. Retain the actor/timestamp history so reviews can distinguish a resolved issue from an ignored one.

What readiness does not guarantee

A readiness score is not a guarantee of successful cutover or savings. It expresses documented readiness under known inputs. An approved exception should be visible to decision makers rather than disappearing from the record.

Important

Approving an exception does not resolve the underlying blocker — it records an accepted risk. Decision makers should see the exception alongside the readiness score.

Using readiness with waves

Before assigning a workload to a wave, review blockers and the economics assumptions. If a dependency is unresolved, surface the wave risk rather than assuming the scheduled date cures it.