Most MSP “methodology” pages are marketing. Process diagrams, certification logos, vague language about best practices. This one is different. What you’re reading is the actual decision framework I use when a client hands me their network, their phones, and their carrier contracts and asks what to do.
If you’re a CTO or VP of IT evaluating us, you should be able to read how I think before you ever pick up the phone.
If my framework matches yours, we’ll be a fit. If it doesn’t, you’ve saved yourself a meeting.
One note before you read further. This page names patterns I won’t recommend and calls out things I won’t sell. That’s on purpose. A consultant with no opinions isn’t worth hiring.
The most common mistake I audit is one carrier across every site because procurement was easier that way. It almost always costs more. It almost always performs worse. It usually creates a single point of failure nobody noticed until something broke.
I evaluate each building on its own. Here’s what matters.
Fiber availability and ownership. Not “is there fiber on the street.” Whose fiber, lit by whom, on what timeline. A building with three providers on-net is a completely different conversation than a building where the only option is a 60-day construction quote. Before I recommend anything, I pull serviceability from every carrier I represent. I don’t take the first “yes” and call it done.
SLAs, read carefully. Most business-class SLAs are written so the carrier almost never owes you anything. I look at the MTTR commitment, the chronic-trouble clause, and how outage credits gets calculated. A 99.99% SLA with a 4-hour MTTR and pro-rated credits is a very different document from a 99.9% SLA with next-business-day response and a credit cap of one month of service. Both will be marketed as “business class” or “carrier grade.”
Who rolls the truck. When a circuit goes down at 2 a.m. in Mansfield, somebody has to physically show up. I keep track of which carriers have real Ohio operations and which ones subcontract through three layers before anyone gets dispatched. This is one of the places regional fixed-wireless providers regularly beat the national names. They answer the phone and they’re 40 minutes away.
The contract. Term length, early termination liability, MAC fees, rate-lock language, what happens at auto-renewal. The carriers know most customers don’t read this part. I read it on every contract before anyone signs.
Routing options. If a building needs to multi-home or run failover at the network layer, you need a carrier that supports BGP with a public ASN. Not static routing. This quietly rules out a surprising number of “business class” products that are really residential-grade services in business clothing.
The honest answer most MSPs won’t give you: most of the SD-WAN deployments I audit are over-engineered for the actual traffic patterns. A vendor sold a Fortune 500 architecture to a 6-site regional business, and nobody pushed back.
Here’s how I think about the decision.
Stay on MPLS if you have predictable point-to-point traffic between a small number of sites, you’re running latency-sensitive legacy applications (manufacturing SCADA, some legacy ERP, voice on circuit), and your existing contract is priced reasonably for what you’re getting. MPLS isn’t dead. It’s just oversold as dead by SD-WAN vendors who want the replacement revenue.
Move to SD-WAN if your traffic is increasingly cloud-bound (Microsoft 365, Salesforce, AWS apps), you have more than four sites with widely varying bandwidth needs, you want application-aware routing or QoS that your MPLS provider wants a fortune to configure, or your MPLS renewal is coming up with a price hike that doesn’t pencil out. The real win with SD-WAN isn’t cost. It’s flexibility. That’s the right reason to switch.
Run a hybrid if you have a handful of sites that genuinely need MPLS-grade reliability (a primary data center, a 24/7 ops facility) and a larger number of branches where broadband plus SD-WAN is plenty. A vendor will try to tell you it has to be one or the other. It doesn’t.
Site count matters more than people admit. Under four sites, SD-WAN management overhead often isn’t worth it. Point-to-point IPsec with smart routing will get you 80% of the benefit at a fraction of the licensing. Over fifteen sites, SD-WAN is almost always the right call. The middle is where the real decision lives, and it’s made on application mix and security posture, not on a marketing spreadsheet.
On vendors, I deploy and support multiple SD-WAN platforms. I have opinions about which ones are over-licensed and which ones have firmware quality issues I won’t put on a customer network. I’ll tell you which ones on the call. I’m not going to put that in writing on the public site, and if you’ve been in this industry long enough you know exactly why.
The mistake I see most often is a $400-a-month “backup circuit” from the same carrier as the primary, routed through the same central office, sharing the same physical fiber path for the first six miles out of the building.
That’s not redundancy. It’s a line item on a bill.
Real redundancy is three separate decisions, and you have to get all three right.
The first is diverse media. Two fiber circuits from different carriers that share the same conduit are still a single point of failure when a backhoe shows up. Real diversity usually means fiber primary with fixed wireless or LTE backup. For most mid-market buildings, that’s the right answer. Fixed wireless costs more than a second cable circuit, and it’s worth every dollar the first time someone cuts a fiber in the street.
The second is whether you run active/active or active/passive. Active/passive is cheaper and simpler. The backup sits idle and kicks in when the primary fails. Expect 30 to 90 seconds of session disruption when it does. Active/active uses both circuits continuously with load balancing or application steering, no failover delay, more expensive, more complex to operate. The deciding question is: what breaks if you lose 60 seconds? Voice calls and active video meetings break. Web browsing and email don’t. Pick accordingly.
The third is routing logic, and this is where most failover designs actually fail. A backup circuit is useless if your firewall doesn’t fail over cleanly, your DNS still points at the primary path, or your SD-WAN policy doesn’t have a rule for the failure mode you’re trying to protect against. I test failover by pulling the primary circuit during a planned window. I don’t trust the configuration. About half the failover designs I inherit from other vendors have never been tested under real failure conditions, and a meaningful chunk of those don’t work.
“Redundancy” that’s two circuits from the same carrier on the same physical infrastructure. I’ll tell you it isn’t redundant. If you want it anyway because your CFO wants the line item on the books, I’ll document that decision in writing and we’ll move on.
Where the market actually is: Microsoft Teams Phone has taken more of it than the hosted VoIP vendors want to admit. It’s not the right answer for everyone, and I see it sold into the wrong situations all the time.
Teams Phone is the right call when your organization is already standardized on Microsoft 365 at E3 or E5, your phone usage is mostly internal collaboration and outbound business calls, and you don’t need heavy contact-center features or complex routing. The licensing math works because you’re already paying for the seats. The operational story is simple. The user experience is one app instead of two.
Hosted VoIP (Dialpad, RingCentral, 8x8, Zoom Phone, and others) is the right call when you need real PBX features Teams doesn’t do well. Multi-level IVRs. Complex hunt groups. Contact center routing. Advanced analytics. Integrations with industry-specific CRMs. Or when you have a significant non-Microsoft user population (manufacturing floor, retail locations, clinical staff) who shouldn’t need a Microsoft license just to make a phone call.
On-prem PBX is rare but not dead. Two scenarios where it still makes sense: highly regulated environments where cloud voice has compliance friction, and high-volume call centers where the hosted per-seat economics fall apart. If you’re considering on-prem for any other reason, you’re probably solving the wrong problem.
Hybrid setups (Teams Phone plus a hosted contact center overlay) are increasingly common for organizations with mixed needs. Knowledge workers on Teams, support and sales on a dedicated CCaaS platform. More vendors to manage, but it’s often the right architecture.
The biggest mistake I audit on the phone side: companies who picked a system off a feature checklist from a vendor sales deck, then realized six months later that 90% of those features sit unused and the 10% they need every day (mobile app reliability, voicemail-to-email, call recording retention) are mediocre. Pick on what your team will use, not on what the demo looked good doing.
I pull every carrier bill, every vendor contract, every circuit ID. I map what you have against what you need. Then I apply the framework above and tell you, in writing, what I’d change and why.
If the way I think lines up with the way you think, we should talk. If what you want is a vendor who’ll tell you what you want to hear and call it strategy, I’m not the right fit. I’ll say so on the first call, and we’ll both save the time.
If you read this and think I’m wrong about any of it — about MPLS, about Teams Phone, about how I evaluate carriers — that’s the most useful 20 minutes we could have. Call.