Cuts freak people out. No matter how well-planned, if you’re going to migrate service from Thing A to Thing B, there’s going to be an awful moment in the middle where you’re not sure if it worked. And sometimes it didn’t work, and then you have a race against time to fix it, or cut back. And sometimes even cutting back doesn’t go well.
Urgh. I can feel my heart racing just thinking about it.
Being good engineers, we therefore spend a lot of time trying to minimize the risk. For SS7 cuts we have point-code proxy, for trunk migrations we can build them side-by-side and implement overflow routing.
But what about migrating from a traditional PBX to a Hosted PBX?
This is kinda tricky. Calls for your traditional PBX are routed down a PRI / SIP trunk, whereas hosted PBX / UCaaS lines are built directly on your switch. Worse, the lines within a business usually interact in complex ways – hunt groups, extension dialing, etc. How can you migrate a business from one to the other with minimal risk?
We worked on a migration project recently where we faced just this problem, and we were able to use the Metaswitch Device Twinning feature (log-in required) to make this all a little easier.
Device Twinning?
The primary function of device twinning is to support mobility. For a business that is mostly premise-based, using a traditional PBX, you can use Device Twinning to add an external SIP phone or Max UC client to some of the lines, allowing some of the work force to work remotely, or stay connected while traveling.
However, this function also proves to be very useful when preparing for a migration to Hosted PBX. At a high-level, here’s what you can do.
- Move the PBX into a Business Group
- Build Twinned Lines for all extensions
- Build a Hosted PBX mirror of the PBX configuration, including SIP phones on everyone’s desk.
By doing this, all inbound calls will now ring both phones, and users will be able to familiarize themselves with the new Hosted PBX / UCaaS functionality while the PBX is still in service.
This approach isn’t perfect – an intra-PBX call (from one extension to another) will obviously never touch the outside world (unless you add SimRing or something within the PBX) – but it’s much better than flash cutting and hoping everything works.
