Moving Off AudioCodes Mediant: A Migration Guide for Service Providers

What Triggers an AudioCodes Mediant Migration in 2026

The migration trigger is usually one of four specific events, not a general dissatisfaction with the platform. Knowing which one applies to a given environment shapes how the project gets scoped.

Hardware end-of-life is the most predictable trigger. AudioCodes has published end-of-sale and end-of-support notices for older Mediant chassis, including some 4000-series CPU revisions and earlier 1000-series boards. When the appliance reaches end-of-support, the choice is a forklift refresh on the same vendor or a clean migration to a software SBC that runs on commodity hardware.

OPEX procurement policy is the second. Service providers and contact-centre operators that have moved every other infrastructure category to subscription billing increasingly run into a CapEx commitment with their SBC. AudioCodes does sell subscription and usage-based pricing, but the negotiation cycle and the lack of published per-session rates make it difficult to model margins before a quote arrives.

Channel conflict matters specifically to MSPs and to call-centre operators that resell Teams calling. AudioCodes is a Microsoft Premier Partner and an Operator Connect provider, which means the same vendor that supplies the SBC also sells Teams calling services to the MSP’s prospective customers. Moving the SBC to an infrastructure vendor that has no Operator Connect program eliminates that conflict at the technology layer.

Transcoding economics is the fourth, and it is the one that tends to surface late. AudioCodes’ transcoding licensing is per-channel and per-codec, and at scale the line item on a renewal quote becomes material. Service providers that need Opus to G.711 conversion for mobile and WebRTC traffic are the ones who feel it most.

If the trigger applies to a single Mediant in a multi-SBC estate, the migration can be scoped to that one element. The PBX, the carriers, the dial plan, and the rest of the Mediant fleet stay where they are.

Phase 0: Inventory What’s on the Mediant Today

Every successful SBC migration starts with an honest audit of the current configuration. Skipping this step is the single most common cause of cutover surprises. The output is not a screenshot of the AudioCodes Web GUI, it is a structured list that maps cleanly onto whatever the replacement SBC needs to be configured with.

Pull the following from the existing Mediant before touching anything else.

Real session counts. Export 90 days of CDRs and find the actual peak concurrent session count, not the licensed maximum. Most Mediant deployments run well below their rated capacity, and the replacement SBC should be sized to real usage. ProSBC scales to 60,000 sessions per server, so the practical sizing question is usually licensing, not hardware.

The IP Group inventory. List every IP Group on the Mediant: carrier trunks, the PBX, any Teams Direct Routing or Operator Connect tenants, any SIP recording or analytics platforms, and any internal test endpoints. For each one, capture the transport (UDP, TCP, TLS), the proxy address, the IP Profile attached, and the SRD it belongs to.

The IP Profile catalogue. Document the codec preferences, transcoding requirements, SRTP and TLS policy, OPTIONS keep-alive intervals, early-media handling, and any per-side quirks for each profile. A real Mediant deployment usually has fewer distinct profiles than IP Groups, and one profile often gets reused across multiple peers.

Manipulation Sets and IP-to-IP Routing tables. Export every Manipulation Set rule and every routing entry. This is the part of the configuration that carries the most business logic: P-Asserted-Identity rewrites for specific carriers, From-header normalization, dial-plan transforms, attestation tagging for STIR/SHAKEN, and so on. Anything that does not survive the migration gets lost on cutover.

Certificates, ACLs, and security policy. Capture every TLS certificate and its expiry date, every IP allowlist or denylist, every classification rule, and any DDoS thresholds. TLS in particular needs careful handling because the certificate chain on the new SBC must satisfy the same upstream and downstream peers without breaking mutual authentication.

STIR/SHAKEN and fraud integrations. If the Mediant is signing or verifying via AudioCodes’ built-in STIR/SHAKEN, document the signing service, the certificate, and the attestation policy. Same for any toll-fraud integration that ties into the SBC. These pieces are the most likely to need a different architectural choice on ProSBC, where signing and fraud are first-class concerns of the routing engine rather than configuration toggles.

Phase 2-4: The Migration Plan

The plan below assumes a single Mediant being replaced by a single ProSBC instance. Multi-element Mediant deployments follow the same pattern element by element. The whole sequence typically runs four to eight weeks from lab to cutover, depending on how many distinct carriers and PBX integrations are in scope.

Phase 2: Lab build

Stand up a ProLab instance on the same network segment as the Mediant. The ProLab license is permanently free, gives three concurrent sessions, and provisions in roughly twenty minutes. Use the lab to replicate one carrier-side IP Group, one PBX-side IP Group, and any associated Manipulation Set rules. The goal of the lab phase is to validate the mapping in the configuration table above against the specific dialect of SIP that the current carrier sends, not to recreate the full production configuration.

If Teams Direct Routing is in scope, test mTLS, SRTP, and the SBC-to-Teams OPTIONS flow against a test tenant. Teams certification matters as a procurement checkbox in some buyer organizations: ProSBC supports Teams Direct Routing and is deployed in production Teams DR environments, but it has not obtained formal Microsoft certification. If a hard certification requirement exists, the published Microsoft list is the source of truth.

