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.


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. 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. 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 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 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:


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.


I find the article decent except that there is no discussion on the decision making process on choosing Gmail vs. Office365. It's as if you made your decision to go to Gmail before doing the research and there was no consultation with your customer between the two services. I'd love to see an expansion of that decision making process and the customer's "choice" in the matter. One other thing... that chart has a few inaccuracies. For example, the point about mobile device support. Office365 supports the full range of Exchange ActiveSync devices which is actually a longer list of full fidelity devices than Google supports. Saying that Office365 only supports Windows Phone & Blackberry devices is misleading at best. The chart also lists the different Office 365 clients incorrectly. Comparing "Exchange Online" to "Outlook Web App" in the same line, while also calling it "stupid" (BTW, the writer is really calling their own knowledge out at this point) shows the lack of fundamental understanding of the product. Outlook Web App is the web/browser based e-mail interface to Exchange Online... similar, but far superior to, Gmail's browser based e-mail.


If you expect any server built probably around 2003 or 2004 to carry multiple server applications to function 9 years later as well as the day you bought it, then nice dreaming. The server should of been replaced with a stronger server to begin with. You change your client computers probably every 3-5 years. They are faster than before. Why not the server? [You can get a nice quad core Xeon server with gobbs of RAM and you wouldn't have to worry about the server for a long time.] You can't blame the server but who ever is managing the server. Except for a compsany that is barely surviving you won't find too many companies with servers that are that old.


It's very brave of you to lay bare yourself and your thinking. Personally I would steer clear of Outlook 2011 it looks lovely and makes the user feel like she's at the helm of the Enterprise but Apple's minimalist Mail is so much better, especially working with Gmail IMAP. ActiveSync on SBS2003 is a doddle and works great with the iPhone but it's even better with Gmail. Personally I want my customers to ditch SBS as fast as possible because I believe it's a flawed pile of poo. I once restored the backup to a VM (as a test) but it wouldn't even let me log in without activating the installation with MS. How often do you test your SBS backups? Disaster recovery is a nightmare compared with Gmail. SBS is always sold as OEM so you can't legally re-install it on new hardware. Recovering a load of 25 GB mailboxes from a tape backup would take months. Roll on part two, I'm sure it will be a success! What killed it for me with one migration I had planned was that the company director had over 900 folders in her mailbox. Step one for me now is to show the foolishness of filing mail into subfolders - it's a total waste of time.


thanks! What a cool project to be part of.


Really, I am sorry they decided to move things offsite. While the cloud may have its place, I personally am not fond of not being in control of your data. I still have several SBS03 installations out there and we have had to upgrade the disks several times, everything is working as it should and there are no immediate upgrade plans for either. In fact, I have another potential client that would do well by getting a used SBS03 server as it would keep their costs down and aside from MS dropping support on it, is a great entry level server. Anyway, I was wonder if you would be willing to share what you ended up with as far as billable hours. Did you bill separately at a different rate for the research, and then another rate for the onsite work? Are you willing to share the total number of hours billed for this job? I tend to give away the house just to get the job and in today's economy getting the job has not been easy therefore doing a bit of starving here. In most cases my research has not been billable and that is a huge part of the project. I would just like to know how others are doing. Otherwise, good article and I am looking forward to part two. Can't say I agree with the move to the cloud, but while I may not be doing it, I am aware of many that are and have been very happy with it. So the jury is still out for me. :-) Thanks, Rob

Mark W. Kaelin
Mark W. Kaelin

Is your organization contemplating a migration to Google Apps or other cloud-based email system? What is your game plan? What hurdles have you had to consider and overcome?


Thanks for the feedback, and sorry for the delay on my reply. I agree the decision making process as to why Google Apps was chosen over Office 365 could have been fleshed out further; I stated in the article that Office 365 "seemed to have more of a focus on collaboration." By this I meant that their emphasis on Office live collaboration, IM and conferencing seemed overkill - and geared more towards larger companies with a different sort of user base - when the bulk of our needs for this project involved email. Yes, Office 365 does do email too, and Google Apps also has some features we didn't plan to implement at that time, but we wanted to keep the target feature set as minimal as possible per our current strategy. Office 365 seems a fine product, so our selection of Google Apps shouldn't be seen as making the statement that Google Apps is the superior choice for every scenario; it was deemed the superior one for us. Other considerations were the fact Google Apps has been around longer (2007 vs 2011 for Office365) and I felt there would be more of a user base to consult with for tips or problems; we appreciated the Google setup guides and help pages, which seemed custom-fit for our goals, and that as a small company our trial was intended to serve as a "proof of concept" to demo out the product offering by Google. We had a bit more flexibility in terms of how we could restructure our email to try out their solution since we have 5 users; such a decision would have been vastly different and more complex for a larger organization. As it turns out, we did hit a couple of snags with the Google process, which will be discussed in future articles, so the story isn't finished just yet...


