Reading a network you did not build

Before you change anything in a network somebody else built, you have to know what it actually does — which is rarely what the diagram says and never what you were told.

Inheriting a network is the most common engagement in this line of work, and the most commonly rushed. The pressure is to demonstrate progress quickly, and reading configurations does not look like progress. It is, though, the step that determines whether everything after it succeeds.

Start with what is running, not what is documented

Collect every running configuration and read them side by side. Diff the branches against each other: the variations tell you the history of the network, and every unexplained difference is either a deliberate exception nobody recorded or a mistake nobody noticed. Both are worth knowing before you touch anything.

Documentation, if it exists, is a hypothesis to test. It is usually accurate about intent and wrong about current state.

Find the load-bearing accidents

Every long-lived network contains something that was meant to be temporary and is now essential. A static route added during an incident three years ago. A firewall rule with no comment that everything depends on. An address range that overlaps something else and works only because of the order two routes happen to be installed in.

These are the things that break during an otherwise correct migration. Find them by looking for what does not fit the pattern, then trace what depends on it before deciding it is safe to remove.

Establish the real topology

Not the physical cabling — the logical path traffic takes. Where routing actually converges, which links are carrying what, and which redundant paths are genuinely redundant versus drawn twice on a diagram. Some of this can only be learned by watching the network under load.

Ask what changed recently

People remember incidents better than configurations. Asking which parts of the network have caused trouble in the last year is often faster than finding the same information in the devices, and it tells you where the team already suspects a problem.

Write it down before proposing anything

The audit is a deliverable in its own right. Even if the client never proceeds to the work, they now have an accurate picture of their own network, which most organisations do not. And it protects both sides: everything proposed afterwards refers back to a documented starting state that both parties agreed on.

Then, and only then, design

Design proposals made before this step are guesses dressed up as engineering. They are also the reason so many migrations produce a second outage a month later, in the one part of the network nobody looked at.