Migration
Part of Cloud migration planning
Building a dependency map before migration
Map application connections, data flows and shared services so you can choose migration groups and identify cross-environment risks.
Build a migration dependency map by showing which connections would break, slow down or change data ownership if a component moved. Label each material connection, then decide whether its endpoints must move together, can remain connected across environments for a time, or need more investigation before scheduling. A workload inventory identifies the parts; this map records the migration decision each relationship affects.
Begin with a business action
Take an important action, such as approving an invoice, and trace the components it uses. Include systems that call the application and those it calls, plus background work that completes the action later. Use a node for each component and a directed arrow for each material connection.
| Arrow field | Question to answer |
|---|---|
| Source and destination | Which component initiates the connection and which receives it? |
| Purpose and timing | Which action uses it, and when does it run? |
| Data and direction | What is read or written, and where is the authoritative copy? |
| Requirements | What name, identity, network path or response time does it need? |
| Failure effect | What stops, slows or becomes incorrect if it fails? |
| Owner and evidence | Who can verify its purpose, and what observation supports it? |
Mark a missing answer unknown. A connection visible in network data might be monitoring traffic, while a monthly export might be absent from a short observation period. Neither observation alone establishes the edge's business importance.
Check the evidence behind each edge
Compare configuration and architecture notes with logs, traffic observations and interviews. Record when each source was checked and include a period containing scheduled jobs or peaks where practical. Automated discovery may miss undocumented or infrequent work; owners may explain purpose but rely on outdated recollections. Resolve material disagreements before fixing a wave date.
Identify shared services without automatically placing every connected application in one move group. An identity service may stay where it is if the target can use it through a verified path. A database with several writers needs closer review of access, latency, consistency and which applications are affected by a database move.
Key Evidence Sources for Dependency Mapping
- Configuration & Architecture Notes
- Primary source for intended design and access paths
- Logs and Traffic Observations
- Reveals actual usage patterns over time, including peak periods
- Stakeholder Interviews
- Provides context and clarifies purpose when documentation is outdated
Decide what must change together
For each edge, ask whether the endpoints can work in different environments during the transition. A latency-sensitive synchronous call may require a joint move or a demonstrated interim path. A scheduled one-way feed may be separable if its delay, data correctness and support ownership are acceptable. Treat both as hypotheses until checked for the actual workload.
For example, an invoice application might use a shared identity service, write to a database and send a nightly partner export. The application and database may form one move group; identity and export may remain outside it if their paths work from the target. This example does not establish what a real invoice system can tolerate.
Record one decision beside each material edge: move together, keep connected during transition, or resolve before scheduling. For an interim connection, name its operator, required verification and intended removal point. If several applications write to one database, show each as affected even when only one is proposed for the wave.
Review the proposed group
Walk an important user action through the target arrangement, including background completion and components left behind. Ask owners which critical edges are missing and what evidence would settle open assumptions. Confirm that the move group includes the necessary components or has a workable, owned path to each external dependency.
Update the map when an integration, credential or release plan changes. The finished planning map should identify each critical edge, its evidence, owner and migration decision. It need not diagram every harmless packet.
