Going Google raises the question about the lifecycle of user identities. It is quite common to find several identity directories in the same information system. For example, you can find a human resources directory and simultaneously an account directory, and so on. When using the Google Apps, this kind of information is outsourced.

In other words, how do you manage efficiently and in detail Google Apps account creation and update or deletion of a profile in the case of a resignation or firing? Particular care should be taken in order to prevent former employees from accessing their professional mail once they've left the company.

The nature of the data stored in the Google Apps has an impact on which strategy to adopt. Managing passwords is obviously quite different from managing phone numbers or postal addresses. Different data don't require the same level of reliability.

In many cases, the additional archiving service from Postini (see Chapter 5) can certainly answer these kinds of needs.

Mail systems usually include sharing features such as mailing lists. What we mean by mailing list is a group of internal or external mail addresses, or both, accessible to selected users of the domain, without the assumption however that they manage the list themselves. An example of a mailing list could be a list of "gold" clients that only salespeople can access.

The notion of "group", which can be managed for Google Apps, covers precisely this kind of need (see Chapter 7). However, for the time being and without any further extensions (check the Google Apps Marketplace), managing the visibility of groups is possible only programmatically through the APIs.

Accessing external contacts using a third-party enterprise directory (LDAP) is a common functionality of desktop clients such as Outlook or Thunderbird. It is, for instance, possible to access the mail addresses of employees of a subsidiary or of a partner. Gmail however does not propose access to this kind of contact; it is imperative that they are stored in the repository of the Google Apps domain. Here again, the Google APIs allow retrieving all required information automatically from external sources.

Adopting Gmail offers new possibility for accessing mail. Provided an Internet access is available, mail, contact, and events are accessible from anywhere. Mobile access to mail should be included in the strategy, too.

This last topic can open new perspectives and sometimes even bring the existing infrastructure into question. For example, let's mention the Blackberry offering, which dominates the market and which bundles client terminals, software to be installed on the enterprise mail server, and specific mobile operator subscriptions.

The pilot project should also help define the target authentication mode and test its implementation. This choice, in particular, is related to the ease of access to the Google Apps. However, its criticality being low, this decision can be postponed.

Keep in mind that the bare minimum for a Google Apps user is not having to remember yet another login/password pair. These should be synchronized with the enterprise directory. This can be achieved with the Google APIs.

Setting up an SSO mechanism, which totally automates and streamlines the authentication process, is the ultimate solution (see Chapter 8 for more details).

The migration of archives involves mail stored outside existing mail servers by users themselves. This is a common practice, because of lack of storage space on servers. Archives are large files whose format is proprietary (.pst for Microsoft Outlook, for instance).

The pilot project is probably the best occasion to determine whether mail archives should be imported into Gmail or not. If such is the case, it might be necessary to install some specific software on each desktop.

Here are the different strategies available, in order of increasing complexity and impact on the pilot project:

One of the major goals of the pilot project is to estimate the real cost of owning the Google Apps. Experience shows the pilot project often reveals which tasks are needed during the final migration. One example is the merging or syncing of several user directories, which is a prerequisite to authentication delegation (see Chapter 8).

The TCO includes all of the following:

Note that the TCO is necessary to compute a realistic ROI2 estimate.

Any migration should come with a rollback procedure. This amounts to defining the tasks to perform in case of failure during the final migration. It would certainly not be admissible to leave users without mail or lose data after a grid or network failure.

This rollback mechanism is not to be confused, however, with the reversibility plan. Reversibility refers to the ability to switch back, after an extended use of the Google Apps, to the old mail system which, in a way, is closer to an inverse migration.

Reversibility guarantees that the system is not bound forever to Google Apps. This primarily implies being able to extract all data from Google's datacenters. Addressing these kinds of issues is part of the pilot project.