This post has been republished via RSS; it originally appeared at: Microsoft Teams Events Blog articles.
Wow, Ignite has been an absolute whirlwind so far! It's the start of day 4, and I have been to a grand total of two sessions so far: the one I presented on GDPR breach investigation and Korneel Bullens' session on phone number porting. Why this one?
Two reasons. First, porting is a semi-magical process that can be incredibly complex on the back end. As with so many other parts of the technology systems we all use, there's a huge amount of hidden functionality that has to work perfectly, and a large and mostly invisible infrastructure that actually implements the feature. (If you're interested in learning more about number portability, this Wikipedia article on porting is not a bad start.)
Second, porting is absolutely key to driving Teams adoption in businesses that already have existing PSTN service. Before Microsoft can credibly claim that it has an all-up PSTN solution, it has to let customers bring their existing phone numbers into Teams. The mechanism for doing this was the focus of Korneel's session.
The first key point in the session: "YMMV," or "your mileage may vary." Porting requires a smooth flow of information and cooperation between you, the company that provides your existing PSTN service, and Microsoft-- and maybe national or local telecommunications regulators and authorities, third party billing companies, and so on. The porting process for two companies doing ports at the same time from the same place can vary wildly, so plan accordingly.
Second is the distinction between port types. Port-out means transferring a number out of one service; port-in is porting a number to a service. To move a single number from a provider to Microsoft, there will be a port-out on the number from the original provider, paired with a port-in to Microsoft. Bad things happen if you have one without the other. When you port numbers into Teams, you can do a full port (where you move all your number in a single request) or a partial port (you can guess what that is).
Korneel identified seven key issues that can threaten your happy porting experience:
- Regulatory bodies govern porting in each country. "For every regulation there is an equal and opposite regulation" was Korneel's wry claim and it got a good laugh, but it's true. In different countries, the level of regulatory influence over carriers vary-- so not every carrier has to play by the rules or can be forced to live up to their commitments.
- Some port processes (.e.g complex ports) are not regulated in some areas, so there's no penalty if the service provider screws up the port.
- Fragmenting number ranges in many markets is restricted, which means you may have to port all your numbers in one block-- this is often inconvenient for your business.
- "Expediting ports is outside the process"-- there is often nothing you can do to force your current provider to meet any particular deadline.
- Complexity of port operations is determined by the service provider, so they set the SLA.
- Some numbers can’t be ported or take longer. No one quite knows why.
- Porting means losing a customer, so some providers don’t want to do it or drag out the process.
He also identified some common mistakes administrators make when porting. The biggest is what Korneel called "bad administration"-- things like failing to provide the correct account number or a proper letter of authorization. You also must ensure that you don't cancel or change your service with the existing provider before the port happens, which a surprising number of admins fail to do.
Luckily, Microsoft has tools to help solve some of these problems. First is the automated port mechanism available through the classic Skype for Business portal. With this tool, you can request ports of up to 999 numbers but only in the US.
If you're not in the US, or need to port more than 999 numbers, you can perform what Microsoft calls a project port. This is where they help you do it-- very similar in concept to the FastTrack services offered for other workloads. To start a project port, you send email to PTNeu@microsoft.com (if you're in the EU) or PTN@microsoft.com (if you're not) and give them the details for what you need: how many numbers you're porting, which carrier you're using, and so on. Then the fun starts!
The porting process itself "usually" (per Korneel) takes 7-14 business days. It may be faster, it may be slower-- it's up to your carrier. Remember, YMMV. Once the port-out has been done, the carrier registers the port-out in a worldwide system that all telecom carriers use for porting-- so as soon as Microsoft sees that the numbers are available, they activate the port-in, which typically takes less than 2 hours. If you're doing an inter-tenant port from O365 to O365, the process only takes 1-3 days.
Korneel closed the session with some tips for avoiding common pitfalls:
- "Acknowledge the risk that the project timeline can slip" was his polite way of saying that, because there are so many elements to the port process that you don't control, you can't depend on the carrier to stick to a schedule-- so leave plenty of slack in your timeline.
- Make sure the letter of authorization you provide to the carrier is correct for the local regulations. Most countries have specific formats and data that must be in the letter.
- Verify that the numbers you're asking for can actually be ported before you get too far along.
- Double-check that the port request is correct
- If you expect to have multiple port requests, involve the project port team ASAP.
- Leverage your relationship with your existing service provider if you can—they can be surprisingly helpful if they want to
I learned quite a bit from this session about the porting process-- it's worth reviewing the entire live stream (it's only 20 minutes) if you want to know more. Recording can be found here: https://myignite.techcommunity.microsoft.com/sessions/65545#ignite-html-anchor
Now back to the Expo floor for more booth duty!