Simple Isn't Always That Simple When Moving To Google Apps Or Office 365

I spent the past three months talking to Google and Microsoft professional services partners, as well as Google Apps and Office 365 clients, to better understand how cloud collaboration and productivity suites are implemented and the value clients get once they move into these environments. One word that came up quite a bit during these conversations was "simple." As in "We think moving to [Google Apps or Office 365] will simplify our [costs, IT management, user experience, etc.]." This got me thinking: Should CIOs think moving collaboration workloads to the cloud actually simplifies their job? Well...yes, but there's a but. Simplicity in these environments comes with costs. Business and IT leaders must be sure they're willing to pay them as a condition of getting the benefits of the cloud. So what does this mean?

  • These platforms simplify contracting if you can live with the standard service agreement. One Google client told us one of the reasons they rejected the incumbent players was because they felt the licensing agreements were "convoluted." Yes, cloud collaboration and productivity suite providers have straightforward per user pricing for clearly defined feature/function tiers. But the devil's in the details. These players are able to deliver highly efficient, low-cost services because they do not permit a lot of deviation from the standard service agreement. So, healthcare clients looking for business associates' agreements will not find a willing partner in Google.* And smaller enterprises that require a dedicated collaboration environment will find that Microsoft enforces a minimum seat count on Office 365's dedicated SKU.
  • These platforms are simple to implement if you're willing to cleanly break with the past. Many of the successful Google Apps and Office 365 deployments we studied have a common thread: IT leaders decided against migrating years of content to these services. One Office 365 client told us they were successful because, "We kept the migration as simple as possible. We didn't complicate things with complex migrations and use cases." When clients attempt to replicate their on-premises environments in these cloud offerings they often require a lot of custom development work, third-party applications, and integration remediation. This can slow the implementation and create sub-optimal user experiences.
  • These platforms simplify running collaboration infrastructure if you don't require lots of customizations and on-premises integrations. We talk to many IT leaders intrigued with Google Sites or SharePoint Online as a place to offload their on-premises SharePoint implementations. How viable this plan is depends on how they intend to use these tools. Many SharePoint Online clients tell us that they still maintain on-premises SharePoint farms because the cloud environment cannot accommodate their custom integrations, applications, and workflows. This creates a hybrid scenario in which simple workloads, such as team pages, move the cloud and IT departments maintain on-premises servers to run the heavily customized applications.
  • These platforms simplify the employee experience if you're able to convince workers these changes are merited. The vendors position their collaboration tools as, among other things, enabling mobility, enhancing internal dialogues, and facilitating external collaboration. These capabilities often seduce business and IT leaders who jump at the chance to use these tools to improve their organization's operations. This often misses one key factor. As one former Google Apps client whose organization recently moved off the platform, "We saw that the change to Google was too great for our employees." These new collaboration systems require a lot of heavy lifting on the change management front, particularly in businesses that weren't generally displeased with the old collaboration tools.

* Google recently began entering into business associates' agreements with clients handling patient data. See details here.    


TJ, Pretty good article here,

