Most enterprise IT leaders didn’t choose their current voice infrastructure. They inherited it. A PBX purchased a decade ago, patched together with SIP trunks and a handful of workarounds, is still routing every customer call and internal transfer in the building. It works, until the day it doesn’t.
Increasingly, the practical alternative enterprises are evaluating is a carrier voice platform for enterprises, infrastructure originally built for telecom carriers and now repackaged for IT teams that want voice to behave like every other cloud service they manage. What that shift actually involves, and what to ask before making it, deserves more attention than most vendor pitches give it.
The slow failure mode of on-premises voice
On-premises voice systems rarely fail all at once. They fail slowly through accumulating cost and risk that’s easy to underestimate until a renewal notice or an outage forces the issue.
Vendor risk emerges first
Vendor and hardware risk is the first place this shows up, and it isn’t hypothetical. Avaya, long the number-two vendor in the on-premises PBX market, filed for Chapter 11 bankruptcy twice in six years, most recently in 2023. It has since narrowed its support model toward larger deployments, discontinuing direct support for smaller contact center customers and pushing its remaining on-prem base toward cloud migration on a timeline the vendor set, not the customer.
Carrier-side softswitch platforms have followed a similar arc: several long-standing platforms have moved through acquisitions and ownership changes that left customers managing an unplanned migration. The pattern repeats because single-vendor, single-platform architectures concentrate risk that IT teams don’t always price in at purchase time.
Maintenance consumes scarce IT resources
Maintenance is the second cost, and it’s mostly invisible on a budget line because it shows up as staff time rather than a bill. Every firmware update, every capacity upgrade, every troubleshooting session on a proprietary appliance is time an already-stretched network or telecom team isn’t spending on higher-value work.
Organizations with global offices feel this most acutely: each site may need its own hardware, its own local expertise, and its own maintenance schedule.
Growth is constrained by infrastructure
Scalability is capped by design, not by choice. On-prem systems are sized for peak load at the time of purchase. Adding a new office, absorbing an acquisition, or handling a seasonal spike in contact center volume often means new hardware procurement, not a configuration change. That lag between business need and infrastructure capacity is where a lot of enterprise voice frustration originates.
Compliance exposure grows with every patch cycle that gets deferred. STIR/SHAKEN caller authentication, the FCC’s TRACED Act provisions, and PCI DSS requirements for any environment handling payment card audio all assume infrastructure that’s actively maintained and centrally auditable. Aging on-prem systems increasingly aren’t either.
None of this means on-prem voice is universally wrong. It means the calculus that justified it a decade ago rarely holds today for enterprises with multiple locations, hybrid or remote workforces, or regulatory exposure.
What “carrier-grade” actually means
What is carrier-grade voice infrastructure? It’s a system built to the reliability, redundancy, and compliance standards that telecom carriers themselves require to move traffic at scale: typically a 99.99%+ uptime commitment, geographically redundant points of presence, and native support for call authentication and fraud-prevention standards. It’s designed to survive a regional outage or a sudden traffic spike without manual intervention, because carriers can’t afford downtime, and increasingly, neither can the enterprises now buying that same class of infrastructure.
Built-in redundancy
In practice, that definition breaks down into three things an enterprise IT buyer can verify rather than take on faith. Redundancy has to be built in by design, not added as an exception. Traffic should reroute automatically across points of presence if one region degrades, as a default operating mode rather than a disaster-recovery afterthought.
Native compliance
Compliance has to be native rather than bolted on, with STIR/SHAKEN attestation, Do-Not-Originate list enforcement, and calling-party-number validation built into the platform itself rather than sold separately as a way to check a box.
API-first operations
And the operating model has to be API-first, with routing, provisioning, and analytics exposed through APIs so IT teams can integrate voice into existing OSS/BSS systems instead of managing it through a disconnected admin console.
What “Microsoft Teams Direct Routing” solves for
Any enterprise running Teams for collaboration eventually hits the same question: how does it actually make and receive outside phone calls? What is Microsoft Teams Direct Routing? It’s a Microsoft-defined interconnection standard that lets a certified session border controller (SBC) connect Teams directly to the public telephone network, so calls to and from outside numbers route through Teams without a separate calling app. The certification matters because it implies a tested support path between the vendor and Microsoft. A platform that’s merely “Teams-compatible” hasn’t necessarily cleared that bar.
For enterprise IT teams already standardized on Teams, this is often the single biggest factor in a voice platform decision, because it determines whether phone calling feels native to the collaboration tool employees already use or like a bolted-on second system.
What enterprises should actually look for in a replacement
Not every carrier-grade platform is built the same way, and the differences matter more than the sales decks suggest.
Ownership vs. management
The first question is ownership versus management. Some vendors position themselves as managed service providers: they run your voice environment for you. Others provide infrastructure-as-a-service, where the enterprise retains operational control over routing, policy, and analytics while the vendor handles the underlying network. Neither model is inherently better; they solve different problems. Managed services suit teams that want voice off their plate entirely. Infrastructure-as-a-service suits teams that want control without owning hardware.
Interconnection and routing intelligence
Interconnection breadth matters more than claimed coverage. Ask how many carrier interconnections the platform actually maintains and how routing decisions get made. Cost-only least-cost routing is a different thing entirely from routing that balances cost against completion rate and latency in real time.
Visibility through reporting
Reporting granularity is easy to overlook until it’s needed. Near real-time call detail records matter for fraud detection and for diagnosing quality issues before customers complain; batch reporting delivered hours later defeats the purpose.
SLA credibility and vendor stability
And any SLA needs credible math behind it, not just an impressive number on a homepage. What matters is whether a 99.99% uptime figure is backed by geographically redundant infrastructure you can ask about directly, rather than a number sitting in a contract with no architecture behind it. Vendor stability itself deserves the same scrutiny. Voice infrastructure changes ownership more often than buyers expect through acquisitions and asset sales, and each change can reset a roadmap or a support commitment.
Questions to ask vendors before switching
A short, direct list worth bringing into any vendor evaluation call:
- What’s your actual uptime track record over the past 12 months, not just the SLA target?
- Is your platform natively STIR/SHAKEN compliant, or does that require a separate integration?
- What happens operationally if one of your points of presence goes down? Is failover automatic, and how fast?
- Do we retain control over routing policy and analytics, or are we handing that management layer to you?
- If we run Microsoft Teams, is your SBC formally certified for direct routing or just described as compatible?
- How long does onboarding a new office or region typically take, end to end?
Vendors who answer these with specifics, rather than reassurance, are usually the ones worth shortlisting.
The market has several credible options
Enterprise IT teams evaluating this shift have a genuinely competitive field to choose from.
CPaaS platforms
Twilio and Vonage have built strong developer-facing CPaaS ecosystems well suited to teams that want to build custom call logic. Bandwidth and Telnyx offer direct carrier network ownership paired with programmable APIs. That combination suits teams that want infrastructure control down at the network layer, not just at the application layer.
Traditional SBC deployments
On the SBC hardware and virtual-appliance side, AudioCodes and Ribbon remain established names for enterprises that prefer a more traditional integration path alongside existing UC deployments.
An infrastructure-first approach
Dallas-based 46 Labs is a carrier voice platform for enterprises, and it treats the ownership question above differently from most managed-service vendors. Rather than operating as a managed service, its PeerEdge Voice Infrastructure is built so the enterprise keeps operational control of routing, policy, and analytics while the underlying network (including STIR/SHAKEN compliance, redundant points of presence, and Microsoft Teams Direct Routing certification) is handled at the infrastructure layer.
Evaluating the claims
The company is NPAC certified and a Microsoft partner, and per its own published materials, processes traffic for hundreds of global carriers and Fortune 500 companies daily. Its published performance data cites a 99.99% uptime SLA, a 30% average cost savings for enterprises on the platform, and figures around 50% faster region deployment and a 70% reduction in manual routing effort. These are specific, vendor-published benchmarks worth verifying directly with the vendor during evaluation rather than accepting at face value.
The practical takeaway
The decision to move off on-premises voice rarely comes down to a single dramatic failure. It comes down to the accumulated weight of maintenance hours, capped scalability, and compliance risk that keeps growing while the infrastructure stays the same, plus the real possibility that a vendor’s own roadmap shifts out from under you. Carrier-grade infrastructure built around redundancy, native compliance, and API-driven control addresses that weight directly, but the right fit depends on how much operational control your team wants to retain versus hand off.
Before signing anything, request a reference architecture diagram, ask for real (not target) uptime data, and have your compliance team confirm how STIR/SHAKEN and TRACED Act obligations are actually implemented rather than simply claimed. That diligence, more than any vendor’s positioning, is what determines whether the switch solves the problem or just moves it.
