Campus LAN and WAN that survive migrations

In six stages: Discover (as-is inventory), Design (HLD/LLD), Automate, Test, Change and Document. At every point you can see what was decided and why — and the result is a documented network with an acceptance report and operations handover.

Four things, and the order decides. First the inventory: what hangs where today, and which dependencies does nobody remember any more? Second the target architecture as HLD and LLD — the picture before the purchase order. Third the migration during live operations, in waves with a fallback point per step rather than one big weekend. Fourth the acceptance with verifiable artefacts, so operations continue without the builder. What actually gets replaced follows from the first two steps — not from the age of the hardware.

At the border. The campus LAN carries access, distribution and core inside one site — that is where VLANs, routing domains and access policy live. The WAN connects sites to each other and to data centre or cloud, today usually as SD-WAN across two circuits. The interesting failures sit exactly on that seam: plan QoS, routing metrics and failover on one side only, and the first circuit outage reveals the other side assumed something different. We design both sides in one target picture — campus and enterprise WAN belong in the same document.

The high-level design describes the architecture — sites, redundancy, security zones — in language decision-makers can follow. The low-level design translates it into concrete engineering: devices, ports, VLANs, IP addressing and configurations. Only together do they make a network reproducible and testable.

Often yes — from two sites onwards, whenever availability matters. Two affordable internet lines with automatic failover usually beat a single leased line on both resilience and cost. A short analysis of your line costs and requirements shows whether it pays off.

Our focus is Cisco — Catalyst and Meraki — because depth delivers better results than breadth. We integrate existing environments from other vendors cleanly and document the boundaries; for a new build we recommend the platform that fits your requirements and budget.

Yes — that is a standard case for us. The Discover stage captures the as-is state automatically via CLI, SNMP and controller APIs and reconciles it with whatever documentation exists. The result is an honest inventory as the basis for every further decision.

We work remote-first for clients across Germany and the EU; on-site visits for surveys, rollouts or acceptance are agreed per project. Design, automation and operations work from anywhere — documentation is delivered in English or German.