Phase 3: Replicate

Once the lab build proves out the mapping, build the full production configuration on the ProSBC instance. Replicate every NAP from the IP Group inventory, port the codec lists from the IP Profiles, and convert the Manipulation Sets into Ruby module logic. This is where the time goes, and it is the phase that benefits most from a clean Phase 0 inventory.

Upload TLS certificates and configure the NAP-level TLS settings. If TLS and SRTP are required end-to-end, validate the cipher suites and SRTP crypto suites against what the carriers and the PBX actually negotiate, not what the Mediant configuration appears to say. Mismatches between configured policy and observed traffic are the second most common cutover surprise.

If STIR/SHAKEN signing is in scope, point the routing script at the same external signing service the Mediant uses, or at a different provider if the migration is the right moment to switch. Configure primary and secondary signing URLs and confirm the P-Identity-Bypass fallback behaviour.

Phase 4: Parallel

Keep the Mediant in production. Route one carrier trunk through ProSBC while every other trunk stays on the Mediant. Two to four weeks of parallel running typically catches the edge cases that lab testing cannot reproduce: an unusual P-Charge-Info header from a specific carrier, peak-hour codec re-negotiation behaviour, an OPTIONS interval that differs from the documented value, or a specific SIP response code that the Mediant handles silently and ProSBC needs an explicit rule for.

Compare call-completion rates, MOS scores, CDR accuracy, and STIR/SHAKEN attestation levels between the two paths during the parallel period. If a Mediant routing rule turns out to be doing work nobody documented, finding it on five percent of traffic is much better than finding it on a hundred.

Cutover

Schedule the cutover during a maintenance window with the Mediant powered on and warm. Move the remaining carrier trunks one at a time, validating each before moving the next. Update DNS records and any upstream-routing references to point to the ProSBC.

Leave the Mediant powered on and reachable for at least thirty days. This is the rollback path. If a customer-impacting issue surfaces after cutover, rerouting traffic back to the Mediant is a network change rather than a recovery project. After the validation window passes, decommission the Mediant chassis or virtual instance and cancel the support line item.

Post-Cutover Validation

The first seventy-two hours after cutover are the highest-yield validation window. Three checks matter most.

CDR reconciliation covers whether call records on the new SBC match the volume and shape of the old one. Compare hour-over-hour call counts, average call duration, and the distribution of disposition codes between the last full week on the Mediant and the first three days on ProSBC. A divergence usually points at a routing rule that did not survive the mapping rather than a network problem.

Fraud-threshold validation matters specifically because toll-fraud detection rules tuned to the Mediant’s behaviour can either over-trigger or miss patterns on the new SBC. If real-time fraud scoring is integrated through TransNexus ClearIP, SecureLogix, or YouMail, watch the first week of decisions carefully and adjust thresholds based on observed false positives.

Monitoring continuity covers whatever telemetry was flowing out of the Mediant: SNMP traps, syslog feeds, RADIUS CDR streams, or a partnership with the Mediant’s element-management product. ProSBC exposes per-NAP and per-call metrics that can route into Datadog, Prometheus, an SIEM, or a managed monitoring service. Confirm the dashboards are reading the new feed before declaring cutover complete.

Common Migration Pitfalls

Across MSP, ISP, and contact-centre migrations, four pitfalls show up more than any others. None of them are technical surprises in isolation, but each one tends to cost a day or two if it is not anticipated.

Undocumented Manipulation Set logic. Mediant deployments accumulate header-rewriting rules over years, often added by people who have since left the team. Treating the existing rules as authoritative without understanding why each one exists is the fastest way to break a specific carrier on cutover. The right move is to review every Manipulation Set rule during Phase 0 and tag the ones whose purpose is not obvious for explicit testing during Phase 4.

Transcoding assumptions. AudioCodes Mediants do hardware-assisted transcoding for a wide codec set including Opus, G.729, and AMR. ProSBC’s software transcoding currently covers G.711 ALAW and ULAW; broader codec transcoding is on the roadmap but requires careful confirmation before a migration that depends on it. Mobile and WebRTC traffic that currently relies on Mediant transcoding needs a confirmed plan, not an assumption.

TLS certificate chain handovers. Mediants and their upstream peers sometimes negotiate certificate chains that include intermediates the Mediant serves automatically. When the same certificate is moved to ProSBC, the chain configuration has to be explicit. Test mTLS for Teams Direct Routing and any TLS-secured carrier trunk in the lab before relying on it in production.

Hyperplatform compatibility for Azure HA. ProSBC runs on VMware, KVM, Proxmox, AWS, Azure, and bare metal. Native 1+1 HA on Azure requires additional configuration compared to the out-of-the-box behaviour on VMware or KVM. If the existing Mediant runs on Azure with HA, surface that requirement during Phase 2 rather than discovering it during Phase 4.

Frequently Asked Questions