Migrating from Sonus SBC to ProSBC: Why Voice Engineers Are Moving Off Legacy Sonus Infrastructure

The Sonus name is still printed on a lot of session border controllers sitting in production racks. The company behind it has not existed as an independent business since 2017. Sonus Networks merged with GENBAND that year and the combined entity was renamed Ribbon Communications, which means the SBC 5100, 5200, 5110, and 5210 platforms that engineers still refer to as “the Sonus boxes” are now legacy hardware on a roadmap that Ribbon, not Sonus, controls.

For voice engineers, the question is rarely about whether the hardware still passes calls. It usually does. The question shows up when the platform reaches end-of-support, when a security audit flags an appliance that no longer receives patches, or when Ribbon proposes a forklift refresh onto its current SBC 5400, 7000, or SWe line. At that decision point, a growing number of teams use the forced change as the moment to evaluate whether staying inside the Ribbon ecosystem is the right call at all.

This page covers what running legacy Sonus infrastructure actually means today, the specific end-of-support timeline for the legacy SBC line, and what a migration from a Sonus SBC to ProSBC involves. If you are weighing ProSBC against Ribbon’s current product line rather than planning a migration off legacy hardware, the ProSBC and Ribbon SBC comparison is the better starting point, and this page assumes you have already read it or will.

How Sonus Became Ribbon, and Why Your SBC Still Says Sonus

The branding confusion is worth clearing up because it shapes the support conversation. Sonus Networks announced its merger with GENBAND in May 2017, in a deal that gave each company’s shareholders roughly half of the combined business and valued the new entity at around 745 million dollars. The merger closed later that year and the company adopted the name Ribbon Communications.

The Sonus product portfolio did not disappear at that point. The SBC 5000-series platforms, the GSX media gateways, and the PSX policy server all carried forward under the Ribbon name, and the engineering teams continued maintaining them for years afterward. That is why an appliance bought in 2015 or 2016 still boots with Sonus branding while every support bulletin, end-of-life notice, and renewal quote now arrives on Ribbon letterhead.

The practical consequence is that “we run Sonus” and “we are a Ribbon customer” describe the same situation. The roadmap decisions, the support lifecycle, and the upgrade pricing for that legacy hardware are all set by Ribbon today.

The Operational Reality of Running Unsupported Sonus Infrastructure

End-of-support is not a soft deadline. When a platform passes it, the vendor stops shipping software updates, stops issuing security fixes, and stops accepting support cases for it. For the legacy Sonus line, those dates have already passed: the SBC 5100 and 5200 went unsupported in February 2020, and the SBC 5110 and 5210 followed in October 2023.

Ribbon itself frames the situation in security terms. Its end-of-support notification for the 5110 and 5210 states plainly that organizations still running those platforms have networks that are vulnerable to cyber attacks, and it names ransomware, compliance exposure, and data-governance risk as the specific concerns. That assessment comes from the vendor that built the hardware, and it is the clearest signal a voice engineer can point to when making the case internally for a migration budget.

The exposure compounds in a few ways. An SBC sits at the network edge and acts as the security boundary for all SIP traffic, so an unpatched SBC is an unpatched firewall for the voice network. Hardware that has been in service for eight or ten years also accumulates physical risk: power supplies, fans, and storage age, and replacement parts for an end-of-support chassis become harder to source. On the compliance side, security frameworks and customer audits increasingly require that edge infrastructure run supported software with a current patch path, and a decommissioned product line cannot satisfy that requirement no matter how stable the box has been.

None of this means a legacy Sonus SBC will fail tomorrow. Many run for years past their support date without an outage. The point is that the risk is no longer being actively managed by anyone, and the cost of that risk lands entirely on the team operating the box.

The Fork in the Road: Forklift to Current Ribbon, or Migrate Off

Once the support clock runs out, Ribbon’s recommended path is a forklift refresh onto its current line, typically the SBC 5400 or 7000 appliance or the SBC SWe software edition. That path keeps the configuration model familiar and preserves the existing operational knowledge, which has real value for a team that has invested years in Sonus tooling.

It also reopens every commercial and architectural question that came with the original purchase. Moving to the SBC SWe puts the deployment on a current software platform, but for many mid-market operators that platform has historically run on VMware, which carries its own cost trajectory after the Broadcom licensing changes. Ribbon’s STIR/SHAKEN signing routes through a separate PSX component rather than living in the SBC. Pricing remains quote-based rather than published. These are not new criticisms, and they are covered in full in the ProSBC and Ribbon SBC comparison, so this page does not repeat them. The relevant point for a migration decision is that a forklift refresh is itself a project with a lab, a parallel run, and a cutover, which means the incremental effort to evaluate a different vendor during that same window is small.

That is the reasoning a lot of voice engineers follow. The hardware refresh is going to happen regardless. If the team is already standing up new infrastructure, running it in parallel, and cutting traffic over, then doing that work toward ProSBC instead of a new Ribbon appliance costs little extra and removes the recurring friction points at the same time. For a broader view of the forces pushing operators from fixed appliances to software, the guide to replacing hardware SBCs with software lays out the general case, and the hardware versus software SBC TCO breakdown puts numbers to it.

What Migrating Off Sonus Involves

A Sonus to ProSBC migration is a configuration translation problem more than a network problem. The two platforms perform the same SBC functions but describe them with different objects, so the first task is building a working mental model of how the Sonus configuration maps onto ProSBC.

The table below covers the objects that appear in nearly every Sonus deployment. None of the mappings are exact, so the third column is the one that matters: it describes how each Sonus concept behaves differently once it is rebuilt on ProSBC.

The phases that follow this mapping are not specific to Sonus. Auditing the current deployment, sizing the replacement to real traffic, standing up a lab, running both SBCs in parallel, migrating trunk groups one at a time, and decommissioning the old platform after validation is the same sequence regardless of which vendor you are leaving. Rather than repeat it here, the guide to replacing hardware SBCs with software walks through that five-step framework in detail, including how to pull ninety days of CDRs to find real peak session counts and how to keep a rollback path open during cutover.

Sonus-Specific Migration Considerations

A few things tend to be specific to Sonus migrations rather than common to every SBC move, and they are worth surfacing during the audit rather than discovering at cutover.

Where the routing logic actually lives is the first question. If the deployment uses an external PSX, much of the routing and policy intelligence sits on the PSX rather than on the SBC itself, and that logic is what has to be reproduced in the ProSBC routing script. A team that audits only the SBC configuration and overlooks the PSX will miss the most important part of the migration. Mapping the PSX policy is usually the single largest work item in a Sonus migration.

The ERE-only case is simpler. Smaller Sonus deployments that never deployed a PSX keep all routing in the embedded engine, and that logic translates fairly directly into the ProSBC routing table and script. Knowing which model the deployment uses, ERE-only or PSX-backed, sets the scope of the project early.

Certificate and software age matters on hardware that has been in service since before the Ribbon rename. TLS certificates on a decade-old box may use ageing key lengths or chains that the upstream peers no longer prefer, and the migration is a natural moment to refresh them rather than port stale material forward.

Configuration export is CLI-driven on the Sonus SBC. The running configuration is most completely captured through the CLI rather than screenshots of the management interface, so plan to export it as text and work from that as the authoritative inventory.

Frequently Asked Questions