Four capabilities answer that, and each one labels what it could not prove. The expensive part of a Dynamics migration is rarely the work you planned for. It is the component nobody remembered, found three weeks in.
Three of the four are tools on the Pathix MCP server, so an agent can run the same analysis and hand you the answer rather than you driving the console: table_logic_footprint, cascade_fanout, and the pair behind the plan, migration_sequence and plan_table_migration. Every one is read-only, and the agent signs in as you.
The plan folds two kinds of coupling into one sequence: column data flow, meaning one component writes what another reads, and orchestration, meaning one component invokes another. Both have to hold for the order to be safe.
Point your agent at this with the Pathix MCP and it returns the same ordered plan, with the cycles and unproven edges still labeled.
Clusters with no coupling between them. Two tracks can be worked at the same time by different people without either one waiting, which is what makes a large migration divisible in the first place.
Wave 0 is what nothing downstream depends on, so it is safe to change first. Work outward from there toward the roots everything else sits on.
Cascade behavior is configured per relationship and its reach compounds quietly. Pathix walks the relationship metadata outward along whichever axis you pick and returns the tables that operation actually reaches, with the depth it traveled to get there.
Cascade is only one route. A plugin or a workflow can issue a delete directly, and that path does not appear anywhere in the relationship metadata. Pathix answers the question from both sides at once: the relationships that cascade a delete into the table, and the component logic that deletes from it on purpose.
A migration plan that looks certain is worse than one that shows its gaps, because you will act on it either way. Three things the rewrite plan flags about itself.
Where two components depend on each other, no internal order is provable. Pathix marks the group rather than picking one and presenting it as the answer.
An edge crossing an Unresolved or AI-derived endpoint is labeled unproven. It stays in the plan, because dropping it would make the sequence look more certain than it is.
A component can land in wave 0 because nothing depends on it, or because Pathix could not resolve what it depends on. Those two are very different, and the plan tells them apart.
The plan reflects coupling Pathix could model from structure. Treat it as a sequence worth checking rather than proof, which is also how the product words it.
The same four capabilities in narrative order, with the product screenshots and a real migration an agent rebuilt from the graph.
Read →The manual method for rename, retype and delete, including why the platform's delete check will not stop you breaking a plugin.
Read →The edges every one of these capabilities is built on, and how confidence is expressed per edge.
Read →A walkthrough traces whatever you name, on a pre-scanned environment, in about thirty minutes.