Last weekend I posted an article posing a question we’d been getting asked a lot on MSUC.Chat:

With O365, and the focus MS are putting on it, will SfB on-prem continue & what happens to my job if it doesn’t?” I thought that it would be interesting to post my thoughts but also to gather views from a number of people from around the industry. Today I’m pleased to be posting the first set of answers back from the internet.

Adam Jacobs

Blog | Twitter | MVP Page | LinkedIn

Adam is a Principal Microsoft Architect working for Polycom in the USA so spends a lot of his time living in the Skype partner ecosystem.

  • Is SfB on-prem going to be left out in the cold because Microsoft wants everyone to have an O365 subscription?

Ultimately I’d imagine that’s their trajectory although I don’t see this happening for at least 3-4 years. Over time I suspect more Hybrid capabilities will be available enticing on-premises customers to at least get some services from the cloud.

  • My job is based on installing/upgrading/managing SfB on-prem if we go cloud what do I do next? / is my job at risk?

Well I’m working for a vendor, so it’s business as usual for me. Around 3 years ago we started looking into what it would take to support endpoint registration for Skype for Business Online, we quickly learnt that there is a load of new authentication mechanisms (Org ID and OAuth 2.0), a few years on and for the most part that transition is complete. But there’s still more work and enough to keep me busy 🙂

Randy Chapman

Blog | Twitter | LinkedIn

Randy is an architect as a SfB Architect at MeetingZone and prolific community contributor!

  • Is SfB on-prem going to be left out in the cold because Microsoft wants everyone to have an O365 subscription?

The short answer is no.  I believe there are enough companies out there that have special requirements that can’t be fulfilled by Cloud PBX alone.  There are also some companies that want to look after it in-house or need to deploy it on-prem because they have security concerns, or probably a bunch of other reasons I’m sure you’ve heard before.
Microsoft listed a vNext for SfB server on the futures deck and gave a target of CY 2018 for launch.  That could change, of course.  But I believe they have to keep developing the product.  They will really limit their customer base if they don’t.
Exchange Online has been around since 2007 (10 years).  Starting with BPOS, if you remember that.  Exchange online at the time was up and down like a yoyo and it was limited, compared to Exchange Server.  But it had to start somewhere.  10 years later and there are a lot of companies going to Exchange Online.  There are a lot with hybrid too.  But I suspect there are more on-prem.
Cloud Connector Edition is based on SfB Server.  They could leave CCE on the current SfB code base or plan in a build and side-by-side migration to vNext.
3rd parties and their applications.  There are dozens of qualified 3rd party applications that are designed to integrate with SfB server.  Some will want to get their hands on the new trusted application APIs so they’ll work with Cloud PBX too.  Some won’t.  There are also a lot of apps that work, but aren’t qualified.  Same for devices.  It’s a big ask of Microsoft to get companies to develop against two SDK’s and APID to support both server and online.  But that’s essentially what they must do.  They can’t ignore existing customers that are on-prem and if they want to stay relevant, they need to think about online.

  • What does this look like over 5 years?

On one hand, there are features.  Cloud PBX is basically SfB Hosting Pack Version 3.  A special media installation of SfB server with some additional “tenant” cmdlets.  Hosting Pack V2 was based on Lync 2013 and it was fine, but had a number of limitations.  I have a list of what they were somewhere, there were more than 30.  A lot of them had workarounds, but some were limitations of scale.  Microsoft is removing any limitations in the product by building new companion applications.  RGS, for instance, vs Call Queue and Org Auto Attendant.  Exchange Online UM was also a limitation and Microsoft delivered basic voicemail.  So Microsoft probably has a queue of features that they are trying to re-architect with a new application.  I’d imagine these are weighted for priority based on who and how many are asking for it.
On the other hand, there is PSTN Calling reach.  The cadence for this has been painfully slow.  3-4 countries per year?  At that pace, it will take years to have coverage everywhere.  And I know there are options for those that aren’t in the club yet (CCE, Server etc).  I think it will take longer than 5 years to catch up.
Again with 3rd party apps.  It’s going to take a while for the delivery, testing and qualification of these.  I suspect there will be a few ready in the next 2 years.  But just what they will look like is still unclear.  If they have to sit in Azure, that’s added expense because Azure is a metered service.  It will suit some, especially those that put servers in Azure already, but not all.
On, yet another hand, there are still people that will want/need on-prem for whatever reason, even in 5 years.

  • My job is based on installing/upgrading/managing SfB on-prem if we go cloud what do I do next? / is my job at risk?

“My” job isn’t based on any of those things, at least not anymore.  I architect solutions for customers.  There is no one size or type fits all solution.  I have to have my eyes on pure server, pure cloud and hybrid and design solutions that meet the requirements.
If, on the other hand, it was my job.  The same applies.  Just as solutions architects have to design solutions that fit the needs of the customer, a consultant needs to be able to build, install, upgrade and manage these solutions.  
This applies to both.  If anything, it gets more interesting because there is more to learn.
As I said above, Exchange Online has been a thing for 10 years.  What Exchange consultants are probably doing more of is migrations from on-prem to online.  Exchange consultants know server, online, hybrid and migrations.  This should be the same for SfB consultants.
And really, how much consultancy is there in the initial build?  (e.g. topology, DVD, Next, Next finish, repeat).  A few days or maybe a bit more for larger deployments.  The really complex and interesting stuff starts after all of the services have started and you send your first IM.  This is the same for online.  Just because the environment is already there and users are probably already enabled and it should just work doesn’t mean there isn’t a ton of stuff to do.  At the moment, there is less to do because there is less possible.  As more features are added there will be a need to do more set-up.

  • How does that vary by job role – i.e. IT Pro, Consultant, Contractor?

A good SfB consultant or architect needs to have knowledge across a wide range of areas.  Probably one of the widest mix of any other solutions consultant.  PC’s, Servers, AD, DNS, DHCP, PowerShell, Networking (1-7), Security, SfB Server, SfB Online, SQL, Virtualization, Exchange, Load Balancers and reverse proxies, SIP, Regex, Troubleshooting, SBCs and other 3rd party hardware and software and probably a lot more besides.  So just by the fact that they know so much about so many things, they can probably go and do anything.  All they need is a company that does more than just SfB.
One thing is for sure.  If all a consultant knows is on-prem it is only a matter of time before they are left behind.  On the other hand, don’t just learn cloud.  One must know both paths to be successful.

— end —

A big big thanks to Adam & Randy for their views and for letting me collate and publish them here. I think it’s a pretty interesting time to be working in this space and sharing views about where we are all at feels pretty important to me.

I’ve got a few more responses on the way and will post them soon but I’d love to expand the discussion, if anyone fancies contributing feel free to add a comment and I’ll make contact.

Ta, Ben.