Coping with the Exchange Online update cadence

Rajesh Jha, Microsoft Corporate Vice-President for Exchange, recently published a blog that casts some light on how Microsoft plans to release updates to the Exchange Online application within the Office 365 suite. I've meant to comment on this topic because it is obviously important that any Office 365 customer understands when and why change will occur in their environment. Other more important events interfered with my writing schedule, but it's good to have had the time to consider what the development cadence means for customers.

In a nutshell, updates are divided into three groups:

1. On-going bug fixes and updates that improve the service. In an on-premises deployment, you’d probably refer to these as hot fixes and other updates that Microsoft release as a response to problems reported by customers. According to Jha, these fixes are put into production every two weeks and are largely invisible to Exchange Online users.
2. Additive features and capability releases every 90 days. The best comparison we have from the on-premises world is an Exchange roll-up update.
3. Major feature and capability release every twelve to twenty-four months. This type of update might be compared to a service pack or indeed to a new version of Exchange and is broadly in line with the cadence that Microsoft has used to update Exchange since 1996. Jha’s blog gives examples of the revamp of the Outlook Web App (OWA) UI or the introduction of archive mailboxes. In the on-premises world the OWA revamp occurred in Exchange 2010 SP1 while archive mailboxes were introduced in Exchange 2010 and then considerably improved in SP1.

By definition, companies who move from an on-premises deployment to Exchange Online lose some control over when new features are introduced to users. Microsoft allows customers a twelve month window within which they can decide to accept major upgrades but eventually the upgrades must be accepted whether users are ready or not. For most companies this won’t be a problem as twelve months is more than sufficient to prepare users for the introduction of something like a new UI for OWA or to roll-out Outlook 2010 on the desktop so that users can take maximum advantage of archive mailboxes. Companies that are highly distributed, have large user populations, or don’t run desktop management software might find it more problematic to be ready for Exchange Online updates.

In the past, these companies might have been used to a more measured cadence for updates based on a five-year schedule for major server refreshes and a similar pace for desktop changes, perhaps only ever moving to upgrades when Microsoft’s support policy forces the issue. Just look at the number of companies that still run servers with Exchange 2003 on Windows 2003 with Office 2003 and Windows XP on the desktop.

Of course, companies in this situation can decide to remain in charge of their own destiny by continuing to run on-premises servers, but if they make the transition into the cloud then they have to accept that they now operate in a completely different environment where a large amount of control over the functionality and user interface that their users will consume going forward is, by necessity, ceded to the cloud provider. While some will welcome the fact that Microsoft will relieve them of the need to perform updates to Exchange, SharePoint, Lync, and whatever other applications find their way into the Office 365 suite, the loss of control will be quite a cultural change for others. I’m sure that they will get past the cultural upheaval in time!

Whether you decide to stay with on-premises, go into the cloud, or deploy a hybrid infrastructure that spans both on-premises and cloud, the need for planning and preparation for updates and the knock-on effect of new features and interfaces on users, programmers, administrators, and help desk won’t go away in the future. It’s just a little different when the cloud is involved. But then again, isn’t everything?