Network refresh cycles tend to follow a predictable pattern. Equipment ages. A budget cycle approaches. Someone schedules vendor demos. Bids come in. A decision gets made, usually based on some combination of price, vendor reputation, and what the incumbent already knows how to support.

By the time the new equipment is installed, no one is quite sure whether the original problems got solved, because no one ever defined them clearly in the first place.

Five questions worth answering before signing anything.

1. What specifically is broken — and how do you know?

"Our network is slow" is not a problem statement. It's a symptom report from a single perspective at a single moment.

A useful problem statement names specific workflows that aren't working, specific user populations affected, and ideally some quantification: "Our warehouse pickers experience 3-5 second scanner delays an average of 12 times per shift, which costs us approximately 90 minutes of productivity per picker per day."

If you can't write that sentence, the project hasn't started yet — you're still in the "vague complaint" stage.

The data to write that sentence comes from a few places: help desk ticket analysis, time-and-motion observation, user surveys, and ideally direct measurement of network performance from the endpoint's perspective. Most enterprises have access to the first three and not the fourth, which is part of why the fourth is increasingly valuable.

2. What's changing about how you actually use the network?

The mistake here is buying for the network you had, not the network you'll have. Common patterns that change network requirements:

  • Shift to video-heavy communication (Teams, Zoom, Webex)
  • Increased reliance on cloud-based applications instead of on-premise
  • Growth in connected devices (IoT, sensors, BYOD)
  • Expansion to additional sites with different connectivity profiles
  • Customer-facing workflows that depend on uptime
  • Workforce flexibility requiring guest, contractor, and remote access

Whatever you're buying needs to work for what you'll be doing 18-36 months from now, not what you were doing two years ago. The patterns that are stable now will probably not be stable then.

3. Are you buying infrastructure or buying outcomes?

This is the most important strategic question, and most enterprises skip it.

The traditional model: buy equipment, install it, operate it yourself (or with help). You own the asset, you control the configuration, you handle the support escalations.

The emerging model: buy an outcome — reliable connectivity for X users in Y locations at Z performance levels — and let a vendor figure out the infrastructure. You don't own equipment; you pay for a managed service. The vendor is responsible for upgrades, support, and meeting SLAs.

Both models work. The right choice depends on your team's expertise, your operational tolerance for surprises, and whether you'd rather have predictable monthly costs or amortized capital expenses.

What doesn't work is buying infrastructure when you wanted outcomes — ending up with equipment you don't know how to optimize, and chasing your vendor for support when things break. That's the worst of both models.

4. What's the cost of failure, and what does success look like?

Different facilities have radically different tolerances for downtime. A regional office might tolerate two hours of degraded connectivity once a month with no business impact. A hospital cannot. A 24/7 logistics operation cannot. A retail store on Black Friday cannot.

The infrastructure decision needs to match the operational tolerance. SLAs, redundancy levels, support response times, and monitoring depth should all be calibrated to "what does failure cost us?"

The corresponding question — what does success look like? — is just as important. "Things work" is too vague. "User-reported connectivity tickets drop by 60% within 90 days" is measurable. "Zero unplanned outages in critical zones for 12 consecutive months" is measurable. You can't manage to a vague success criterion.

5. Who owns this after the deployment is done?

Network refresh projects have a predictable post-deployment failure mode: the vendor leaves, internal expertise was never built, and within 18 months no one really knows how the new system works. Problems pile up, workarounds proliferate, and the next refresh cycle starts with "our network is slow" all over again.

This is preventable, but only if it's planned for. Before signing, agree on:

  • Who is the primary owner of the system internally?
  • What training do they get, and when?
  • What documentation gets handed over, and in what format?
  • What ongoing relationship exists with the vendor — quarterly reviews, dedicated success manager, just-in-case-of-emergency?
  • What's the escalation path when something inevitably breaks?

Vendors who can't answer these questions clearly are showing you something important: they're set up to sell, not to support.

The point

The right network overhaul is the one that solves a specifically defined problem, anticipates how the problem will evolve, matches infrastructure-vs-outcomes correctly, calibrates to actual operational tolerance, and has a credible ownership story. The wrong network overhaul is the one that started with "let's see what's available" and ended with whoever had the best demo.

Skipping the questions doesn't make the project faster. It just makes it more likely you'll be having the same conversation again in three years.