Migrating from Exchange to Google Apps

Over the last couple of weeks I have been working on migrating Aspeq’s email system from Microsoft Exchange over to Google’s hosted emailing offering. A number of colleagues at other organizations I know have also been considering going this way, particularly in light of recent announcements by larger higher profile organizations such as New Zealand post around the use of Google Apps. As a result I thought it might be helpful to share some experiences on how it went for those thinking of switching.

Firstly, its important not to get caught up in all the hype around the so called “Cloud”, and recognize that the Google Offering isn’t as comprehensive as many common stand-alone email servers such as Microsoft Exchange. There are a number of features which don’t work quite as expected, are still in Beta (pre-release) form or simply haven’t been implemented as yet in Google Apps at all.

What switching to Google Apps does achieve however, is to effectively outsource the need to maintain and provide the infrastructure for email within your own organization. When also considering that Microsoft Outlook is no longer required on every desktop, and a very basic word processor and Intranet tools are also provided with Google Apps – it can be quite easy to build up a positive business case showing overall savings for your organization.

Another big plus is the generous amount of storage space provided for each user (currently 25 GB) to store their email, compared with what most organizations are able to offer their users on an internally offered Exchange email server. Usually this generates the need for large amounts of backup capacity, which quickly becomes very expensive and complicated to manage with many users with large email in-boxes. You also have to ask how limiting in-box size to a few GB per user works with legislation that requires historical business information (which email can be considered) to be kept for 3-5 years – Google’s generous storage for the most part quietly solves this compliance issue.

So lets say you make the decision to go ahead and migrate – how difficult actually is this process? The first challenge you are likely to have is actually signing up for the service. It seems like you must have a Google account set up with an email different from the domain you plan to migrate in order to create your Google mail domain. This avoids the chicken and egg scenario – but is confusing to say the least.

Once you have accounts set up, Google apps have a number of migration tools allowing you to move email from your existing email server using IMAP protocol. This works ok, but typically won’t migrate 100% of email for 100% of your users successfully, with simple things like exchange in-box rules, large files or folders named with atypical characters such as “/” derailing the process.

Once your initial migration is kicked off, you can then configure individual Google Accounts to stay “up to date” by retrieving any emails arriving to exchange after your IMAP migration completes. This does require logging into each newly created account in google to set up – kind of a pain if you have a large number of users though. In our even with POP and IMAP running some email couldn’t be brought across and we had to do this manually from each PC using that user’s Outlook account. POP and IMAP also won’t migrate email stored locally on each computer in an outlook PST file – this too must be manually migrated on each user’s desktop.

Once you have mail migrated across you can make changes to DNS, per the instructions on google mail to ensure all new mail now gets delivered to google instead of your old server. This does require a bit of mucking around, which can be problematic if your registrar doesn’t give you full control of things like MX records. This proved to be a problem for us for our New Zealand domains hosted at domainz.co.nz who provided very limited DNS control only and no support after hours or the weekend – so we ended up migrating our domains to a different registrar to resolve these issues, which unfortunately can’t easily be tested in advance as with IMAP and POP.

Feature wise there are a few things missing from Google, and the online help whilst being voluminous is often difficult to navigate. This is a  particular problem where there are differences between GMail and Google Apps and the help doesn’t seem to clearly differentiate between the two. Also, often help refers to a feature which doesn’t appear to be there – usually this is a result of omitting instructions to turn on “Labs” or enable features from the manage this domain console. Google often takes up to 30 minutes to enable a feature once it is turned on, so it can sometimes be hard to know if you have been successful in configuring something.

There are quite a few helper applications available for Google to help solving some of the other problems that corporates are likely to encounter although not always easy to find. It does seem as though Google is not very coordinated in its approach, with many different employees posting help and solutions independently? Two of these are the Mobile Apps and Google Apps Directory Sync which should help mobile devices receive “push mail”/ synchronize calendars etc and synchronize user passwords between corporate domain and google apps. Both of these tools require a bit of experimentation to make work – and we found the built in Active Sync utility on windows mobile actually worked better in the case of the former.

Issues which are of particular concern for most heavy corporate email users we have found to date include:

• Lack of support for email sub-folders within the Google web interface. If you have a large number of nested sub-folders in your exchange account these are effectively flattened into a single level making sub folders near un-usable in Google Mail. You can get around this by continuing to use Outlook on local client computers to access Google via the Google App Sync tool for windows where folders are rendered correctly.
• The global address list listing all your colleague’s email addresses and details isn’t available out of the box. There is a workaround involving downloading the list, sharing it on your network and hacking every client machine’s registry to bring it into outlook – but it is not kept up to date automatically and quite a hassle to get working.
• Giving other user’s access to your email, contacts and calendar is still problematic. This can be enabled within the user’s settings, but in our experience it only worked properly with email with calendars and contacts not being available or shared as expected.
• Although Google mail allows the use of multiple domains (in our case aviation.co.nz, aviationassessment.co.uk, aspeq.com, aslexam.com etc) and set up aliases such as sean.davidson or seand or just sean to receive emails across all those domains – it is an all or nothing proposition. You can’t have email for info@aviation.co.nz and info@aspeq.com go to two different accounts, although we worked around this with a rule to forward email.

Over time we expect a lot of these problems to be fixed, and in our case we think the benefit of being able to decomission exchange, free up a lot of server and backup storage space and infrastructure – as well as not having to maintain Exchange make the change more than worth it. Google Apps also has good spam detection, so we are able to save on the complexity and costs of an additional 3rd party spam filter for Exchange.

At $50 USD per user, that Google also works out cheaper than just buying the licenses for Microsoft Exchange and outlook, and upgrading every three years – not to mention freeing up our Information Services team to do other more strategic stuff.

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment