The preliminary study remains the essential phase of a migration, whatever the strategy is. Its goal is to precisely identify the company profile, its functional and technical requirements, as well as the features of the existing mail system. It also aims to identify the dependencies on the IS and should anticipate advanced integration tasks. It will conclude with a detailed schedule of the actual migration.

Its duration will depend, for the most part, on the number of people involved in the project and the number of topics to handle.

The pilot phase enters the picture when the feasibility of some technical solution needs to be checked or when the solution is a vital issue for the company. It is also important when the coaching of future users must be organized.

This phase is quite common for mid-sized or larger structures or when advanced integration with the IS is considered (for example, Single Sign-On, industrialization of data transfer from archives, integration with an enterprise portal, establishing links with enterprise workflows, and so on). Chapter 13, The Pilot Project contains more details on the pilot phase, which is its topic.

The training phase is organized in sessions, which may take two forms:

The support phase is for helping users, and can be conducted simultaneously with the pilot and migration phases. It is particularly useful when users have a low level of technical autonomy.

This phase is also the opportunity for the existing help desk to gain expertise on the Google Apps.

Organizing support is linked with nominating ambassadors. These are employees who were specially trained for the Google Apps and in charge of providing on time help to users.

Setting up a rollback plan includes defining all tasks necessary to roll back from the Google Apps to the previous solution. One important aspect of this plan is to know exactly how to remove any data hosted in Google's datacenters. This includes, in particular:

The aim here is not to define preventive actions that could be taken if a problem occurs but rather to anticipate an inverse migration plan.

In a sense, this phase could be conceived as an extension of the pilot phase because the plan should be tested before the final migration. This phase is often integrated in one of the tasks of the pilot phase.

Advanced integration usually happens only after the completion of the primary migration steps which involve mail, calendar, and contacts.

Advanced topics, which are identified in the preliminary study, usually include such topics as:

The length of this phase greatly depends on its scope.

The actual migration phase is the last one (except the advanced migration). Its aim is to have all users working with the Google Apps, following previously validated procedures (see the pilot project, training, and so on).

Paradoxically, the migration is one the shortest phases. In most situations, communication applications are available within 48 to 72 hours. This includes data transfer to Gmail, Google Calendar, and contacts.

Chapter 14, Performing the Migration is entirely devoted to a detailed description of this phase and includes a review of the tools available on each platform.

This is a minimalist strategy that is well-suited for smaller organizations that have a technically autonomous population and for which the dependency on the IS remains weak.

"Flash" strategy

This is a strategy for small organizations whose population should be trained to take charge of the migration.

"DIY" strategy

This is a strategy for small to mid-sized organizations. The data migration is usually handled by an administrator; only some specific tasks are left to the end users, such as migrating mail archives, for instance. The lack of autonomy of users is balanced by their small number. This can usually obviate the need to set up a helpdesk. User training should thus include migration tasks. This strategy is less suited to multisite configurations, but is appropriate when the dependency on the IS is not too strong. This last point could in some cases justify setting up a pilot phase.

"Light" strategy

This strategy is adapted to mid-sized or larger structures when dependency on the IS is weak to medium. Most often, this implies setting up a pilot. The technical autonomy of users and their number imply organizing a dedicated support infrastructure. Resorting to ambassadors is an alternative which can also be considered as a complement to the helpdesk, if the number of users is large.

"Standard" strategy

This strategy is adapted to larger organization (international subsidiaries, and so on). The dependency on the IS is significant and necessitates setting up a pilot and specific phases devoted to critical and complementary tasks. On such a scale, anticipating a rollback and reversibility plan is particularly important to mitigate the risks. The large number of mostly non-technical users requires setting up a helpdesk and designating Google Apps ambassadors:

"Advanced" strategy

These are mostly small, niche companies specializing in new technologies (software engineering companies, start-ups, and so on). Flash migration is particularly well adapted because the population is technically autonomous. Training and support are in this case unnecessary. Furthermore, the small number of users favors a thorough delegation of the whole migration to the users themselves, from the data transfer to the configuration of the various tools.

These are small organizations whose business is not related to new technologies (for example, craftsmen, retail stores, associations, and so on). Here again, the small number of employees allows them to take charge of the migration themselves. A training phase should be planned, however.

These are mid-sized companies whose business has no relation to new technologies (for example small industry, construction and civil engineering works, and local authorities). The small size of the population allows the delegation of migration to the users themselves, provided some initial training is offered. Let us note that moving to the "Light" strategy is usually motivated by the need for a pilot phase. This phase makes the migration to the new solution smoother, thanks to a change-management policy.

These are mid-sized organizations with users who have, for the most part, some technical autonomy. In principle, a "Flash" migration could be performed with minimal training and preparation. What could lead to choosing the "Light" strategy instead is the need for a pilot strategy required for validating the technical feasibility of some tasks.

These are mid-sized organizations with no specialization in computing. They have several geographic locations and have their own mail system. The absence of technical skills and the number of employees would in principle favor the "Light" approach, which implies preparing for the migration through a pilot project and user training. Adopting the "Standard" strategy, however, is most likely because it adds a helpdesk. The selection of ambassadors, planned in the standard strategy, remains optional however, because the number of employees is not large enough.

These are mid-sized organizations whose population has good technical autonomy. They have several geographic locations and run their own mail servers. On such a scale, this is the only case where the "DIY" strategy is still possible, meaning that training and user support can be left out. However, adding the pilot phase makes sense to validate the technical feasibility of some tasks (connecting to an enterprise directory, for instance).

These are mid-sized organizations without technical specialization. They have several geographical locations and have their mail servers outsourced. The most reasonable strategy is the standard one.

These are large organizations with no specialization in computing. They have several locations and own their mail servers. They often have advanced integration needs for the Google Apps. The Advanced approach is the best solution. Without the advanced integration needs, the Standard approach could be sufficient.

For each of these types of organization, the following table summarizes the most usual strategies that can be applied for a migration to the Google Apps:

	Flash	DIY	Light	Standard	Advanced
OT1 (10 employees)
OT2 (10 employees)
OT3 (50 employees)
OT4 (50 employees)
OT5 (500 employees)
OT6 (2 000 employees)
OT7 (2 000 employees)
OT8 (10 000 employees)