Your Avaya PBX has been the backbone of your enterprise voice for years — maybe decades. It's reliable, your team knows it, and it works. But Avaya Aura 10.1 reaches end of support in January 2026, and the clock is ticking.
After that date: no security patches, no vendor support, no fixes when things break. Your voice infrastructure becomes a liability — and a compliance risk if E911 isn't properly maintained.
This guide walks through everything involved in migrating from Avaya to Microsoft Teams using Direct Routing. It's written for IT leaders and telecom architects who need to understand the scope before they commit.
Why Avaya Enterprises Are Migrating Now
Three forces are driving Avaya customers to Teams:
1. Avaya Aura 10.1 end of support (January 2026). This is the hard deadline. After January 2026, Avaya will not provide security patches, bug fixes, or technical support for Aura 10.1. If you're running this version — and most Avaya enterprises are — you're on a countdown.
2. Avaya's post-bankruptcy strategy. Avaya emerged from Chapter 11 bankruptcy with a focus on cloud-based CX (customer experience) platforms, not PBX. The company has deprecated its PBX and UCaaS lines. The message from Avaya is clear: they're not investing in the product you're running.
3. Microsoft Teams adoption. Most Avaya enterprises already have Microsoft 365. Teams is already on every desktop. Extending Teams to handle voice is a natural consolidation — one less vendor, one less infrastructure stack, one less set of phones on desks.
The question isn't whether to migrate. It's how, and on what timeline.
Avaya-to-Teams Migration: What's Involved
Migrating from Avaya to Teams is not a "export/import" operation. It's an engineering project that touches every layer of your voice infrastructure. Here's what's actually involved:
Dial-plan translation. Your Avaya system has extensions, short codes, route patterns, and abbreviated dialing that your users have memorized over years. These need to be translated to E.164 format and mapped to Teams voice routing policies. This is "dial-plan archaeology" — digging through years of configuration changes to build a complete map of your current dialing behavior.
Station mapping and number porting. Every user's extension maps to a DID (direct inward dial) number. These DIDs need to be ported from your Avaya carrier to your SIP trunk provider. Porting requires coordination between your current carrier, your new SIP provider, and your SBC configuration — and it must happen without losing any numbers.
Protocol translation. Avaya uses H.323 or SCCP (Skinny) for signaling between endpoints and the PBX. Teams uses SIP with specific Microsoft extensions. Your SBC handles this translation — H.323/SCCP → SIP, RTP → SRTP (encrypted media). This is core SBC engineering, and it's where generalist IT firms get lost.
Voicemail migration. If you're running Avaya Modular Messaging or Aura Messaging, voicemail needs to be migrated to Teams Voicemail (Exchange Unified Messaging or Microsoft Cloud Voicemail). Greetings, messages, and routing rules need to be mapped. Some messages can be exported; some cannot. Set expectations.
Analog device integration. This is the hard part that blocks most migrations. If you have elevator phones, warehouse paging, fax machines, or door intercoms connected to your Avaya system, they can't connect to Teams directly. They connect through Analog Telephony Adapters (ATAs) wired to your SBC. The SBC bridges the analog signals to Teams Direct Routing. This is our technical moat — and the reason most generalist firms can't complete an Avaya migration.
SBC Selection for Avaya Migration
Your SBC is the bridge between your legacy Avaya infrastructure and Teams. Two vendors dominate the Microsoft-certified SBC market:
AudioCodes Mediant VE (virtual) or Mediant 8000 (appliance). AudioCodes has deep Avaya expertise — their SBCs are common in Avaya environments for gateway functionality. They offer strong analog support (MP-1xx series ATAs), SIP normalization, and Microsoft-certified Direct Routing integration. If you have significant analog infrastructure, AudioCodes is often the better choice.
Ribbon SWe (virtual) or SBC 1000/2000 (appliance). Ribbon (formerly Sonus) has strong SIP normalization capabilities and supports dual-region active-active HA architectures. Their SBCs are Microsoft-certified and widely deployed in Teams Direct Routing environments. If your priority is high availability and SIP normalization, Ribbon is a strong choice.
Both vendors are certified by Microsoft and support all Direct Routing requirements. The choice depends on your specific Avaya configuration, analog infrastructure, and HA requirements.
E911 Compliance During and After Migration
E911 compliance is not optional — it's federal law. Kari's Law and Section 506 of RAY BAUM's Act apply to your Teams Phone deployment.
Avaya's E911 handling: Most Avaya systems handle E911 through station-based location mapping — each extension has a fixed location in a database. When a 911 call is placed, the PBX looks up the location and sends it to the PSAP through a CAMA trunk or PS-ALI.
Teams dynamic E911: Teams uses dynamic E911 with PIDF-LO (Presence Information Data Format Location Object) XML blocks. Location is determined dynamically based on network topology — switch, subnet, building, floor, room. For remote users, location updates in real time based on their network connection.
During migration, you need to:
- Map your Avaya station locations to Teams network sites and subnets
- Configure emergency call routing policies in Teams
- Set up PIDF-LO location routing through your SBC
- Validate 911 call flows with your PSAP before production cutover
- Test remote-user dynamic location updates
E911 is the one thing you cannot get wrong. If someone dials 911 and the PSAP can't find them, the consequences are life-safety. Read our full E911 compliance guide for the technical details.
The Phased Migration Approach
We've done enough migrations to know that "big bang" cutovers are how you end up working at 3 AM with users who can't make calls. The phased approach:
Phase 1: Discovery ($15,000, 2–3 weeks)
Full audit of your Avaya environment: configuration, stations, analog lines, dial plans, E911 setup, voicemail, call routing, integrations. This is where you find the analog line someone added in 2019 that nobody documented.
Phase 2: LLD & Lab ($25,000, 3–4 weeks)
Low-level design: SBC architecture, SIP trunk configuration, dial-plan translation, analog ATA design, E911 routing design. Lab validation: build the configuration in a test environment, make test calls, validate protocol translation and analog integration.
Phase 3: Pilot ($30,000, 2–3 weeks)
Migrate 50–100 users from a single department or site. Test every call path: internal, external, emergency, analog, voicemail. Validate E911 with a real 911 test call (coordinated with your PSAP). Fix issues. This is your dry run.
Phase 4: Production Migration ($20,000, 1–2 weeks)
Full cutover: all users migrated, all numbers ported, Avaya decommissioned. Done in waves — site by site or department by department — with rollback capability at each step. The Avaya system stays powered on but unused until you're confident the migration is stable.
Phase 5: Hypercare ($10,000, 2–4 weeks)
Post-cutover monitoring: call quality, SBC health, analog line status, E911 compliance. Issue resolution. Stabilization. After hypercare, transition to managed SLA support.
Total: $100,000 fixed fee. No surprises.
Common Pitfalls (and How to Avoid Them)
Incomplete dial-plan translation. If you don't fully map your Avaya dial plan — every short code, every route pattern, every abbreviated dialing rule — users will find extensions that don't work. The fix: thorough discovery in Phase 1. Test every dialing pattern in the pilot.
Analog devices forgotten. We've seen migrations where the elevator phone was discovered during cutover — not during discovery. The fix: physical site audit. Walk the building. Find every analog line. Document it. Test it in the pilot.
E911 misconfiguration. If PIDF-LO location routing isn't configured correctly, 911 calls may transmit the wrong location — or no location. The fix: validate with a real 911 test call coordinated with your PSAP before production cutover. Never skip this.
Cutover without pilot. The temptation to skip the pilot and go straight to production is real — especially when the deadline is looming. Don't. The pilot exists to find problems before they affect all users. Every hour spent in pilot saves ten hours of production firefighting.
Ready to Plan Your Migration?
If you're running Avaya Aura 10.1, you have months — not years — before end of support. The migration takes 4–6 months for a large enterprise. The time to start is now.
Get your Avaya migration assessment — we'll audit your current environment, map the migration path, and show you the timeline and ROI before you commit.