Device Management is a massive factor in UCaaS Voice/PBX Cloud Migration. Voice endpoint devices like desk phones are expensive, so it’s often desirable to keep legacy devices. We see three issues repeatedly: Devices must be compatible with losing and winning SPs to retain them. You must get control over Voice devices to maintain them and activate features. And cybersecurity controls can block the migration.
1. Compatibility. One common holdup for cloud migration is devices that work with the losing system but are incompatible with the winning Voice platform. A key reason is End-of-Life (EOL) for software from the device manufacturer. In these cases, heroics to retain elderly devices is usually unwise because it keeps unmaintained software in the network — including all the security vulnerabilities.
For example, a Polycom SPIP500 phone from 2009 isn’t compatible with Zoom Phone or RingCentral. Polycom (now HP) ended support ages ago. You can hardly expect full features from the SP when the manufacturer has mothballed a device.
2. Control for provisioning and management.
Even when devices are compatible with the winning SP, it doesn’t always mean the winning SP can readily control the device. Generally, devices are configured to check in with only one SP — the losing one — and it’s rare for the winning SP to have access to control the configurations. Perhaps just as bad, many devices check-in for settings only when they boot up. This means they can avoid talking to the provisioning device management servers for months if they don’t restart.
Overcoming these obstacles can sometimes be achieved. A factory reset of a device will let the winning system gain control, but that process can take several minutes for each device. And for devices that don’t periodically retrieve their configurations, a manual power cycle is required.
3. Network controls blocking migrations. The final common problem is in the effort to run a safe enterprise network. Network administrators can lock down the network to ensure that Voice devices only communicate with the losing SP. That makes sense to prevent the devices from being exploited to launch attacks or be used for data exhilaration. But it means the winning SP cannot take over until the security policy is updated. Unfortunately, this can be a big project and challenging to plan for in a migration. Firewall rules accumulate over time. Many networks have layers of firewalls, and several may need to be updated.
The critical defense for ensuring this doesn’t block the migration is testing. Move at least one device at each enterprise office location from the losing SP to the winning SP as early as possible in the project to uncover blocking rules that prevent the connectivity between the enterprise network and the winning SP.
Even migrating from VoIP to VoIP can be challenging, but anticipating the obstacles may save the project before it starts.
