What a dependency map costs — and what skipping one costs more

Every migration overrun we have seen traces back to the same root cause, and it is never the thing on the risk register. It is a dependency nobody knew about, discovered during a cutover window, at the point where rolling back is expensive and pressing on is worse.

The uncomfortable part is that discovery is unglamorous. Two weeks of interviews and packet captures produces a document, not a running system. Sponsors who have just approved a migration budget want to see workloads moving. Saying "we are not touching anything for a fortnight" is a hard sell, and it is the right call almost every time.

What the map is actually for

Not for the systems you know about. Those are on the architecture diagram already. The map exists to surface the four categories that are never documented:

• Scheduled jobs on machines that are not in the inventory, usually running as a departed employee's account
• Hardcoded IP addresses and hostnames in configuration files, which survive a lift-and-shift right up until DNS changes
• Database links and linked servers connecting two systems that officially do not integrate
• Licences tied to a MAC address, a hostname, or a physical dongle in a rack you are about to decommission

Every organisation has at least one system that everything quietly depends on and nobody owns. It is not on the diagram because the person who built it left.

How to actually build one

Three sources, and you need all three because each misses what the others catch.

Network flow data

Capture for a minimum of two weeks, and prefer a full month if a period-end process exists. This is the single most common discovery mistake: a week of capture misses everything that runs monthly, and the monthly job is disproportionately likely to be the fragile one.

Configuration inspection

Grep the configuration for IP literals, connection strings, and file share paths. Flow data shows you traffic that happened; configuration shows you intent, including paths that only fire under conditions you did not observe.

Conversations

Ask the people who get paged what they worry about. Not the architects — the operators. The question that works is: "if you had to take this down for an hour, who would call you?" People who cannot describe an architecture can always answer that.

The arithmetic

Two engineers for two weeks is a real cost and easy to quantify. Set it against the alternative: a cutover that fails, a rollback that has never been rehearsed, a business day lost, and the credibility cost of the second attempt. The discovery phase is cheaper than one failed weekend, and failed weekends are the normal outcome of skipping it.

There is a second return that is harder to price. The map outlives the migration. It becomes the disaster recovery plan, the onboarding document, and the thing you hand an auditor. Teams have told us afterwards that the inventory turned out to be more durably useful than the migration it enabled.

One rule makes it stick: nothing moves until the map is signed off. Not as a bureaucratic gate — as an admission that a plan built on an incomplete inventory is a guess wearing a Gantt chart.