Software

One company's Google Apps email migration: Part 1

Learn how one small business took the plunge and retired their in-house email server in favor of Google Apps.

Hello and welcome to my first article for TechRepublic's Google in the Enterprise Blog. My goal is to write about real-world scenarios with a look at how Google's products can work for businesses both large and small. I'll jump right in by discussing a recent experience I had as a consultant working with a small organization on their Google Apps email migration. This is part one of a two-part series which will be wrapped up in my next post.

Background

For several years I've supported the email and file server needs of a company I'll call Terrapin Valley. This organization is a classic small business (approximately five users) run by the owner and his wife, both of whom are technically savvy and clued into current trends. For confidentiality purposes I'll call them Ted and Jill.

We ran an in-house Microsoft Small Business Server 2003 system (TV-SBS was the imaginative name of this host) since 2005 at Terrapin Valley. This Active Directory domain controller provided Exchange email services (including local/remote Outlook and Outlook Web Access connectivity), Windows file shares, and tape backup operations for the company for approximately seven years. The company owns the domain name (i.e. terrapinvalley.org) and the MX record for the domain pointed to the internal server, which could send/receive email through the firewall.

There was also a separate Blackberry server running the express version of the product, which had one user: Jill. Users connected to the Exchange server via Outlook 2003 clients.

The Problems

By early 2012, TV-SBS was creaking and groaning, and so were its users. The Dell server hardware, which had been deemed "good enough" for the past couple of years, was severely outdated. Disk space was low on the server. Spam was a major factor as well; anti-spam functionality was in place via a third-party server product but an unacceptable amount of junk email still made its way through to users.

Jill also wanted to retire her Blackberry in favor of an iPhone. The TV-SBS system could support some basic Activesync mobile functions required for iPhone connectivity but it would be a kludgy arrangement requiring a lot of tinkering with IIS virtual directories.

Lastly, Ted and Jill are frequent travelers; they vacation away from home for a large part of the summer and used Outlook via RPC over HTTP to connect to TV-SBS over the Internet to keep up on their email. This setup involved too much latency and delays to continue to deal with. The system had met their needs for many years, but clearly it was time to send it off to a retirement community.

The Requirements

Ted approached me in January of this year explaining that he'd like to look into cloud-based email to replace the email server at Terrapin Valley (the file server components would be left as is for the time being). Previously Ted had been a strong proponent of internal physical servers and maintained that perspective until researching the cloud and its opportunities. Ted felt it was now unnecessary to run an email server in-house for five people and for us to have to contend with physical maintenance, backups, and OS features that slowly got more and more outdated. We talked over and documented the requirements:

  • Retain email traffic to existing domain name (i.e. terrapinvalley.org) and continue to utilize current email addresses.
  • All email, calendar and contact items kept intact and migrated up to the new email platform (each user had no more than 5Gb of data, but room to grow was also desirable).
  • Full Outlook / browser-based email for Ted, Jill and staff - the same experience whether home or operating remotely.
  • Outlook 2011 connectivity for Jill's Mac to access email, calendar and contacts.
  • Email access for Ted and Jill on iPad and iPhone.

Shared calendars, documents and other collaboration tools were secondary and could be explored later. Pricing wasn't a particular factor or consideration.

Ted expressed the desire to retain Outlook 2003 for at least the time being, since company users were intimately familiar with it and it met their needs. An updated version of Outlook could be obtained and rolled out later in the year. Google offers transition guides to help users move from Outlook to Gmail and I intended to make good use of those as well.

The Research

I started looking into cloud-based email solutions and right away the offerings from Google caught my eye.

Google provides a helpful Adobe PDF titled "Google Apps Migration for Microsoft Exchange" (PDF), that outlines the transition from Exchange to Google email, whereby each user and their email can be copied up to Gmail and provided corresponding accounts which can be accessed via other applications (such as by POP or IMAP).

Another strong contender was Office 365. I mentioned to Ted that I was looking into these two products, and he felt that either one should be sufficient for our needs, expressing the opinion that proven big names like Google and Microsoft were the right fit for his organization. Based on Ted's preferences, I kept the search scope narrow and began comparing Google with Microsoft.

Click the image for a larger version

I found this TechRepublic chart to be invaluable. It basically states either Google Apps or Microsoft 365 will work fine for most small businesses for most categories, but is helpful to determine the features and details involved.

One of my considerations involved confirming that the various types of email data (messages, calendar items and contacts) could be properly shuttled up to Gmail. According to the "Google Apps Migration for Microsoft Exchange", all data in these categories can be migrated with the following exceptions:

Mail items not migrated

  • Public folders
  • Items larger than 25MB
  • Executable files in compressed attachments
  • Posts in mailbox folders
  • Importance levels (high priority for instance) - the actual messages would copy up however
  • Rules
  • Signatures
  • IMAP/POP account settings
  • Shared mailboxes
  • Category definitions
  • Category assignments

