If you’re running a multi-site rollout, you know the worst time to discover that gap is during the install window. By then, the technician is on site, the change window is underway, and the team is trying to keep the migration moving without disrupting the business.
Most rollouts are scoped around the documented network, not the network the technician actually finds on site. The diagram says one thing, the closet says another, and the person with the most context on how it was originally set up left two years ago.
That is when small unknowns become expensive. The team is no longer planning around constraints before work begins. They are reacting to them live, while the rollout is already in motion.
The Site May Not Be Ready
The most basic failures are physical, and they are the ones a site survey is supposed to prevent. A closet with no spare rack space. No powered, ready rack. Cabling that was never run. A cellular signal that reads fine on a planning sheet but will not hold in the actual mounting spot.
These checks may seem obvious, but basic does not mean solved. In multi-site rollouts, readiness is often confirmed at the wrong level. Teams confirm that a site has the right components in theory, but not whether they are usable for the actual install. That gap is where simple issues become day-of-install problems.
Most experienced teams know to check space, power, cabling, access, and signal strength. But those checks only confirm that the site can host the equipment. They do not confirm that the live network matches the design everyone is working from.
The Network May Not Match the Documentation
Even when the site is physically ready, the network you were handed on paper may not be the one you are running. Circuits are shown as installed in the carrier portal, but they do not pass traffic. Segments appear that were never on a diagram. Local routing exists because someone solved a problem years ago, and nobody documented the reason.
A new deployment plan may assume the site will move cleanly from the old network setup to the new one. But in reality, old connections, backup links, VPNs, MPLS circuits, local internet breakout, or legacy routing may still need to stay live during the transition. The new design has to work around them, not just replace them instantly.
Security Policy May Not Match the Traffic
Security is not a separate phase that happens after the network is up. It becomes part of the deployment the moment traffic has to move securely.
This is where live changes start to pile up. Firewall rules need editing during cutover. SD-WAN policies do not match how applications flow. SSE or inspection paths are not aligned with the new design. A licensing issue or portal access problem blocks the one change the team needs to make.
The hardest version of this is not technical. It is operational. The fix may be clear, but nobody on the call has the authority to approve it. Or it is unclear whether the network team or the security team owns the decision.
Hidden Dependencies Appear After Cutover
Some of the worst surprises arrive after the install looks finished. The link is up, traffic is flowing, and the team has packed up. Hours later, the branch reports a problem: a building system is down, or an application stopped working. Something existed, worked, and quietly depended on the network in a way nobody had documented, until the deployment changed the thing it relied on.
It might be a door-entry system, a payment terminal, or a piece of OT on the floor. It worked yesterday, so it was never on anyone’s list. Those dependencies are usually tribal knowledge, held by whomever happened to set them up, and they only become visible when they break.
The Cost Shows Up Fast
The cost is not just the failed install. It is the return site visit, the extended change window, the delayed rollout, the emergency bridge calls, and the unplanned downtime.
A small, unknown issue at one branch becomes much more expensive when it is discovered during the installation window. The team gets pulled away from managing the migration and into live troubleshooting while still trying to keep the business running without interruption.
Why Earlier Is the Only Real Fix
Here’s the part that’s easy to feel and hard to act on: Your ability to influence the outcome is highest before anyone shows up, and it drops off fast once the install starts. A problem found during discovery is a planning decision. The same problem found on install day is a fire.
So, the work that decides whether a rollout goes smoothly mostly happens beforehand:
- A real low-level design, not a reference architecture with site names pasted in
- Actual discovery at the site, not an inherited asset list
- Naming the likely gotchas per location before a date gets booked
You will not eliminate every surprise. Sites will still surprise you. The difference is whether you are dealing with a known risk or being blindsided during the install window.
Install Day Should Not Be the Discovery Phase
The point I’d stress: The installation day should not be the discovery phase, because the real decisions need to be made before anyone arrives on site.
There is no such thing as a simple network deployment. Every site has its own history, shortcuts, dependencies, and constraints.
That is why discovery matters. Not the kind of discovery that checks the site against a list, but the kind that asks a harder question: What are we assuming is true here, and what happens if it is not?
Author
James Cancel - Senior Director, Engineering and Activations
James is a telecommunications and network operations leader with more than 16 years of experience across leadership, network design, service activations, troubleshooting, SD-WAN, wireless networking, hosted voice, and customer support. Combining hands-on technical expertise with operational leadership, he brings a practical view of what it takes to move complex network deployments from design to working service.