The migration factory model earns its name from throughput. Discovery, assessment, wave planning, cutover and hypercare become repeatable stages run by specialised teams, so the fiftieth application costs a fraction of the first. The model works. What it does not do is make the hardest input any easier to produce: an accurate picture of what depends on what.
Dependency capture is where migration programmes quietly accumulate risk. Waves are planned against it, cutover windows are sized against it, and rollback decisions are made when it turns out to have been wrong. The interesting question is not whether AI can help — it is which parts of the problem are actually tractable, and which are being oversold.
Why Wave Planning Is Hard
AWS recommends migration waves of six to ten weeks, and distinguishes between hard and soft dependencies: a soft dependency tolerates its counterpart living elsewhere, a hard dependency does not. Split a hard dependency across a WAN boundary and you get latency-driven failures that pass smoke tests and then fail under production load.
AWS states the constraint plainly in its own prescriptive guidance: although process-to-process communication can be obtained from discovery tooling, it is hard to classify those flows into hard and soft dependencies, and latency tolerance is difficult to determine from network data alone. No discovery tool resolves this by itself.
Hard dependencies are not only technical. Maintenance windows, change freezes, resource availability and data centre exit dates all constrain wave composition, and none of them appear in a traffic capture. Month-end and quarter-end batch processes are invisible to a two-week observation window, which is why a discovery period should span at least one full business cycle.
The Shared-Services Hairball
The most common reason an automated wave planner returns a single enormous wave is that nobody filtered the shared services. Active Directory, DNS, NTP, backup, monitoring and SIEM traffic connect to everything, and in a dependency graph they glue the entire estate into one strongly connected component.
Shared infrastructure traffic is not a dependency signal. Until it is filtered out, every application depends on every other application, and the graph tells you nothing.
Once shared services are excluded, the graph becomes tractable. AWS suggests a useful technique: look for single applications that bridge large clusters. Those articulation points are where the estate can be cut into wave-sized groups with the fewest cross-wave edges.
What Algorithmic Wave Planning Actually Does
Microsoft's Auto Wave Planning in Azure Migrate is a useful reference implementation because its behaviour is documented rather than implied. It is deterministic — the same inputs produce the same plan — and it evaluates eight prioritised conditions in order: strongly bidirectional dependencies stay together, all workloads in an application move as one, dependency targets migrate no later than their dependents, dev and test precede production and never share a wave with it, and high-criticality or high-complexity applications stay out of the earliest waves.
Two design choices in that engine deserve wider adoption. The first is that unmapped workloads default to production and medium criticality, so anything unknown drifts into later waves rather than being risked early. The second is that confidence and risk are scored separately: confidence measures how complete the input data was, not whether the plan is correct. A low-confidence plan is not a wrong plan — it is a plan built on thin evidence, and that is a different problem with a different remedy.
Where AI Helps, and Where It Does Not
The defensible applications are inference tasks over large, messy, unlabelled data. Clustering endpoints into candidate application groups from flow data. Classifying traffic as shared-service or application-specific. Reconciling three discovery sources that disagree about the same host. Drafting the rationale for a wave so a reviewer can argue with it. These are real, and techniques such as MDL-based clustering for dependency mapping are established enough to appear in granted patents.
The honest architecture is that AI proposes and the application owner disposes. Machine inference compresses the interview list from four hundred applications to the forty where the evidence is ambiguous. It does not remove the interview, because latency tolerance and criticality live in people's heads, not in netflow.
The weak claim is that AI determines hard versus soft coupling. It cannot, for the reason AWS gives: the signal is not present in the data. Treating a model's confidence score as a substitute for an owner conversation is how programmes arrive at cutover night with a dependency nobody validated.
The CMDB Is a Hypothesis
Factories that seed waves from the configuration management database inherit its failure modes: duplicate items, stale records for decommissioned kit, misclassified types and missing relationships. A stale entry is particularly awkward, because it asserts that something exists which discovery has not confirmed for months.
The productive posture is to treat the CMDB as the hypothesis and observed traffic as the evidence, then model the disagreement explicitly rather than overwriting one with the other. Discrepancies between planned and discovered state are findings that need an owner, and the size of that backlog is a better readiness indicator than any completeness percentage.
Planning Under a Deadline
Much of the current migration demand is not discretionary. Broadcom's licensing changes — the end of perpetual VMware licences and, from April 2025, a minimum purchase of 72 cores per product order line — have put estates on a contractual clock. Gartner has projected, as reported by TechTarget, that 35 percent of VMware workloads will move to alternative platforms by 2028.
A deadline-driven migration is exactly the condition under which dependency discovery gets truncated. The discipline that protects the programme is unglamorous: filter the shared services, observe across a full business cycle, treat confidence and correctness as separate measures, regenerate the wave plan as evidence improves rather than freezing it early, and keep one source of truth for scope so that a newly discovered dependency changes the plan instead of surfacing during cutover.