Pretty good article here, but I wanted to point out a few points in here that I think could use some clarification. First, Google does now sign BAAs ( I'm sure you know that, but may not have been able to get this article updated prior to publication.
You also talk about "making a clean break" from our legacy mail system and I would contend that that is best practice, no matter what you are doing, as it greatly reduces complexity, confusion and cost. For example, if you were migrating from Lotus Notes to on premise Exchange, you would not want to leave Notes around in a dual environment as you would have complexities in mail and collaboration. Whenever changing messaging platforms, you always want to make a clean break from the older platform; it's best practice.
Further, I would contend that Google is a highly customizable platform with App Scripts and App Engine.
Lastly, change management is huge, no matter what you are doing in IT to your users. If you do not train and communicate to your users, they will always be frustrated and lost. If I worked for Microsoft, and were selling O365, I would tell people to train heavily because it is a new platform and, although marginally similar, it is still different. Train early, train often.

Thanks for commenting, Derik

Thanks for taking the time to read and respond, Derik. I appreciate the points you made, but would note the following:
* When I refer to making a clean break from the prior email environment, I'm referring to the position of many organizations to forego migrating old messages, content, data, etc. into the Google Apps (or Office 365) as a way to avoid data corruption or any other complication in the move. This is not the same as persisting in a coexistent environment, though in the Notes example you provide, many organizations choose to maintain a Notes server for all of those Notes applications the company has come to depend on. So, the point I'm making that is radical from the perspective of the company is how they step away from that historic data when they move to the new environment.
* While it's true that you can use Google App Script within Apps, we can both agree that the amount of customization those afford is not nearly the same as what companies do in their legacy SharePoint or Lotus Notes environments. Google App Engine provides an interesting adjunct, but as we both know, using App Engine is a separate set of licenses a client must acquire. So, again, this isn't exactly comparable to the middleware that Microsoft provides in SharePoint on-premises.
* On your last point, I'm in total agreement about change management. I've actually written extensively about the importance of this in a cloud migration. What I was noting in this post, though, is that a move to a cloud app (particularly Google) can be very jarring for employees as the look, feel and functionality is wholly different than what came before. So, can present an interesting set of challenges related to change management as employees grapple with the difference.

As a post script, I'll update the post to note that Google now enters into business associates' agreements.

Thanks again for the comments, Derik. I appreciate your engaging in this topic.

*I do agree with your first

*I do agree with your first comment; customers do need to consider how much data they want to move. Often times, when I talk to customers about this, they give you a look like they've never thought about it before. I assume they just thought they would always move everything, but realize they have a chance to make some changes during the transition.
*I agree, App Engine is a different "product" that is charged based on usage, but I would contend that SharePoint Portal Services is a different product than SharePoint Enterprise, which also requires a different database version to run, so they are different products with different costs as well. Bottom line though, as you originally pointed out, what you can do with SharePoint on premise is not the same as you can do with SharePoint online and I do agree that it may not 100% translate to App Engine as well.
*I think one point to consider, in regards to change management, is that Gmail is now the most used email platform in the World, so when I talk to customers, I would say between 40-60% of anyone in the room is already using it. I feel that the role change management plays is; how do I use this in an Enterprise setting? I think if you took an Office/Outlook 2007 or 2010 user and gave them 2013, there would be just as significant learning curve. Also, Outlook client is different than OWA which is different than the mobile client so there is training to be done on 3 different platforms. But we agree, change management is absolutely key no matter what, I just disagree that moving to 2013 is any less significant that moving to Gmail and can make an argument that moving to Gmail is less of a change based on consumer usage (
All of the points you bring up are points that customers do need to consider no matter what they do, which is the point of the article, and leads to conversations such as this one.

The psychology of change management

Good article and comments.

T.J: "I would say between 40-60% of anyone in the room is already using it [Gmail]. I feel that the role change management plays is; how do I use this in an Enterprise setting?"
- Which enterprise functions does Gmail lack? Email is email is email. I believe the dissonance is mostly related to the UI differences instead of capabilities. I will call it the 'user psychology of appearance'.

In my opinion, on-premise owners are trying to avoid the inevitability of the cloud and IT managers are resisting the work involved with "Change".

"We saw that the change to Google was too great for our employees." This statement exemplifies that sometimes users anxiety over "Change" outweighs rational productivity decisions for organizations.

Thanks T.J. for the article. The psychology of change management would be a great area for further research.

Psychology is part of it, but there are real changes

Thank you for taking the time to reply to this post, Akil. I agree that psychology is a big part of change management; my colleague Claire Schooley has written extensively about this in regards to collaboration technology. That said, there is actual change in moving from Lotus Notes, Microsoft Exchange or Novell GroupWise to Gmail (and the rest of the Apps portfolio). And if we overlook these material changes -- if we just tell employees "It's all in your head" or "You're just resisting change" -- we'll miss the opportunity to effect change through these technologies.

I agree that many employees have experience with Gmail in their personal lives. But here's where we overlearn the wrong lesson in consumerization: How I manage my personal affairs isn't how I've trained myself to manage professional matters. So, when you pose the question, "Which enterprise functions does Gmail lack?" I note two common complaints heard from Google Apps users: The negative comparisons of Google's calendar to Outlook and lack of native integrations into on-premises systems of record like Siebel.

Now, there are clearly workarounds to these problems, but these are examples of actual differences (not just interface shock) that IT leaders must address when making the migration.

Thank you again, Akil, for reaching out. I hope to hear from you on future posts.