The migration and change management phase of a Google Apps Deployment can vary greatly in the amount of time it takes to execute depending on the deployment approach. Outlined below are some of the key tools, terms and data migration options to consider when performing a migration.

Data Migration Approaches & Tools

As we discuss in our Google Apps Deployment Guide, when performing a migration of user data to a new platform it is important to gain an understanding of what data is required to be migrated and where that data is stored. Most commonly in a Google Apps migration email, calendar, and contact data is stored on one central server managed by IT. In some cases data may also (or solely) be located on the end user’s machine. This gives us two common approaches to migration; server-side and client-side. We will also discuss a less common but known approach, the PST migration.

Server-side migration

Server-side migrations involve installing a migration tool on a migration station to connect directly to the server and migrate the end user data to their Google Apps accounts. This is usually performed with the Google Apps Migration for Microsoft Exchange Tool (GAMME). This is a free tool provided by Google that obviously given the name, was built primarily to migrate data from a MS Exchange server. However it can also be used to migrate from any IMAP enabled server over the IMAP protocol, which allows for the transfer of email data only (not calendar/contacts).

Google also provides a free tool for migrating from Lotus Notes aptly named Google Apps Migration for Lotus Notes (GAMLN), which allows for migration of email, calendar, contacts and Lotus Notes email archives.

Another server side tool worth noting is the Cloud Migration Tool which is a paid tool provided by Cloud Solutions. This is a robust migration tool used to migrate from nearly all the leading mail platforms to not only Google Apps but to many other cloud email providers as well.

*Server side migrations are commonly run twice. Once prior to cut-over in an initial migration for the bulk of mail and once again after the cut-over for the remainder of mail and calendar/contacts*

Client-side migration

Client-side migrations most commonly need to be performed in the following scenarios

1. Your company has POP email enabled and no mail is stored on a central server
2. You are performing an IMAP migration and require the migration of calendar and contacts from the end user’s individual machines
3. End users’ current workflows are to commonly reference locally stored email because of an existing IT storage policy and would require it in their inbox post go-live
4. Your server’s health or local network does not allow for a server side migration

The most common tool used to perform a client side migration is the Google Apps Migration for Microsoft Outlook (GAMMO) tool which is another free tool provided by Google. This tool is also embedded within the Google Apps Sync for Microsoft Outlook (GASMO) application. If choosing to allow users to sync Outlook using the GASMO application, you would only need to download the GASMO tool on the workstations to perform the client side migration rather than also downloading GAMMO as a stand alone tool.

The GAMMO tool only migrates from MS Outlook and when migrating from other mail clients such as Thunderbird and Mac Mail, you will need to rely on 3rd party tools or perform manual exports/imports, both have been known to produce mixed results.

*Client side migrations are ideally performed after the cut-over with the tool only running once to simplify communications, consolidate support efforts, and prevent data duplication (specifically of calendar and contacts)*

PST migration

A PST is a Microsoft file type specific to storing MS Outlook personal folder data, most commonly email messages. The GAMME tool is used to perform PST migrations as one of the migration options available in the tool. You would most likely perform a PST migration in two different scenarios:

1. Your internal network can not handle a migration and would prefer to ship the mail files off site to be migrated on another network
2. Your only option is to perform a client side migration because of one of the reasons listed above, and you would prefer to have all the client side files aggregated to one machine and migrated by one staff member or consultant rather than individually on each end user’s machine.

*PST migrations are most often performed post cut-over as IT teams would prefer not to perform the logistics of pulling down mail into the PST format followed by running the migration both prior to cut-over and post cut-over as it is time intensive and rarely adds much value opposed to performing the migration only once after the cut-over has occurred.*

Migration Speed

The speed of your migration will be determined by several factors:

• Bandwidth on your network
• Processing power of your migration station
• Number of migration stations running concurrently
• Health and hardware resources on your legacy server
• Total size of data to be migrated
• Google servers’ import acceptance rate (1 message/second)

Change Management

During the migration of data IT teams will periodically need to check in on the status of the migration however much of it is waiting on the data to transfer. During this time it would be advantageous to be conducting change management activities to prepare your end users for the go-live.

Once again the execution and approach to change management can vary greatly depending on the culture of the organization and chosen deployment approach. However below is a list of common activities used by organizations to improve the experience of moving over to Google:

1. Assigning “Google Guides” who are either familiar with the technology or are brought onto the platform prior to the company wide go-live. These guides serve as champions of the platform and provide ad hoc support for their fellow end users.
2. Providing a series of live webinars prior to and post go-live to give an overview of the technology and answer any end user questions.
3. Make your users aware of Google Gooru, which they can visit at their leisure and become more familiar with the platform.
4. Sending out a company wide series of emails highlighting the benefits and features of the new platform as well as helpful links and resources.
5. Providing a support team onsite and available all day in the days immediately after go-live.

Phase 3 of Google Apps deployment is important because it is when all your data is migrated from old legacy systems where data loss can occur. It is also crucial to educate your end users so they are aware of the differences between Google Apps and your legacy system.

This article is Part 11 of Google Gooru’s Comprehensive Guide to a Google Apps Deployment. To access the entire guide for FREE, please fill out the form located here.