Wave Planning, Dependency Analysis & Cutover Runbooks

Tier: Core · Hands-on time: ~30 minutes

Wave planning sits downstream of assessment (pb-22) and upstream of the only migration artifact users ever experience: the cutover. The work is planning-shaped — grouping applications under dependency, capacity, and business-calendar constraints — which models handle well as candidate generation, and badly as truth: an LLM will sequence beautifully around a dependency map whose edges are wrong, and network-flow exports are wrong in known, systematic ways. So the human gate is data verification before sequencing, and sign-off after; between those gates, AI compresses days of grouping and runbook drafting into an afternoon.

When to use

• •
  Assessment is done and a portfolio must become an ordered wave plan with defensible reasoning per wave.
• •
  Dependency exports (network flows, CMDB relations, APM maps) exist and need converting into migration-relevant groupings.
• •
  Each wave needs per-app cutover runbooks — steps, checks, abort criteria, comms — drafted to a consistent standard.

Skip AI when sequencing is dictated by a single dominant constraint (a datacenter exit date, one shared database) — the plan writes itself, and the effort belongs in the runbooks.

Prerequisites

• Dependency data, with a candor notenetwork flow exports, CMDB relationships, APM topology; annotate what each source reliably captures and what it misses (flows miss batch jobs that run monthly; CMDBs miss everything since the last audit).
• The pb-22 disposition sheet with confidence labels and the override log.
• The constraint calendarfreeze windows, business peak periods, contract/licensing dates, team capacity per fortnight.
• An LLM with structured input handling plus your runbook template — the house format for steps, verification gates, abort criteria, comms.

The workflow

1. 1.

   Verify the dependency data before it touches sequencing. Sample the map where wrongness is systematic: pick five high-connectivity apps and confirm their top edges with the owning teams; ask specifically about what flows cannot see — monthly batch, DNS hardcoding, shared credentials, file drops. Every confirmed correction goes into the dataset with a source tag. Sequencing on an unverified map is the playbook's cardinal sin, because the plan will look rigorous exactly where it is wrong.

2. 2.

   Generate candidate wave plans with reasoning attached.

   Copy

   Group the attached 62-app portfolio (dispositions + verified
   dependency edges + constraint calendar) into candidate wave plans
   for a 9-month window, GCC factory capacity of 8–10 apps per wave.
   
   Produce TWO candidate plans optimizing differently:
   Plan A — minimize cross-wave dependencies (clean cuts).
   Plan B — earliest business value (quick wins first, accepting more
   temporary bridging).
   
   For every wave in each plan: member apps; the dependency reasoning
   (cite the specific edges that bind or separate apps — edge IDs from
   the input); risk annotations (low-confidence dispositions present,
   apps with unverified edges, freeze-window adjacency); and required
   temporary bridges (connectivity or data sync that must exist while
   waves are split).
   
   Rules: never place an app before a wave containing something it
   depends on unless you name the bridge. Flag any app whose edges are
   marked unverified — do not sequence it as if the data were clean.
   

3. 3.

   Interrogate the candidates, then decide. The two-plan structure exists to surface trade-offs, not to pick a winner by vibes. Probe: "which single edge, if wrong, most damages Plan A?"; "what does Plan B's bridging actually cost in temporary infrastructure?" Then the human sequencing decision — typically a hybrid — gets written down with reasons, wave by wave. This sign-off is the artifact the steering committee holds you to; Sameer records his as one paragraph per wave in the migration charter.

4. 4.

   Draft cutover runbooks per app, from the template. Feed each app's record (disposition, dependencies, bridge requirements, rollback story) plus the house template: steps with owners and timing, pre-cutover verification gates, go/no-go criteria with named decision-makers, abort criteria with the rollback procedure, and the comms plan (who is told what, when, in which channel). Insist on abort criteria being concrete state ("replication lag exceeds X for Y minutes"), not sentiment ("issues encountered") — models default to sentiment, and vague abort criteria are how cutovers become incidents.

5. 5.

   Dry-run the riskiest runbook, fix the class. Pick the wave-1 app with the worst blast radius and walk the runbook in a tabletop with the teams named in it: every step, every check, every abort path. The dry run finds the runbook's fictions — steps that assume access nobody has, checks with no owner, rollbacks that were never tested. Feed corrections back as template changes so the whole runbook set inherits them, not just the one you walked.

6. 6.

   Re-plan on evidence, not embarrassment. Waves will surprise you. When wave 1 uncovers an edge the map missed, update the dependency data, regenerate downstream candidates against the corrected map, and re-sign the changed waves. The regeneration is cheap now — which removes the traditional excuse for riding a wrong plan to the end because re-planning cost too much.

Verify before you trust it

• Cited edges exist in the input. Sample each plan's dependency reasoning against the actual dataset — an invented edge ID means the grouping logic hallucinated structure, and every wave built on it needs re-checking.
• The unverified-edge flags survived into the plan. Apps you marked unverified must appear flagged in the wave risk annotations. A plan that launders data uncertainty into clean sequencing has overstated itself — and the steering committee will price the plan's confidence wrong.
• Bridges are enumerated and costed. Every cross-wave dependency the plan accepts implies temporary infrastructure someone must build and later tear down. If the bridge list is shorter than the cross-wave edge list, waves are silently broken.
• Runbook abort criteria are executable at 2 a.m. Read each abort criterion as the night-shift engineer: is the threshold observable on a dashboard that exists, and is the rollback a tested procedure? Anything requiring judgment calls by people not in the room fails the read.

Restricted-environment variant

Dependency maps and wave plans describe the client's estate and its soft spots — pb-03 register material throughout. Run planning inside the approved boundary (Bedrock/Azure OpenAI in the client subscription, or local models — wave grouping over structured exports works acceptably on capable local models with the reasoning-and-citation rules intact). Pseudonymize where the middle path is needed: app IDs for names, with the mapping held client-side; the sequencing logic never needed the real names. Cutover runbooks are operational security documents — they enumerate access paths and rollback credentials by role; keep them in the client's document boundary regardless of where drafting happened, and never let credential specifics enter any prompt.