Dependency mapping is the identification of resources, behaviors, and responsibilities that a system requires to perform its work. Source-code relationships describe only the dependencies visible in the code available to the analysis.
A database call is a dependency. The identity authorized to execute it, the scheduled task that initiates it, and the operator who resolves a rejected transaction are also parts of the operating relationship. A map that records only the call leaves those conditions unexplained.
Different methods expose different relationships
Static analysis follows relationships inferred from source and build information. It can identify candidate calls and data flows without executing every path. Missing library source and runtime-selected targets limit what that analysis can resolve.
Runtime observation records interactions that occurred during an observation period. It supplies evidence that a particular process reached a resource under particular conditions. It does not establish that an unobserved path is impossible or unnecessary.
Configuration inspection records intended execution: command arguments, working directories, identities, schedules, and connection settings. User and operator observation identifies work and judgments outside the application’s own instrumentation. These methods complement each other because they inspect different parts of the system.
Record what the dependency supplies
A link between two application names is too coarse to define a migration boundary. The relationship must explain what the consumer obtains: a lookup, an authorization decision, a transaction update, a file, or a recovery service.
Direction matters. An application that reads a reporting database has a different dependency from one that writes the authoritative transaction record. The required timing and failure behavior also matter. A nightly export and an interactive lookup impose different continuity constraints even if both touch the same table.
Take a report produced by a scheduled script. The script’s executable path identifies the program. Its arguments select a period. Its working directory determines relative file resolution. Its identity determines access. The downstream recipient determines when the result is useful. None of those properties is supplied by the executable name alone.
Configured intent is not observed success
Windows Task Scheduler exposes task definitions with separate action paths, arguments, and working-directory properties. Reading those definitions establishes what is configured. It does not prove that a job ran successfully or produced the right business output.
Other launch mechanisms remain outside that scheduler’s inventory. Database jobs, another scheduling service, application events, and manual invocation require their own discovery evidence. A complete list from one tool is complete only within that tool’s scope.
The same distinction applies to registered components. A component can be present without being used. A dynamically loaded component can matter even when a particular source-analysis pass does not resolve the call.
Observation needs interpretation
Watching a successful workflow reveals actions and transitions. It does not automatically explain why the operator rejected one case, corrected a value, or waited for another team. Contextual investigation combines observation with questions about those decisions.
The interruption changes what is being observed, so the resulting record should distinguish natural execution from an explanation elicited afterwards. A business-rule interpretation remains a claim to confirm with an appropriate owner.
Rare paths require deliberate attention. Period-end processing, emergency recovery, and unusual exceptions can fall outside a normal working-day sample. Their absence from that sample is an observation boundary rather than proof of irrelevance.
A map that supports change
A useful dependency record connects the consumer, required resource, operation, execution context, and consequence of failure to dated evidence. Unresolved calls and disputed interpretations remain visible.
This permits a proposed change to ask a precise question: which required relationship changes, and how will the consumer’s requirement continue to be met? A diagram without those semantics shows connectivity. A dependency map with them supports sequencing, testing, and eventual removal of the old responsibility.