Dependency graph for migration impact
A migration dependency graph shows more than a list of modules: it shows directed relationships among the source runtime, framework, build plugins, libraries, integrations, deployment, and data/protocol boundaries. The graph should make target constraints, affected paths, and high-blast-radius nodes visible.
This is a separate artifact from MODULE_INVENTORY: an inventory describes individual modules, while a migration graph helps determine transition order and compatibility impact between components.
Nodes, edges, and constraints
| Element | Example content | Why it matters |
|---|---|---|
| Node | runtime, framework, plugin, client, protocol | a separate surface for a migration decision |
| Directed edge | application → framework or service → protocol | shows impact direction and verification order |
| Constraint | supported version, ABI, config, data format | determines a blocking or conditional path |
| Affected flow | endpoint, job, event, persistence operation | connects the graph to observable behavior |
| Unknown | unconfirmed transitive dependency | blocks an unjustified compatibility claim |
A compatibility matrix is a decision, not a score
A compatibility matrix breaks a source-to-target decision down by API, configuration, ABI, runtime, data format, protocol, and operations. Each cell needs a status, evidence, and owner. Statuses such as compatible, requires verification, blocking, or Unknown cannot be replaced with one overall number.
A risk map can show priority and consequence, but it does not replace the technical decision about whether a particular source/target pair is compatible.
Building the graph and matrix
- Start with the affected flow and its entry point, not the complete package list.
- Add source/target nodes and direct and transitive dependencies as far as they are confirmed.
- Mark directed edges, version constraints, and high-impact hubs.
- Fill in compatibility dimensions and evidence for each critical edge.
- Assign an owner to unknown and blocking items.
- Choose the smallest pilot that tests the main compatibility hypothesis.
Canonical lesson source · JavaRush
Open JavaRush material