As you’re probably aware, Microsoft uses the same code base to deliver both Exchange 2013 on-premises and Exchange Online. New builds are generated from the base and first appear in Exchange Online and later in a quarterly cumulative update. It all seems like a reasonable arrangement that ensures that same the features will be delivered to all customers.

But we also know that this is not the case for major new features like the Office Graph, meaning that a functionality gap will soon open up between the on-premises and cloud versions, if it not already has. In other posts, I have noted that the complexity and cost of delivering something like the Office Graph underpins Microsoft’s logic in keeping these features cloud-only, but more pragmatic reasons might exist.

Take resources for instance. Microsoft can easily afford to take on the delivery of more complex software to cloud consumers because they have the cash, software engineering talent, hardware resources, instrumentation, and datacenters necessary to develop, debug, and refine software. Eventually the software might be in good enough shape to deliver to on-premises customers and if so, it can be slipstreamed into a cumulative update or new version.

In addition, the scale of Office 365 operations allows Microsoft to test and refine new software by selectively deploying it to small user communities running in a highly structured and instrumented environment. Although MAPI over HTTP is already available to on-premises customers, Microsoft is using an incremental roll-out to determine its performance characteristics and sort out final details, like allowing the protocol to access legacy public folders.

Tens of thousands of users connect to Exchange Online with MAPI over HTTP today and more will be connected over the coming months. The switchover will occur gradually to allow Microsoft to tweak code to increase stability and throughput. The results will then be seen in updated code provided to on-premises customers in addition to better documentation, knowledge about network performance, and so on.

The Office 365 change management session at the recent TechEd North America conference described how tenants will be able to nominate themselves to access features earlier than others. This is another way to ease the roll-out of new code in a very structured and observed manner to cloud users that isn’t possible when software is released to on-premises customers.

Another factor is that Microsoft doesn’t have to deal with third-party add-on products inside Office 365. Removing these variables makes it easier to assess and test new code and move it to a point where it will be better able to cope with all of the different ways that Exchange is deployed inside on-premises environments.

Having Microsoft do all the work to refine new software before it is exposed outside Office 365 seems to be a good deal for on-premises customers. After all, no one likes to deploy buggy and immature code. It’s so much better when code works as it should. The days are long gone when it was amusing to have to track down an obscure registry hack that was necessary to make software work properly (or at all).

Of course, Microsoft could release code to their “Technology Adoption Program” (TAP), which allows customers to access new versions very early. This mechanism has worked well in the past and has been the source of valuable information about how Exchange behaves inside very different environments, including its interaction with third-party products. However, the TAP is now running into problems because of the accelerated cadence of software delivery. TAP participants are expected to deploy new builds into their environments to provide feedback to Microsoft about how the software behaves when exposed to different circumstances.

Getting the time and resources necessary to deploy new builds of major products like Exchange is reasonably easy when a new build is provided every few months over a year-long TAP such as the one that ran for Exchange 2007 or Exchange 2010. Getting the same time and resources every few weeks to deal with cumulative updates of Exchange 2013 (which are in effect brand-new versions of Exchange) is a different matter and I think that the lack of feedback from customer testing has not helped Microsoft achieve stability in some of the cumulative updates issued to date.

All in all, it makes a heap of sense to use Office 365 as the testing ground for complex new features like Office Graph before they are unleashed upon on-premises customers. It’s not as if customers are clamouring for Office Graph – and if they really, really want Office Graph in the near future, they can sign up for Office 365.

Follow Tony @12Knocksinna