Moving Off Our Own Premise: A Cloud Phone System Migration
Problem
Regal ran its phone system on an on-premise solution — hardware we owned, maintained, and were responsible for keeping alive, with all the usual risks that come with aging on-prem telephony (hardware failure, limited redundancy, no easy path to add features like mobile/remote calling). For a distribution business where a meaningful share of orders and customer service still happens by phone, the phone system isn’t a nice-to-have utility — it’s closer to a production system. Migrating it to the cloud meant taking on real risk to fix a real risk.
Approach
I scoped this as a 3-month project with a clear target: get fully off the on-premise PBX and onto a cloud-based solution, without a disruptive cutover day. [Fill in: which cloud provider/platform you migrated to, if you want to name it]
Key parts of the approach:
- [Fill in: how you handled number porting — did you stage it by department/location, or cut over all at once?]
- [Fill in: how you handled training/adoption for frontline and office staff who’d never used a cloud phone client before]
- [Fill in: any parallel-run period where old and new systems coexisted before full cutover]
Because this ran independently from the ERP and HQ26 work, I was able to keep it on its own track and timeline rather than bundling it into a larger cutover window — reducing the number of moving parts that had to land at once.
Outcome
Regal moved off on-premise phone hardware entirely within the 3-month window, eliminating the maintenance and single-point-of-failure risk that came with owning the PBX outright, and gaining the flexibility of a cloud-based system (remote/mobile calling, easier scaling, no more hardware refresh cycles for phones specifically).
[Fill in: any concrete outcome — cost comparison old vs. new, uptime since migration, features gained that solved a real complaint, adoption feedback]