Straight answers to the questions CIOs actually ask.

For most UK organisations at the 1,000-user mark, the honest answer is Direct Routing, usually with Operator Connect as a complementary option for specific user groups. Microsoft Calling Plans become commercially and operationally awkward at this size: per-user pricing scales linearly, country coverage is uneven, and integration with analogue endpoints, paging systems or specialist contact-centre platforms is either unsupported or contrived.

Direct Routing with a UK-hosted active/active SBC pair gives you carrier choice, predictable per-channel pricing, full control of number ranges, and a clean integration point for SIP trunks, analogue gateways and contact-centre platforms. Operator Connect is useful for sites or user groups where the simpler Microsoft experience matters more than carrier flexibility — small remote offices, for example.

What matters more than the model is the surrounding design: resilience, survivability for critical sites, emergency-services configuration, fraud controls, and a licensing posture matched to actual user behaviour. We cover all of this in the Enterprise Teams Voice Guide.

They solve overlapping problems with different trade-offs. Operator Connect lets a Microsoft-approved carrier plug PSTN connectivity directly into your tenant with almost no infrastructure on your side — no SBCs to manage, minimal configuration, fast to enable. The trade-off is reduced flexibility: carrier choice is constrained to operators in Microsoft’s programme, and integration with legacy analogue, paging or specialist endpoints typically requires additional infrastructure anyway.

Direct Routing uses your own (or partner-managed) Session Border Controllers between Teams and any SIP carrier. You get carrier-agnostic procurement, full control of dial plans and routing rules, native support for analogue gateways and fax-over-IP, and clean integration with Teams-native contact centre platforms. The cost is operational: SBCs need to be sized, monitored, patched and tested.

For estates above ~500 users, mixed-site, or with any analogue, contact-centre or carrier-flexibility requirement, Direct Routing is usually the right backbone. Operator Connect can sit alongside it for user groups that don’t need the additional capability. The two models coexist comfortably in a single tenant.

Yes — with the caveat that "replace" means something different for the desk-phone estate, the analogue estate and the contact centre. A typical Mitel MX-One or MiVoice estate covers all three, and each needs its own replacement strategy.

For knowledge workers on softphones and IP handsets, Teams Phone with Direct Routing is a like-for-like upgrade and usually a better day-to-day experience. Voicemail, presence, call handling, call recording and reporting are all available natively or through well-established Teams add-ons.

For the analogue estate — lift lines, door entry, fire panels, DECT handsets in clinical or industrial settings — you don’t remove the analogue endpoints, you front them with analogue gateways that present as SIP to the SBC. This is well-trodden ground.

For the contact centre, Mitel’s native ACD/IVR is replaced by a Teams-native CCaaS platform (Anywhere365, Luware, Tendfor, Landis, NICE, Genesys and similar). Migration is usually phased: general users first, then contact centre once the new platform is bedded in. We cover the full Mitel coexistence pattern in the Teams Voice Guide.

Teams Phone is built on the Microsoft 365 global infrastructure, which is highly available by design — but resilience for a production voice estate isn’t a property you get for free from any single cloud. It is something you architect for.

For Direct Routing estates, the resilience pattern is active/active SBC pairs across two UK data centres, with diverse SIP carriers, geographic PoP diversity and dial-plan logic that fails calls between routes automatically. Either side can absorb full load. This is what enables the estate to ride through a carrier outage, a single-PoP failure, or maintenance on either SBC pair without users noticing.

For sites where the loss of dial tone is unacceptable — an NHS Trust switchboard, a 24/7 council emergency line — the Survivable Branch Appliance (SBA) pattern adds local survivability: if the WAN drops or Microsoft 365 itself is unreachable, the SBA takes over and the site keeps dialling out, including 999.

Properly designed, a Teams Phone estate has an effective RTO of zero for most failures and tested DR runbooks for the rare scenarios it can’t absorb in-line. Properly designed is the operative phrase.

Yes, and for any migration above a few hundred users it has to — nobody big-bangs a legacy PBX. The integration pattern is coexistence via SIP at the SBC layer.

The legacy PBX (Avaya CM/Aura, Mitel MX-One or MiVoice, Cisco UCM, Unify OpenScape) is connected to the same SBC pair that fronts Teams, on its own SIP trunk group. Calls between Teams users and PBX users route internally through the SBC; calls to/from the PSTN can be steered to either platform based on DDI ownership. Users are migrated wave by wave, and their DDIs move with them — in most estates without the carrier needing to touch anything.

The practical work is mostly in the application layer: voicemail consolidation, attendant console replacement, contact-centre cutover, integration with CRM and case management. Each legacy vendor has its own gravitational mass — Cisco UCM estates are typically the most complex because of UCCX/UCCE, Unity and Jabber; Mitel estates often have the deepest analogue and DECT footprint. Phased coexistence windows of 3–9 months are normal and healthy.

Teams voice is light by modern standards. A single Teams Phone call typically uses Microsoft’s SILK or Satin codecs and consumes roughly 30–100 kbps per concurrent call in each direction, including the IP overhead. Microsoft’s own network planning guidance allows around 100 kbps per call as a safe sizing number for peer-to-peer Teams calls.

For an estate of 1,000 users, you don’t plan for 1,000 concurrent calls — typical peak call concurrency for an office population sits around 15–25% of headcount. So 1,000 users equates to roughly 150–250 concurrent calls at peak, or about 15–25 Mbps of bidirectional voice traffic. A few thousand users typically remains comfortably inside any enterprise WAN or internet circuit.

What matters more than raw bandwidth is quality of service: voice packets need to be marked (DSCP EF) and prioritised end-to-end, jitter buffers configured sensibly, and Teams traffic given a direct path to Microsoft 365 endpoints (split-tunnel VPN, local internet breakout). The estate that fails on day one isn’t the one with insufficient bandwidth; it’s the one where all voice traffic is funnelled through a single VPN hub.

Yes — through a layer of Teams-native CCaaS platforms that sit on top of Teams Phone, rather than through Microsoft’s own native call queue features (which are fine for small, informal queues but not for a real contact centre).

The two architectural patterns are Connect (CCaaS uses the Teams client and Teams Phone underneath) and Extend (CCaaS provides its own agent app but federates with Teams for presence and collaboration). UK enterprises commonly deploy Anywhere365, Luware, Landis, Tendfor, and for larger or omnichannel estates NICE CXone for Teams or Genesys Cloud for Teams.

Capabilities are at parity with traditional ACD platforms: skills-based routing, IVR, callback, supervisor wallboards, quality monitoring, compliance recording, and integration with CRM and case management systems. Voice AI — voicebots, agent-assist, real-time transcription — layers on top via a Voice AI gateway like AudioCodes VoiceAI Connect; see the Voice AI in Teams guide for the architecture.

The pragmatic stance: let the CCaaS platform own routing, recording and reporting; let Teams own the user experience; and keep the two layers swappable so neither vendor owns the roadmap.