Application dependency mapping is the work of finding every connection an application relies on, including other servers, databases, directory and time services, licenses and partner links, so systems that must stay together move together. It is your IT team's job, and the move groups it produces set the order in which hardware is shut down, trucked and re-racked.
Get the map right and systems move together in sequences that hold. Get it wrong and an application arrives at the destination separated from something it silently needed, which surfaces as an outage nobody planned for and few people can immediately explain. The map is also the deliverable planning teams most often assume already exists. It usually does not, at least not in the form a migration requires.
Why isn't the CMDB enough?
Because a configuration management database records what was documented at the time someone documented it, and migration planning needs to know what is true now.
The gap comes from ordinary operational history: integrations added under deadline, servers repurposed without records being updated, temporary connections that became load-bearing, and systems inherited through acquisition that were never fully catalogued.
Treat the CMDB as a starting inventory and a cross-check, not as evidence. Anything it asserts should be confirmed by observation before a move group is built on it. The physical side of the same problem is covered in reconciling the CMDB against physical inventory.
Which discovery methods should you use?
Several, because each one sees something the others miss.
| Method | What it finds | What it misses or costs |
|---|---|---|
| Passive network flow analysis | What actually communicates with what, comprehensively at the network layer, with no agents | Which process on a host owns a connection, or why |
| Agent-based discovery | Process-level connections with accuracy flow data cannot match | Deployment effort, change approval, and platforms where agents cannot be installed |
| Configuration review | Intent: connection strings, host files, application configuration, scheduled job definitions, hardcoded addresses | Anything not written down in configuration |
| Interviews with application owners | Business context: which integrations matter, what runs quarterly, which manual processes touch the system, what broke at the last restart | Anything the owner has forgotten |
No single method is sufficient. Flow analysis finds connections nobody remembers; interviews find dependencies that generate no traffic until the day they do.
How long should you observe network traffic?
At least a full month, and preferably a window that includes a month-end close. A week of flow data captures daily patterns and misses everything else. Monthly close, quarterly reporting, annual processes, disaster recovery replication, patch cycles, and long-interval batch jobs all produce connections that appear rarely and matter enormously.
Where quarterly or annual processes exist, capture them explicitly through interviews and configuration review rather than waiting to observe them. A business impact analysis of the kind described in NIST SP 800-34 is a useful source for which processes run on long cycles.
What should you record for each dependency?
- Source and destination systems, identified consistently
- Port, protocol, and direction
- Frequency and data volume
- Latency sensitivity, and the basis for that assessment
- Business criticality of the connection, not just of the systems
- Whether the connection tolerates a brief interruption or fails hard
- Owner on each side
The tolerance column is the one that changes sequencing decisions. A connection that retries gracefully permits a staged move; one that fails permanently on a dropped session forces both ends into the same window.
Which dependencies get missed most often?
Infrastructure services, because nobody treats them as part of an application's footprint:
- Hardcoded IP addresses in configuration files, which survive DNS changes and break on re-addressing
- License servers, including hardware-keyed appliances
- Authentication and directory services: AD, LDAP, RADIUS
- DNS, NTP, and certificate infrastructure
- SMTP relays, which surface when notifications stop rather than when applications fail
- Monitoring, logging, and other agents reporting to fixed collectors
- Batch jobs initiated by other systems on schedules the application team does not own
- Third-party and partner connections, often with firewall rules keyed to source addresses
- Physical dependencies: dongles, fax boards, serial connections to building systems
Time synchronization and certificate paths cause a disproportionate share of post-move failures, and both fail in ways that look like something else entirely. Check where every system gets its time, whether an internal source or a public reference such as the NIST Internet Time Service.
How do dependencies become move groups?
A move group is a set of systems that must move together because the coupling between them cannot tolerate separation. Building groups means deciding, for every dependency, whether it can span the origin and destination during the transition.
- Identify latency-sensitive pairs and keep them in the same group
- Identify connections that will cross a WAN link after the move and validate them at realistic latency first
- Flag dependencies crossing group boundaries as explicit transition risks with a mitigation
- Sequence groups so that shared services move before or with the systems that depend on them
Shared infrastructure deserves particular care. Directory services, DNS, and certificate authorities are depended upon by nearly everything, so they rarely fit any single group and need a deliberate strategy of their own.
Once your team fixes the groups, they become the physical schedule: which racks are de-installed together, which truck they ride on, and which go back into service first. Recording both in one migration workbook keeps the IT plan and the move plan aligned.
Why does latency matter so much?
Because applications built on a local network make assumptions about round-trip time that nobody wrote down. A chatty application performing thousands of round trips per transaction runs comfortably at sub-millisecond LAN latency and becomes unusable at ten milliseconds, without any error, alert, or failure. It simply gets slow enough that the business stops working.
This is the failure mode dependency maps exist to prevent, and it cannot be predicted from a diagram. Test it: introduce the expected latency between the components in a test environment and measure transaction times before committing to a split. The trade-offs between moving everything at once and moving in waves are covered in lift-and-shift, cold, and phased migration.
How do you validate the map?
- Review each application's map with its owner, and record disagreements rather than resolving them silently
- Cross-check flow-derived dependencies against configuration files
- Where feasible, test isolation in a non-production environment and observe what breaks
- Reconcile against the CMDB and investigate every discrepancy in both directions
Discrepancies deserve attention in both directions. A system in the CMDB with no observed traffic may be genuinely dormant, or may be the quarterly process that has not run yet.
How quickly does a dependency map go stale?
Immediately. Dependency maps begin aging the day they are completed: environments change, integrations are added, systems are retired.
Re-verify critical paths close to the move date, and keep flow collection running through the migration period. The map that guided planning three months ago is a plan; the one refreshed last week is a control.