How do you migrate from on-premises PBX to UCaaS?

A port moves phone numbers. It doesn't move the settings inside the PBX, the routing behind the main number, or the devices plugged into the wall. Whatever callers to a number relied on has to be rebuilt on the new system or deliberately kept on the old one. That is why the inventory has three parts.

The first is the numbers themselves, with the account each one sits on. Microsoft's guide to planning a port, written for its own calling plans, lists what a port order asks for. It needs the account number, the person authorized on the account, the service address, the business name, the billing telephone number and the list of numbers. Most of that is on a recent invoice. In the United States you can also ask your carrier for the customer service record, which is its official record of the account. You can ask for it at any time.

The second is the call flows. Write down what happens when someone calls the main number during the day, after hours and on a holiday. Do the same for each department line and each group of phones that ring together.

The third is every device that uses a phone line and isn't a desk phone. Look for fax machines, alarm panels, elevator phones, paging systems and door intercoms. They matter because not every cloud phone system serves them, and the copper lines some of them run on are being retired. Microsoft says a fax number can be ported to Teams, but faxing won't work there. It also warns that other services tied to a ported number, such as ISDN or broadband, are disconnected once the port completes.

A migration doesn't have to put everything in one place on one day. Atlantech Online's business phone service shows the choices one provider can offer. You can connect to its cloud PBX. Or you can keep your own PBX and have service delivered to it by SIP, PRI or analog. For the analog devices, its POTS replacement service puts a managed appliance in the telecom closet. The appliance gives fire panels, elevator phones, alarms and fax lines an analog line over broadband and 4G LTE. Each unit supports two to eight lines and has up to 24 hours of battery backup.

Suppose a 60-person accounting firm has a PBX in a closet and 70 phone numbers. Sixty are direct lines, six are the main and department numbers, two are fax lines, one serves the fire alarm panel and one serves the elevator phone. The 60 staff and the six shared numbers move to the cloud phone system. The two fax lines, the fire panel line and the elevator line move to an analog appliance, four lines on one unit. That assumes each device works on the appliance and the fire panel's monitoring company tests its line after the move. The PBX is retired.

A different firm might have a second site that isn't ready to change. It could keep that site's PBX for now and feed it with a SIP trunk, then move those users later.

Your published numbers keep ringing on the old PBX until the port happens. That gives you time to build the new system completely while nobody depends on it. Create the users, record the greetings and rebuild each call flow from the inventory. Enter an emergency address for each location. Staff who work from home need a setup of their own, because their 911 address and their network are at home.

Then try it on temporary numbers. Ask the new provider for a few new numbers that aren't part of the port. Put one on the new main-number menu and the others on a small group of pilot users. Calling the temporary main number tests the menu, the queues and the after-hours path the way a caller will meet them. The pilot users make and take real calls at their desks, which shows how the new service behaves on the office network. A weak switch or a dead WiFi spot is easier to fix with five people on the system than with sixty.

A pilot on temporary numbers has a limit. It tests whether the new system routes calls the way you intended. It can't show that the port will go through, because the published numbers haven't moved yet.

The new provider submits the port order to your current carrier on your behalf. The current carrier then approves or rejects it. Microsoft's guide is plain about the date. Choosing a target date doesn't mean the port happens then. It happens on that date only if the current carrier approves it, and the approval is called a firm order commitment.

Microsoft's figures give a sense of the timing for a US port to its calling plans. The current carrier has three to five business days to respond. A port typically takes 7 to 14 days from start to finish and can take up to 30, depending on the carrier. A rejected order has to be corrected and resubmitted, and the response clock starts again. Microsoft names mismatched account details as the most common cause of errors and delays. A freeze on the account also blocks a port, and removing one can take one to three weeks.

Those figures describe Microsoft's process, and another provider runs its own. Atlantech lists number porting in its Operator Connect price. For its business phone service it advertises go-live "in as few as 10-15 business days," on the condition that nothing is delayed on the client's end. A complete inventory removes one cause of delay on your side, since the details on the order have to match the carrier's records.

Schedule the cutover for the confirmed date, and announce it to staff once you have that confirmation. An announced date that the carrier then rejects has to be announced twice.

Two rules about the old service follow from how ports work. Don't cancel or disconnect anything before the port completes, because inactive numbers can't be ported. And decide whether the port is full or partial. A full port moves every number on the account. A partial port leaves some behind, which is how a firm can keep an alarm line with its old carrier. If the billing telephone number is among the numbers leaving, Microsoft says one of the remaining numbers can become the new one.

If you port in stages from one account, the orders run one after another. Microsoft says the current carrier processes one order per account at a time and rejects any that overlap.

On the confirmed date the old carrier releases the numbers, and the new provider starts receiving the calls. From then on a call to one of those numbers arrives at the new provider. In a migration that retires the PBX, like the firm's above, the PBX is no longer in the path.

So test from outside, with a mobile phone, and work through the inventory. Call the main number and follow each menu option. Call each department line and one or two direct lines. Leave a voicemail and confirm it arrives. Call again that evening to hear the after-hours path. Then call out from a desk and check the number the other person sees.

For 911, check the address on file without calling 911. Atlantech documents dialing 933 from a phone on its service. A recorded message reads back the phone number and the E911 address registered for it. That confirms the record. It doesn't test an emergency call itself.

Returning a number to the old carrier is another port with another approval. So the first place to fix a problem after cutover is the new system. A menu that sends callers to the wrong place, or a queue that rings the wrong people, is a change to the new system's settings and needs no port. That is the reason to rebuild and try every call flow before the port.

Once every port is confirmed complete, close out the old service for the numbers and lines you moved. Keep active any line you deliberately left with the old carrier, such as an alarm or elevator line in a partial port. For a full port, Microsoft says the old account might be terminated automatically, and it still recommends working with the old provider to confirm the account is closed. Read the next invoice to see that billing has stopped for the lines you moved.

Before anyone unplugs the PBX, go back to the device list. A paging amplifier or a door intercom wired to the PBX can stop working when the PBX is switched off, whether or not it ever had a number to port. If the list shows nothing still attached, the PBX can go.