2,500 Devices Migrated Off Jabber Without Touching the PBX

My first instinct was to treat it like a full re-platform. Rip out Jabber, and while you are at it, question whether you even need CUCM anymore.

I priced that out. The CFO was never going to sign off on replacing a call manager that worked fine, on the strength of a vendor's end-of-life notice for a completely different piece of software.

So I scoped it down. I told my team: find something that just replaces the client. Leave the PBX alone.

The breaking point was not one dramatic event. It was a slow leak. Every iOS and Android release, Jabber got a little shakier. Push notifications started dropping on battery-optimized devices.

And underneath that was a second problem I had been sitting on for years. Jabber was a closed box:

• My service desk wanted a screen pop, so a known number calling in would pop the ticket history automatically.
• We wanted call logs to land in our ITSM tool instead of living nowhere.
• Every time we asked Cisco, it went into a roadmap queue and came back "maybe in two years."

I could not even get a straight answer, let alone a ship date.

Honestly, it felt like I did not control my own department's tools. I am the IT Director. I am supposed to own this stack. Instead I was waiting on a vendor's product committee to decide whether my service desk got a feature.

Commercially it was worse, because the risk was silent. Nobody budgets for "the softphone client quietly stops getting security updates." It does not show up as a line item until it is an incident.

And if I picked another closed softphone to replace Jabber, I would just be signing up for the same wait, with a different logo on it.

We found Acrobits Cloud Softphone. What mattered to me first was not a feature list. It was Class 5 compatibility.

That is the part that meant the new app could register against our existing CUCM exactly the way Jabber did: same dial plan, same routing, no PBX-side project. So the vendor-deprecation clock came off the calendar without a re-platform.

Then the deployment itself just worked. Intune pushed the app to corporate iPhones and laptops. Apple DEP enrolled the fleet the moment a phone was activated. Android Zero-Touch handled the Android side. Nobody typed a SIP password, because external provisioning pulled each person's credentials from our own directory the first time they opened the app.

The rollout closed in days, and the help-desk surge I was bracing for, the one that always follows a fleet-wide dialer change, never showed up. That is when I stopped firefighting and started thinking about my actual backlog again.

Unified communications happens in the UI, not in a server room.

I used to think "unified comms" meant some big PBX feature you bought as a module. It does not live there anymore. It lives in the screen the employee is holding: the dial pad, the service desk ticket, the ITSM record, all in the same place, updating each other in real time.

The mechanism that makes that possible is Web Tabs plus the IPC SDK. Once I understood that, I stopped asking vendors to build things for me and started asking what I could build myself.

This is the part that made it an easy renewal conversation with my CFO.

We provisioned the app across roughly 2,500 devices. Not everyone who has it installed is making calls day to day, and active-user billing means we only pay for the ones who do.

The numbers:

• Our active rate landed around 60%, so about 1,500 billable users.
• At $0.12 per active user, that is roughly $180 a month in total cost.
• A per-seat license on a Jabber-equivalent client runs $4 to $8 per user per month, billed against the full provisioned base of 2,500 regardless of who picks up the phone. That is $10,000 to $20,000 a month for the same fleet.

The bigger a rollout gets, the more per-seat licensing punishes you for provisioning devices nobody is actively using. Mass deployments like ours are exactly where that gap gets widest.