Networking
The full domain, and the other capabilities within it.
Network Infrastructure
The layer everything else assumes is working.
What this is
Network infrastructure is the switching, routing, cabling and resilience design that everything else depends on. It is the least visible capability here and the one whose failures are most expensive, because nothing above it degrades gracefully when it is wrong.
The common pattern is a network extended a floor at a time, where the original design is no longer written down and the redundancy is believed rather than tested. Most of the value is in restoring a design somebody can reason about.
When you need it
If more than one of these is true, this is usually the right place to start.
- A network extended piecemeal, with no current diagram anyone trusts.
- Switches past end of support, where a hardware failure means a procurement cycle rather than a spare.
- Redundancy that has never been tested by pulling a cable during working hours.
- A new site, floor or data hall that needs designing rather than extending.
What the scope covers
- Current-state survey: topology, hardware, firmware, licensing and support status.
- Access and core design, including uplink capacity and the failure modes each layer is meant to survive.
- Structured cabling and power, with the physical constraints that actually decide what is possible.
- Resilience design: link and device redundancy, convergence times, and what a failure looks like to a user.
- Configuration standards and change process, so the estate stays consistent after we leave.
What you receive
| Deliverable | What it contains |
|---|---|
| As-built documentation | Topology, addressing, VLANs and uplinks, reconciled against what the devices actually report. |
| Target design | Access, distribution and core with capacity assumptions stated, and the growth it is sized for. |
| Configuration standard | Templates per device role, naming, and a change process that keeps them true. |
| Migration plan | Sequenced with maintenance windows, rollback per step, and the tests that confirm each step held. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Proportion of the estate within vendor support and on the standard firmware baseline.
- Convergence time measured during a deliberate failover test, not quoted from a datasheet.
- Configuration drift from the standard, counted per device rather than averaged.
Questions we are asked
Do we need to replace everything at once?
Almost never, and proposals that say so should be read carefully. The usual approach replaces what is out of support or undersized, standardises the rest, and phases the remainder over budget cycles.
How much capacity should we design for?
Enough for the growth you can evidence plus headroom for the failure case, because a link sized for average load is oversubscribed the moment its pair fails. We size for the surviving path, not the happy one.
Is our cabling really a problem?
It is more often the constraint than people expect. Cable category and length decide what speeds are reachable, and a switch refresh that ignores the cabling is a refresh that cannot deliver the speeds it was bought for.
Can you work with our existing vendor?
Yes. The design is expressed in capability terms and then implemented on whatever platform you own or intend to buy, which also keeps the design reviewable by someone who does not know that vendor's syntax.
What about wireless?
Wireless is a separate capability with its own RF design, but it sits on this one. A wireless project on an undersized or unresilient wired network inherits every problem the wired network has.
How do you avoid downtime during migration?
By sequencing and by rollback, not by optimism. Each step has a maintenance window, a test that decides whether it held, and a documented way back — and steps that cannot be rolled back are identified before the night they run.
Continue reading
Enterprise Wi-Fi
RF design, controller policy and validation surveys for wireless that holds up under density — measured on site, not predicted from a floor plan.
SD-WAN & SD-Branch
Application-aware path selection, local internet breakout and central policy across branches — with the security design decided before the circuits change.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.