Office 365 Upgrade and What We Can All Learn

Over recent months Microsoft has been rolling out the significant upgrade to Office 365 that includes the 2013 wave of products. Office 365 is a service on which hundreds of millions of customers rely every day. My own company, Intelliem, is one of them. 

You know how angry your users get when they can’t access email, or some other internal on-premises service is down.  Magnify that by “staggering” and you get a picture of the complex and risky process Microsoft is undertaking. 

How are they doing it?  How quickly are they learning and improving?  And what can we learn about upgrading our own SharePoint environments, and about the future of updates and upgrades?

What Upgrade Looks Like

For those of you who’ve not directly experienced the Office 365 upgrade, let me share my experience as one of my tenancies was upgraded to the 2013 version of Office 365.

In May, I received an email communication from Microsoft shown in Figure 1:

Figure 1 Office 365 Upgrade is Coming

In it, Microsoft basically said, “an upgrade is coming.”

A few weeks later, another communication arrived, this time specifying the date on which the upgrade would occur (see Figure 2).

Figure 2: Office 365 Upgrade is Scheduled

Sure enough, late on June 2^nd, a third message arrived (see Figure 3).

Figure 3: Office 365 Upgrade Complete

The upgrade was complete.

I opened up the tenancy, and saw the following in Figure 4:

Figure 4:Team Site

For those of you who haven’t experienced the previous version of Office 365, I’ll tell you: the site looked exactly the same, just with a notification at the top that the site collection was available to upgrade.  A site collection administrator has the ability to complete the upgrade to 2013 mode, which will then enable the new look-and-feel and features. 

But it’s not forced upon anyone.  It’s self service.

What Microsoft Has Learned and Applied

My immediate reaction: Wow.  That was the smoothest and lowest impact upgrade I’ve ever encountered. Ever. 

From a technical standpoint, this “low impact upgrade” is made possible by the deferred site collection upgrade I described last week.

And the reason that feature was developed was exactly because Microsoft needed to upgrade a service that hosts hundreds of millions of real people every day, without impacting them or requiring significant training.  Now we, on premises, can benefit from something Microsoft had to develop out of necessity.

Microsoft is also showing signs of learning, and continuous improvement, about how to execute the upgrade [there were some very rough times in the winter and spring] and how to communicate to its customers about upgrade. 

In the early months of this upgrade cycle, Microsoft wasn’t telling customers the exact date that the upgrade would happen—at least those were the screams of pain I was hearing.

My experience, now, was very specific and clear.

Microsoft’s messaging about what needed to be done to prepare for the upgrade was also much clearer than in the past. There are solutions centers and resources for the IT pro or service owner to prepare the local environment for the service upgrade.

Microsoft is also learning what we, as customers, need to support the upgrade for our user base.  Notice that in the email messages, there are links to tools with which a service owner can communicate about the upgrade to end users.

What We Can Learn and Apply

Shouldn’t all of our internal service upgrades be this smooth?

-        New version is released

-        Within a few months, it is deployed and the new features and capabilities are available to the IT organization and to end users

-        Little to no “forced” impact on end users, thereby reducing or eliminating the need to train users before upgrading

-        Self-service capability to allow end users to upgrade when they are ready and trained

In order to get to this point with our internal services, we need to get more agile, we need to understand and document our existing environments more thoroughly, we need to have an infrastructure that is flexible (virtual machines--VMs--help a lot here), and we need to have technology that, like SharePoint, supports it.  Many of these elements are within our control as IT organizations.

We should also take a look at the resources Microsoft provides for end user communication and leverage those for supporting other types of service upgrades.

And there’s one more big takeaway, which is how we deal with updates (patches, service packs, and feature packs, rather than version upgrades). That conversation we’ll have in a future article.

Until then, I have to give Microsoft big kudos for how it’s managing upgrades, and how much better the process has become even over the last few months, after a rough start.

The learning and improvement they’re exhibiting, now, is a sign of a maturing, agile service.  Well done.