Total risk visibility,
from discovery to cutover

A risk taxonomy for migration programmes

Migration risk is not one thing, and a single register of loosely worded entries hides more than it reveals. Clarity classifies risk into six categories, each attached to the workloads, move groups and tasks it affects, so an entry always points at something in the plan.

• 
  Dependency risk. An application relationship that is not in the map, so a workload is scheduled without something it needs.
• 
  Sequencing risk. A move group that is technically correct but placed in the wrong wave, against a change freeze, a business peak or a supplier lead time.
• 
  Data risk. Replication lag, integrity failures, or a dataset too large to move inside the agreed window.
• 
  Target readiness risk. Landing zone, network, identity or security controls that are not in place when the wave arrives.
• 
  Operational risk. Run books, monitoring and support models that do not follow the workload into its new home.
• 
  Compliance risk. Residency, retention or evidence obligations that the move itself has to satisfy.

The failure modes this is designed to catch

Programmes rarely fail because a server refuses to boot. They fail in a small number of recognisable ways, and every one of them is visible in planning data before it becomes an incident.

• 
  Cutover starts and an undocumented integration on a legacy server fails, so the rollback is invoked and the window is lost.
• 
  Two move groups share a database that nobody owns, and each team assumes the other is migrating it.
• 
  A wave is planned against inventory that is six months stale, so a third of the hosts do not exist as described.
• 
  Validation is defined as ping and login, so a broken batch interface is discovered by the business a week later.
• 
  Rollback is documented but never rehearsed, and the first attempt to use it takes longer than fixing forward.
• 
  Risk is tracked in a register that is separate from the plan, so nothing in the schedule changes when a risk is raised.

How risk is scored and acted on

Each entry is scored on likelihood and impact across three dimensions: service disruption, schedule and compliance exposure. The score sets the review cadence and the approval level needed to proceed, and it is recalculated as evidence changes, so a dependency risk drops once the relationship is mapped and a target readiness risk closes when the landing zone control is verified. Any move group holding an open high score cannot be scheduled without a recorded acceptance from a named owner. Mitigations are tasks in the runbook rather than notes in a register, which means the plan moves when the risk does. The underlying evidence comes from the dependency data described on the dependency mapping page and the task level plan described on the runbook generation page.