Calendar items not migrated

  • Tentative / Out of Office Status
  • Optional Attendees
  • Calendar attachments
  • Rich content in event descriptions (such as images or links)
  • Category definitions
  • Category assignments

Contact items not migrated

  • Personal distribution lists
  • Rich formatting in personal contact notes
  • Notes larger than 16 Kb
  • Follow-up flags, dates and reminders
  • Category definitions
  • Category assignments
  • Domain contacts
  • Out-of-domain contacts

It was good that we had found out about categories not making the transition from Exchange to Gmail, because this did pose a significant factor for Jill, who relies heavily upon contact categories. After some analysis it was concluded we could set up the categories as groups in Gmail before migrating her contacts, then migrate each set separately and assign them to the correct group on a bulk basis. It would be a bit tricky, but not a show-stopper.

Because Office 365 seemed to have more of a focus on collaboration, something which was not a major requirement for Terrapin Valley at the time, we opted to go with a thirty day trial of Google Apps to take it for a spin. We would make no change to the existing email environment (other than changing the flow of incoming email from the local server to Gmail via a DNS update); data would be copied up to Gmail - not moved - so we could easily reverse the changes if desired.

The Proposal

After completing my research I outlined for Ted how the migration would work as well as the manner in which the Terrapin Valley Windows, Macintosh and mobile devices would operate in a proposed Google Apps email setup:

  • User accounts would be created in Google Apps, all their email/calendar/contact items copied to Gmail, and the results inspected by all involved. We'd start with test accounts to ensure the process worked as expected. If users were comfortable with the arrangement we'd adjust the DNS MX record for terrapinvalley.org to reflect Gmail servers so inbound mail would be delivered to the new location. It's also possible to go "live" on Gmail first and THEN copy all data up, but we wanted to make sure the environment was suitable for use with the data before conducting the cutover.
  • Windows clients would continue using Outlook 2003 and connect to Gmail via an Outlook plugin called "Google Apps Sync for Microsoft Outlook." This plug-in would replace the existing Exchange server connection and allow these users to access their email, calendar and contacts, which would reside on Google's systems in each user's Gmail account, while synchronizing to a local Outlook PST file.
  • The Macintosh could use Outlook 2011 and connect to Gmail via IMAP for email access. The local iCal and Address Book applications could be set up to synchronize with Gmail, and then Outlook 2011 configured to synchronize the contacts with the Address Book. iCal would be used for calendar access.
  • The iPhone and iPad could be set up to connect to Gmail directly, and email/calendar/contacts would be available on these devices.
  • If we liked Google Apps and decided to continue using it, the cost would be $5 per user per month, or $50 per user for year. For a five-user shop this would turn out to be $25 per month or $250 per year.

I'll be honest and admit I wasn't crazy about keeping Outlook 2003 on life support, albeit temporarily. I made sure to inform my client that direct browser-based Gmail access would be the best and easiest solution for all users; no need for separate email clients and no synchronization of data required. At the very least it would make sense to update the Outlook clients to 2010 as soon as possible.

It's been a tenet of mine for years that an IT professional isn't necessarily there to provide users with what they want, but rather what they need. The same applies for consultants - the trick is to find a way to convince clients that the two are the same. But on the other hand, when implementing a new server change, I've also found that it's best to keep things as simple as possible and conduct a "like for like" migration to eliminate as many variables as possible.

Keeping Outlook 2003 around for a bit would allow users to get more familiar with the Gmail interface without being thrown into it. I also think it makes a good point: Google provides different options for email access, as should any forward-thinking organization.

Another factor was the projected Outlook 2011 setup: it had a lot of moving parts; synchronization of calendar and contacts between not two but three applications, which gave me some cause for concern. Research on the proposed setup turned up mixed reports of successes and failures. Since we were plowing forward on a trial basis, it was decided we'd see what worked and what didn't on a first-hand basis and adjust as needed.

I notified all users at Terrapin Valley of the upcoming plans, asked them to please delete all unnecessary email items to ease the data migration, and laid out a schedule for the initial testing / email migration / cutover to Google.

The Migration Plan

In short, our migration steps were planned as follows:

  • Enroll in Google Apps
  • Create accounts for users within the Google Apps environment
  • Configure settings to permit copying of existing data to Google servers
  • Copy all email, contacts and calendar items for up to Google servers
  • Configure email clients (Outlook for Windows, Outlook for Mac, iPhone and iPad)
  • Configure mail synchronization of Outlook clients and Gmail to permit offline access to email
  • Train users on email operation (with emphasis on transition to Gmail use via browser where possible)
  • Repoint incoming email for terrapinvalley.org to Google

We planned for me to set up Google Apps, create accounts, copy all the mail and configure the Outlook clients over the course of a weekend. The following week would be devoted to having users test the Google email environment (which would merely be a repository for their data until we went live) before cutover.

In Part II of this series, I'll discuss how the migration went and the details involved in the implementation.

Also read:

About

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

Editor's Picks