Recipe: Migrating from Novell Groupwise to Microsoft Office 365 Part 1 – Why Change Anything?

This is the first blog post of a category we call a "recipe" – the analysis, planning and effort that went into an implementation of a cloud-based application. Recipes are big, this one breaks down into three parts, a separate post each for the analysis phase, the planning phase and the execution of the project.

This project did not start out as a cloud-based application project – it started out as an email migration project. The customer in question had an email system in place operating on Novell GroupWise. But the users all wanted Outlook as their mail client. But was Outlook what they actually wanted, or was there more to the demands?

In general users ask for functionality instead of specific products – they typically only name a product because they believe it possesses the functionality they need. In order to make a solid business case we needed more than just the fact that users like the Outlook UI better than GroupWise client UI. Migrating 5,000 users to a new mail system is not an easy nor cheap endeavour. Trying to justify this in the middle of a financial crisis with only "it looks better" as an argument would certainly have resulted in a NO from the board. We needed to get a clear answer on the why from a business perspective, an answer to what was wrong with GroupWise.

When we started a like-for-like comparison between GroupWise and Outlook we came to the conclusion that there’s not a lot of difference between the two. They both send mail, allow for appointments to be made, keep a task list and so forth. The differences between the two are small on a functional level, although the UIs are very different. The functionality one expects from any mail program is adequately covered by both. But what really mattered to the users was Outlook’s ability to integrate with the other tools they use on a daily basis including Microsoft Office and the ERP systems. When it comes to increasing productivity and efficiency through integration with other software, the Outlook and Exchange combination wins easily over GroupWise.

There was some discussion about using Outlook as a client against GroupWise servers – but ultimately it was discarded. There were too many reported problems with integration, broken features and lack of support moving to Outlook 2010 to make this option viable. And then an even larger conversation started – if the project migrates over to Microsoft Exchange, should the Exchange servers be on-premise, hosted or in the Cloud?

Clarifying the meaning and differences between on-premise, hosted and Cloud:

  • On-Premise Exchange means that the Exchange servers live in the company data center. The company is responsible for everything – hardware, software, maintenance, backup, reliability, disaster recovery and so on. Likely consultants will help with the initial configuration, but in the long term the responsibility rests solely on the IT resources of the company itself.
  • Hosted Exchange involves a third party company in the ownership and/or operation of the Exchange servers. While there is the option of co-location of the company’s servers and a hosted location, Hosted Exchange in our minds means a scenario where the company does not own the servers or even the software. The hosting provider owns everything, maintains everything and is ultimately responsible for the quality of service to the company. The company typically pays a fee roughly in relationship to the number of mailboxes involved.
  • Cloud Exchange is a relatively new product from Microsoft. The original version was called Business Productivity Online Suite (BPOS). The subsequent version is called Office 365. Office 365 is SAS70 and ISO27001 compliant. For both BPOS and Office 365, the offering is more than just Exchange. But regardless, the Exchange part of the equation is handled entirely by Microsoft, operating all the servers, responsible for all services and charging the company a per-seat fee.

It’s also important to realize that these three options are not an either-or choice. Depending on the products involved, it is entirely possible to end up with a mixture of on-premise, hosted and cloud elements to any application – effectively a "Hybrid Cloud" solution. In fact, the more we work with real world Cloud implementations, the more it is apparent that virtually all sophisticated software application efforts in the Cloud end up as Hybrid Cloud implementations.

In the analysis of this particular project, the company is a multinational organization that had a number of significant jurisdictional compliances issues regarding email. For certain countries, email orginated in the country had to be stored in the country. This would appear to make email in the Cloud impossible, but the Hybrid Cloud approached solved the problem.

With Office 365, it is possible to mix storing email in the Cloud as well as on your own Exchange 2010 servers. Those mailboxes that had to be stored in-country were positioned on Exchange 2010 servers in that country, the rest were stored in the Cloud – hence the Hybrid Cloud solution.

One point of discussion was exactly where those Exchange 2010 servers should live. The option as to put them into the company offices or a third-party hosting provider. Using a third-party provider was preferred because it reduced cost of ownership, increased reliability and security. Ideally the server itself should be owned by the third-party to minimize the expense to the organization, but third-party providers at this point were not ready to support Office 365 in that configuration yet, so the servers in this case would be co-located servers, owned by the organization and positioned in a third-party data center.

Another key advantage we discovered using Office 365 was creating common journalling rules and data retention policies. Office 365 provided one point of access into the entire mail system so that there is a single archiving and legal hold system in place – a substantial improvement over the other mail solutions that made dealing with legal issues very challenging.

The analysis completed, we knew where we want to get to – now the question was, how to get there? The next blog post deals with the planning involved in this mail migration to the Cloud.

Advertisements
  1. You should be a part of a contest for one of the best sites
    online. I most certainly will highly recommend this web site!

  2. Very good article! We are linking to this particularly great content on our site.

    Keep up the great writing.

  3. Wow that was unusual. I just wrote an incredibly long comment
    but after I clicked submit my comment didn’t show up. Grrrr… well I’m not writing all that
    over again. Regardless, just wanted to say great blog!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: