Surviving the Skype for Business to Teams Transition, for the Organization

By now you’ve probably seen and heard all kinds of rumors, leaks, plans, guidance, announcements, and roadmaps for Skype for Business and Teams. Well, here’s one more! In this post, I’ll focus on what I think organizations should be doing over the next couple of years.

Yup. Years. One of the first things that you should do, is Keep Calm and Skype (for Business) On. There is no “end of life”, “sunset” or “get off or else” date for SfB.

If you visit the Microsoft product lifecycle pages, you can see that SfB Server 2015 is in mainstream support until October 2020, and extended support until October 2025. We know that Skype for Business Server 2019 is coming later this year, and that’ll take you a few more years out for mainstream and extended support. At Ignite last year, an attendee asked if SfB Server 2019 was the last planned version, and the response was that was “unlikely”.

If you’re looking at SfB Server 2019, be aware that there are a few changes. Alas, the list of changes keeps changing, so until the product is finalized there will continue to be some speculation. You can view the Ignite announcement from last year as a general guide to what to expect, though it has been announced that Standard Edition will be available for SfB Server 2019.

So what kind of things should an organization be thinking about then? Well, in case you’ve missed it, Microsoft recommends that you pilot Teams. I have to agree. I was iffy a year ago, but the product has seen massive feature updates since then, with many more to come. The collaboration experience of working within Teams is entirely different that other application and platform combinations from Microsoft and other parties. I find myself spending more time in Teams. If you’re not currently piloting teams, check out and then start your evaluation.

Teams features compliance, security, extensibility, collaboration and mobility stories that are unmatched by other platforms.

If you’re wondering when Teams will have all of the features that you current get in SfB Online, check out this page.

If you’re looking for guidance on how to pilot Teams, this is the spot along with this page.

And if user adoption is important to you (that’s a rhetorical statement! User experience, training and adoption are key!) follow Karuana Gatimu on twitter. Karuana is the Patterns, Practices & Adoption PM in Microsoft Teams, and is a wealth of knowledge.

Is this the end of Exchange UM?

In a post on the MS Exchange Team blog, the Exchange team lays out alternatives to a service that is being discontinued. The service in question is using a SBC (session border controller) to connect a 3rd Party PBX (Avaya, Cisco, Mitel, anything not SfB) to Exchange UM online. The sunset date for this service is July 2018. The alternatives listed were to move to SfB, use an API, or to use a different voicemail system.

A couple of days ago, an update was provided that indicated that the 3rd option, to use an API, was no longer recommended. After some time, the wording was changed to indicate that it was only recommended as an interim solution. A little bit later, the post vanished. Throughout, there was anger and confusion expressed online over the change in guidance, and the lack of notice provided. Some people have since reported that they’d be informed that the post was an error.

What are we to make of this? First, if the post was in error, I find it challenging to believe that the content was in error, vs the timing of the post.

I say this, because Exchange UM is going away. Let’s look at the facts:

  • SfB is the #1 voice platform that uses Exchange UM. SfB Online has its own voicemail platform now, including auto-attendant functionality.
  • I went looking to see the last time a feature was added to, or updated in, Exchange UM. I went waaaay back, far enough back that I was convinced that the Exchange team would really appreciate it if someone could take UM responsibility off their hands.
  • According to users should have an Exchange Enterprise CAL to utilize Unified Message. For organizations who only needed the license for UM, this was a tough payment to make.

The leaked/early announcement that 3rd Party PBX support via API was no longer recommended is, to me, the nail in the ExUM coffin. If the only recommended solutions from the Exchange team are “move to SfB” and “go find another voicemail platform”, then I can’t see that ExUM is sticking around.

Getting rid of Exchange UM online is a huge task. Microsoft is slowly chipping away at the number of organizations doing 3rd party integrations, to make the eventual service termination have the least impact possible. Providing this kind of guidance before service termination plans are finalized and announced is smart. It allows Microsoft to track their success in reducing the use of the services. If the use of the services is too high, they can adjust the messaging and deprecation tactics to increase the number of organizations pursuing alternatives. Dates for service termination can also be adjusted much more easily on internal roadmaps that haven’t been announced.

I expect that we’ll see more details once the specific features for SfB Server and Exchange Server 2019 are released, though online roadmaps may have a different timeline than their on-prem counterparts.

Microsoft did provide one year of notice before the planned retirement of the “SBC to Exchange UM” solution. While I expect at least a similar amount of notice before the loss of all 3rd party connectivity to Exum, I would also expect to see a block put in place on new organizations using this functionality, while those using it are encouraged to find alternate solutions.

If you are an organization with a 3rd party PBX and you are using Exchange UM online, you should be proactive and consider your possible next steps now. Don’t wait for Microsoft to re-post this announcement, you’ll only have less time to plan.

If you are an organization with a 3rd party PBX and you’re considering using Exchange UM online, you should move quickly to avoid any block that may be put into place. You must also consider this as an interim solution while you migrate to another (like SfB) lest you suffer the indignity of having to migrate off of a solution that you’ve just rolled out.

In either case, there’s no need to panic, but you do need to make sure you’ve got this on your roadmap. You can keep an eye on here for updates on this, as well as the pending 2019 release of SfB and Exchange.