Author’s Note: We first published this post over a decade ago after we adopted the then “Google Apps for Work.” The product, since rebranded Google Workspace, has served us well for all these years. In fact, we liked the product so much that we eventually transformed this website into a blog about Google Workspace.
An increasing number of our clients have been making the transition to Google Workspace for their email and other collaboration needs. After recently weighing the pros and cons of upgrading our current email server, we decided to make the move to Google Apps as well.
Evaluating the Alternatives
Upgrading our email server would have been costly in terms of IT consulting hours and we would have still been responsible for keeping the server lights blinking at the colo where we keep our production and development servers. Plus, our email uptime would still have been dependent on a single machine’s uptime as well as on the reliability of a colo’s power and Internet connectivity.
After looking at the $50 per user annual cost of Google Workspace and about twice the per-user annual cost for hosted BlackBerry Enterprise Server (BES), we decided that this was more than a fair price for a scenario in which we could worry about one less spam appliance and two fewer [virtual] servers.
After a review of some of the “Geeking Out” videos on Google’s YouTube channel, Google’s distributed architecture started to look better and better. The fact every Google write is to multiple drives—and even to multiple physical locations—convinced us that our all-important email flow would be based on a significantly superior infrastructure than anything we could develop and support internally.
Migration to Google Workspace
Google provides both client-side and server side migration tools, so importing email, calendar, and contacts from standard apps is relatively straightforward. However, if you need to import contacts from a non-standard source, you’ll find that the contact import is devoid of a mapping tool, and a “custom import” can be time-consuming.
Also, if users want to maintain a multi-level folder structure in their email client, the emails associated with those folders need to be stored on a user’s local drive. Google does not have a hierarchical folder structure, as their search engine effectively eliminates the need for this.
For BES, one option would have been to connect to a BES server that we still maintained. Even though we already owned BES user licenses, we decided to go to BES in the cloud as well — and we signed up with ExchangeMyMail. Their process of connecting to Google Apps is straightforward and their support was excellent.
Deployment Planning
As with any technology migration, proper planning is necessary. Google provides a comprehensive Webcast video that gives an overview of deployment best practices, including how to run your legacy system in parallel with Google Workspace using split delivery.
With proper planning, the cutover can be extremely fast, even for larger organizations. In fact, Google goes as far as to recommend a “big bang” deployment — which really means a rapid cutover rather than an overnight one.
Finally, Google stresses it’s important to get your users bought into the process. This includes building user enthusiasm for the process and providing users with the proper level of support throughout the process.