Dependency Mapping

Back to Cloud Infrastructure Consulting · Service Offerings

Dependency mapping establishes what each workload actually talks to, so nothing gets migrated in isolation and breaks on day one. It is the first step of a cloud readiness assessment, and the one most often skipped — because the team is confident they already know, and because every hour spent on it produces no visible progress.

That confidence is usually the problem. Migrations rarely fail on the workload being moved. They fail on the connection nobody remembered: the reporting job that reaches straight into the production database, the hardcoded IP in a script written by someone who left, the licence server that has to be reachable or the application refuses to start. None of these appear in an architecture diagram. All of them surface at 02:00 on cutover night.

1. What a Dependency Actually Is

Before discovery, it is worth being precise, because “dependency” is used loosely and the loose version leaves gaps.

• Outbound calls: what this workload connects to — databases, caches, internal APIs, third-party services. The obvious category, and the only one most inventories cover.
• Inbound callers: what connects to it. Moving a service changes its address; everything upstream is affected, and the upstream team may not know they are upstream.
• Infrastructure dependencies: DNS, NTP, LDAP or Active Directory, certificate authorities, licence servers, SMTP relays, log and metrics collectors. Invisible until they are gone.
• Data dependencies: a shared filesystem, a database another team reads directly, a nightly export another system waits for. No network connection from the application, and a hard dependency all the same.
• Human and scheduled dependencies: cron jobs, CI pipelines, someone's laptop running a script monthly. These are real, and they are never in the diagram.
• Directionality and hardness: whether the caller degrades gracefully or stops. A cache it can live without is a very different migration risk from a database it cannot.

2. Discovery — Four Sources, Because No Single One Is Complete

Every discovery method has a characteristic blind spot, and they are different blind spots. We use all four and reconcile them against each other, which is what makes the result trustworthy.

• Ask the team. Fast, and the only source that captures intent — why a connection exists and whether it still should. It misses exactly what people have forgotten, which is the dangerous part.
• Read the configuration. Connection strings, environment variables, Docker Compose and Kubernetes manifests, nginx upstreams, cron tables, firewall rules. Concrete and auditable; blind to anything resolved at runtime through service discovery or a feature flag.
• Watch the live connections. ss, conntrack, VPC flow logs, or an eBPF-based collector, sampled over days rather than minutes. This is the only source that shows what is actually happening. Its blind spot is time: a job that runs on the last day of the month will not appear in a one-week capture.
• Mine the logs you already keep. DNS query logs and firewall accept logs going back months catch precisely the rare, scheduled traffic that live capture misses. This is the step that finds the quarterly reconciliation job.

We deliberately do not require an agent on every host. On systems where one is unwelcome — appliances, vendor-managed boxes, anything under a support contract that an agent would void — network-side capture and log mining get us the same edges without touching the machine.

3. Reconciliation — Where the Value Actually Is

Four sources produce four partial maps, and the interesting output is not their union but their disagreements:

• Named but never observed. The team believes a connection exists; no traffic confirms it over months of logs. Usually dead. Retiring it is cheaper than migrating it, and this routinely removes a meaningful share of the work before it starts.
• Observed but never named. Traffic is flowing that nobody could account for. This is the category that breaks cutovers, and it is the reason the exercise is worth doing.
• Named differently by each end. The caller thinks it is talking to a load balancer; the owner thinks that path was decommissioned. Both are describing something real and neither description is complete.

Each edge in the final map carries how it was found, when it was last seen, its direction and protocol, and whether the far end's owner has confirmed it. An unconfirmed edge is not an error — it is a question with a name attached to it.

4. Turning the Map Into Migration Waves

A dependency map that is only a picture has not paid for itself. Its job is to determine the order of work — which is a topological sort of the graph, with the cycles as the interesting part.

• Leaves move first. Workloads nothing depends on carry the least blast radius and are where the process gets rehearsed.
• Cycles move together. Two services that call each other cannot be split across waves. A cycle is not a scheduling puzzle to be solved — it is a single cutover window, and finding it late is how a migration plan loses a weekend.
• Latency-sensitive pairs stay together. If a chatty application and its database end up on opposite sides of a WAN link mid-migration, the system is technically up and practically unusable. The map shows which pairs cannot be separated even temporarily.
• Each wave gets its own rollback. By wave three the earlier waves are live in the new environment, so “roll back” means something different each time and has to be written down each time.

5. Beyond Migration

The map keeps earning after the move, which is why we hand it over in a form your team can regenerate rather than as a one-off PDF:

• Disaster recovery. A critical application is only as resilient as its least resilient dependency. The map is what turns that from a slogan into a list — see disaster recovery planning.
• Incident response. When something breaks, the map answers “what else is affected” and “what could have caused this” in seconds rather than in a call with four teams on it. It pairs directly with downtime prevention work.
• Change review. Decommissioning a server stops being a guess about who still uses it.
• Blast-radius review for security. The map is also a reachability map, which is what patch prioritisation and network segmentation both need.

Where it is worth the effort, we wire discovery into existing monitoring so the map refreshes itself. A dependency map is accurate on the day it is produced and decays from then on; one that regenerates weekly from live data stays useful for years.

What You Get

• A dependency graph of the in-scope estate, in a format you can query and diff — not only a diagram.
• A per-workload list of inbound and outbound dependencies, each tagged with how it was discovered, when it was last observed, and whether it is confirmed.
• The reconciliation findings: candidates for retirement, and undocumented connections that need an owner.
• A proposed wave ordering with the cycles and the inseparable pairs called out explicitly.
• The collection scripts, so your team can re-run discovery without us.

Talk to us if you are planning a migration, a data-centre exit, or a decommissioning programme and are not certain what the affected systems are connected to. It is a short, bounded piece of work, and it is far cheaper before the cutover than during it.