Shown in the following figure are the standard steps of a migration to Google Apps:
Stepwise implementation of the pilot
The very first thing to do is to subscribe to a Google Apps domain and to associate it to an existing domain (ex: mycompany.com) and not to, say, a test domain dedicated to the pilot project (ex: mypilotproject.com). We shall see later that this has no impact on the existing infrastructure (mail, DNS declarations, and so on). The subscription URL is currently http://www.google.com/a, and the "a" at the end designates the applications universe at Google. The outcome of this step is the administrator credentials for the Google Apps domain. The service is however not yet active. Indeed, for obvious security reasons, Google first needs to check the actual ownership of the domain name declared during the subscription process.
Here are the steps to follow:
- Connect as an administrator to the Google Apps configuration panel and initiate the process of checking the domain name.
- Choose one of the checking methods. An assistant will provide the detailed steps to follow, depending on the method selected:
- Using an HTML form: this requires write access to the website hosted under the declared domain.
- Using CNAME records: this requires write access to the DNS configuration for the declared domain name.
- Launch the checking process from the configuration panel. This operation can take from 2 to 48 hours.
- Once the check has been completed by Google, the status is displayed in the configuration panel and the service is available. Adding users can begin.
Using services such as the APIs, mail routing, or web filters from Postini requires subscribing to Google Apps Premier Edition. The upgrade from the Standard version can be done at any time. The subscription includes a one-year trial period.
We refer the reader to the introduction of Part 2 of this book for a detailed description of the differences between the various Google Apps versions.
The next step is to create accounts for the pilot users. The required information is: first name, last name, username (prefix of the mail address), and password. Since this is an experimental phase, the number of users will rarely exceed 20 accounts. Several possibilities are available to create them:
- Manually from the Google Apps console.
- Using a tool such as GAML.
- Exporting and importing CSV files.
- Programmatically, through the Google APIs. This method is certainly the best choice when the migration involves more than 3000 users.
Chapter 7 describes in detail user management in a Google Apps domain.
Once the accounts have been created, it is possible to change the data of some users, in particular to grant them specific rights in the domain.
The next step is enabling or disabling applications and services in the Google Apps administration console. Even mail will need to be enabled because by default it is disabled.
In the common case where the mail is part of the pilot project, the first recommendation is to adopt a so-called "dual delivery" strategy. The purpose is the redundant storage of mail, both on the existing mail system and in Gmail, without users having to change their address. There are two advantages to this solution:
- The old mail remains available and readable for the whole period of the pilot project in case Gmail should lack critical features or data
- At the end of the pilot project, the rollback to the earlier situation is made easier as no data recovery task will be required
However, this strategy may not apply in some contexts, in which case you'll choose "direct delivery". This strategy applies both to incoming mail (that is, received mail) and to outgoing mail (that is, sent mail) and can be set up in two modes: either going through Gmail or using the existing mail server.
To implement the "dual delivery" using the existing mail server, no change of the MX-record of the main domain is needed. For pilot users, you can configure sending a copy of each incoming mail to another associated address. These settings are defined directly on the mail server and are unfortunately not supported by all mail solutions. The domain of the associated address should however be associated to Gmail with a specific MX-record. The Google Apps can handle sub-domains as simple aliases of the main domain. Thus, using a sub-domain of the main domain will be the best choice for the associated addresses.
The dual-delivery principle with an existing mail system
To implement "dual-delivery" using Google, it is necessary to change the MX-records of the main domain and to define a specific routing rule in the Google Apps console. The propagation delay on the Internet of MX-record changes is up to 72 hours. Meanwhile, the messages are routed either to the old address or to Gmail. Beyond that, note that any mistake in these changes will imply mail service unavailability or even loss of messages. Fixing the problem could require an additional 72 hours. Finally, to revert to the initial situation, it would be necessary to change the MX-record one more time.
The dual-delivery principle using Gmail
Depending on the scope of the migration, a number of applications should import all or part of the existing data. No doubt messages, contacts, and agendas are the primary data that should be imported. Migration tools will be described in Chapter 14. Numerous solutions are also available from Google's partners on the Google Marketplace.
Users can thus be notified when their new communication and collaboration platform becomes available.