My first exposure to cloud-hosted Exchange came when I was invited to join Microsoft’s “Exchange Labs” dogfood program that Microsoft. (Editor’s note: “dogfood” refers to the Microsoft Exchange development group’s servers running the latest internal build of the software; “eating your own dogfood” means that you run your software to find bugs. Sometimes the theory worked, sometimes it didn’t.)
At the time, there were a few efforts inside Microsoft to develop what was then known as “hosted Exchange,” mostly for telcos and other large service providers. But Exchange was far in the vanguard of this effort—everyone else, including Office Communications Server and SharePoint, were firmly grounded in the on-premises world.
A big part of my job at the time was working with, and teaching about, the integration between Exchange and OCS (later Lync) for voice. Let’s call this the “better together” phase of my work with the BackOffice suite. It revolved around features such as Exchange Unified Messaging, which I used to call “the champagne of server roles.”
Microsoft had come up with the UM feature set as a way to sell Exchange by offering lower TCO and better features than traditional on-premises (or PBX) voicemail systems, and it was pretty successful—so they then wanted to use Exchange UM as a way to sell OCS and Lync to replace the phone systems themselves.
This was a big stretch at the time, because enterprise phone systems typically had legendary reliability and uptime, and on-premises Microsoft products couldn’t necessarily match that in lots of environments. A big part of my work was helping customers plan and design more reliable Exchange implementations that were good enough to match their SLAs for voice services.
Voice and BPOS
As Microsoft made the journey from Exchange Labs to BPOS to Office 365, the playing field for voice and IM integration started shifting. Customers who moved their mailboxes to the cloud but wanted to keep unified messaging or Lync/Skype for Business integration had to keep Exchange UM servers on-premises, for one thing, which made it hard to move completely to the cloud, but when Microsoft created Cloud Voicemail to work with Exchange Online, the writing was on the wall.
As the overall Office 365 service got more reliable, my work shifted away from “better together” and more towards “get me to the cloud.” Microsoft’s own success at getting Lync, and then Skype for Business, to replace enterprise phone systems held them back though, because a customer who deployed SfB in, say, 2016 wasn’t eager to rip it out and move to Skype for Business Online in 2017…. And then came Teams!
The Advent of Teams
Teams changed my focus to something like the process required to open a box of flat-pack furniture: first, you cut the obvious tape and straps and so forth, then you start removing each piece and its individual packing material, lay it all out, and try to figure out the right layout to get the parts close to where you want them so you can start assembling.
Like many other people swept up in the transition to the cloud, my focus has steadily moved to larger and more abstract requirements. I used to tell people how many disks they needed in each server to get the right Database Availability Group performance; then I moved on to advising people how to move to the cloud; and now I help them understand the larger issues around capability, cost, and compliance that come from moving to the cloud.
Source Practical 365