There are many good blogs out there that detail how to port numbers to Cloud PBX, Microsoft pretty much have it organised in this article https://support.office.com/en-gb/article/Transfer-phone-numbers-to-Skype-for-Business-Online-47b3af8e-4171-4dec-8333-c956f108664e. However, if porting numbers is a new thing to you, there are some things you need to know when transferring your customer numbers to Cloud PBX.
1. Be careful with your port requests
The portal allows you to port “user numbers” i.e. DDIs and Mobile numbers but does not allow you to port toll-free or service numbers. For this you must open a service request via the support link in the Office 365 portal.
How is this a problem? It may not be for you, but one thing is to consider the Billing Telephone Number (BTN) for the user and toll free numbers.
By law in the U.S and probably everywhere is that you can only have ONE port request in progress using the same BTN. Therefore, if your DDIs and toll free numbers are under the same BTN then as of today you must raise a support ticket for the porting of all the numbers you want (partial or full) under the BTN rather than using the portal. If you use the portal for your user numbers and then raise a support ticket for your toll free using the same BTN, you will need to cancel or wait for the port to complete in the portal port request in order for the Office 365 technicians to proceed with the toll free port request.
2. Letter of Authorisation
For a port request to be conducted via a support request, you must have the Letter of Authorisation (LOA) signed and completed before the technician will help you. To avoid delays and confusion the letters for the U.S and UK can be downloaded here: https://support.office.com/en-gb/article/Download-a-Letter-of-Authorization-LOA-c0ab5bc9-44f1-46dd-b401-828e4f10b7ac?ui=en-US&rs=en-GB&ad=GB
If you are porting both toll free and user numbers then you will be asked for two LOA’s. This is weird since it is one port request, but to save time and headaches, complete two LOAs. One LOA should contain BOTH your user numbers and the toll free ones you want to port. The second LOA should contain just the toll free numbers you want to port. Why? no idea, but this is required.
3. The Telephone Bill
The support technician will request your latest Telephone Bill associated with your BTN. I assume this is for some kind of authorisation / proof of ownership but it is not mandatory right now. To ease your request and to ensure it doesn’t get slowed down in process or protocol, make sure you have it ready in any case.
4. Choosing a realistic port date
Although you can choose when you want the port request to happen, all times are in EST and do not set expectations that the port can happen any sooner than 7 working days after you submit the request to port. This is largely down to your legacy carrier and expect and plan dates at least 14 days ahead.
5. No Pre-assigning of numbers – there will be downtime
Once you have submitted your port request, your porting numbers will not show in your admin portal. Therefore, you cannot pre-assign them to users in hope that once the request has been completed, calls will seamlessly flick over from the legacy carrier to Cloud PBX. The numbers will appear once porting has completed and they will be unassigned. So you will need to go in and assign the numbers to the services and users you want after porting is completed. So factor in an hour or two of downtime for this to happen.
6. It is not the same as what you are used to
Some customers have toll free numbers assigned to extensions. These extensions belong to a user e.g. receptionist for first point of contact. Cloud PBX doesn’t work like this and in order to use toll free numbers, these are classified as service numbers. Therefore, must be assigned to Organizational Auto Attendants, Call Queues or PSTN Conferencing. You cannot directly assign a toll free number to a user. As largely Org AA and Call Queues are not released (as of the date of this post) pretty much means that unless your toll free numbers are assigned to a conferencing service in the legacy world, there is no point porting these right now.
7. Make sure you keep your authorised person up to date
The authorised person assigned to your legacy carrier contract should be kept up to date. How many people come and go in this position and fail to update the carrier of the change? If the authorised person on the account has left your company and you have not changed this, then the port request can fail. The authorised person must be available to sign off on the LOA and also be contactable by the local porting team at Microsoft in order to complete the porting request. If they are not available, then this may slow down your request.
8. Be careful when porting the BTN
The BTN is a fundamental part of the porting procedure, it is used to identify the account and all numbers within its control. In many cases whoever set up the account in the first place assign their DDI as the BTN on the account. Although fine, it can cause logistical problems when porting numbers. Perhaps you only want to port a subset of numbers to Cloud PBX and leave a small range with the legacy carrier. Why? Perhaps these are analogue lines, or faxes that cannot be ported into Cloud PBX right now. However, the BTN is assigned to your Finance Director as they set up the account, and they need to be ported into Cloud PBX with the rest of the users.
If we were to port the BTN with a subset of DDIs to Cloud PBX, the account from the legacy carrier’s perspective would become orphaned, as the BTN is no longer under their control. This means that the services you have left behind could stop working.
Therefore, if you are in the situation where you need to port the BTN to Cloud PBX, you have three choices you can make:
- Leave the BTN behind and assign your FD a new number from Microsoft for now, forwarding the old BTN to the new DDI so they continue to receive calls
- Contact your legacy carrier to enquire if the BTN can be changed to a number you are leaving behind
- Port all numbers to Cloud PBX and seek alternative / complimentary solutions for the services which Cloud PBX cannot support at the time
Hopefully this should prepare you for your port request to Cloud PBX. Good luck, I am sure it will go smoothly!