Anyone who doesn't use IE is stuck with a cut down version of OWA. This is typical of MS products and for cross platform equality you're much better off with Gmail. For instance Office 365 doesn't work with older versions of iOS. On the other hand MS products look nice though I think Google are paying more attention to design now. Google+ on the iPhone bears witness to this.

Mark W. Kaelin
Mark W. Kaelin

Just to be clear about things - the chart is taken from a previously published TechRepublic Blog post and was created by a different contributor.


Hi Robert, thanks for the comments. I agree that not having complete control of company data can be problematic; the "local" vs "cloud" arguments gets more complex with larger organizations, due to regulatory concerns, privacy and SLAs with the provider. At my day job with a financial company where 200+ servers are present, for instance, the cloud would not be a good fit for us. It's an option, but not a 100% "cure-all" - for instance (despite some marketing claims elsewhere), concerns about availability can be equally applied whether data is kept locally or out on the web (which is why I still keep my critical files with me on a flash drive in case internet access to my Dropbox account is unavailable). In terms of hours spent on the Google Apps migration, it totaled about 20, including research (which I do factor into the billing process), planning, testing, migration, reconfiguration and documentation. I bill at one flat rate for all work aspects involved except for verbal discussions, follow up questions, etc. I think it represents good will towards the customer not to nickel-and-dime them for that 12 minute phone call to clarify documentation, for instance. On the other hand, research is a vital part of the project; it would be great if we IT pros just automatically had all relevant technological details embedded in our heads (solid state drive maybe :-) as clients may assume, but that would be like architects designing a building plan without conducting a site survey of the location, the materials involved, etc. I know what you mean about it being a tough economy - best of luck with your efforts!


Hi Mark, Well written article; where could I share my experience about the migration to Google Apps for the benefit of others? I work for a group of small companies (3 under one umbrella) with 63 users on three domains. We completed the migration three months ago and so far everything is going well except a few small features that some advanced users miss from the old system. But thanks to the preparation, education of users and well planning everything went smoothly. I wish I had a place where to write up my experience. As a comment to your article that will be too long. Thanks,


Thanks for the clarity & background! That really helps. I think one thing Microsoft could do better is tie their public advertising of Office365 to it's real lineage/history. It's built on Exchange 2010, SharePoint 2010 and of coure Lync 2010... but with an online services approach. The online services for these have been around since BPOS (2007 or 2008 I think)... but in reality the lineage of each component goes back a lot farther: Exchange: Late 1990's SharePoint: Early 2000's Lync: 2000 (IM was part of Exchange 2000 and it later was spun off into Office Communications Server) Both are fine products if all one cares about is "email"... but in my experience it's typically a bit more complicated than that: calendaring, Outlook connectivity with full fidelity, IM & call conferencing with desktop sharing/powerpoint sharing w/ full fidelity, etc. etc. I find Office 365 (or it's component solutions on premises) to be more mature than what Google comes close to offering. I think Google wins people's hearts because it's "not Microsoft". That's been my experience at least.


Actually John you're incorrect. OWA on Office 365 has full fidelity/works with any modern browser: Firefox, Safari, Chrome, or IE8/9. The same goes for Exchange Server 2010's OWA. Apple offers free upgrades for iOS devices, so why is it an issue to not support older, buggy, insecure devices?


Thanks Mark... I still question the consultative decision making process that went into the decision with your client. Overall it seems as if a snap decision was made for Gmail over Office 365. Also, do you have a link to the original article/author of that chart? These are blatantly incorrect bits of information that honestly seem quite biased against Office 365 and an uneducated person could be using it as their point of reference between the two services. An accurate comparison should have been used.

Editor's Picks