This chapter aims to present various migration strategies to the Google Apps. For this purpose, the first section describes a number of technical and organizational criteria that we shall use to characterize a company. They will come in when we define the optimal strategy. Later, we define five strategies and describe them in detail. Finally, in the last part, we examine eight types of companies, among the most usual ones, for which we propose one or more strategies while giving the motivation for our choices.
The number of users to migrate, itself related to the size of the company, is the fundamental parameter in the choice of a migration strategy. It is not hard to understand that migrating 50 users is quite different from migrating several thousands of employees.
From this point on, we shall consider for simplicity's sake that the number of employees in the company is the actual number of users to migrate to Google Apps.
Thus, we propose the following standard classification:
Contrary to popular belief, the length and complexity of a migration and a pilot project is not necessarily linked to the number of users to migrate. The steps of the migration project, however, are related to this parameter. For example, it is quite likely that a large company will ask for change management support for their users, whereas a smaller high-tech start-up can probably do without such support. In the former case, setting up a user support team and creating Google Apps ambassadors should be planned.
Another important parameter for the choice of a migration method is the degree of geographic dispersion of the messaging infrastructure. Here are a few examples of geographic dispersion for various types of companies:
Geographic dispersion usually dictates a subdivision of the migration process. This should be planned early on. The SaaS migration will completely eradicate the dissemination of mail servers.
The existing organization and responsibilities will obviously be impacted as well. One simple solution could be to designate, for each site, a person who will assist with the migration. His or her mission will be to ensure the coherence of the migration for that site.
Within this context, we propose the following categorization of end users:
To start with, let's first note that the migration might not necessarily concern the whole company but only a subset of the users (department, subsidiary, entity, and so on). Once this population has been identified, the degree of autonomy of concerned users should be evaluated. Tasks that can be assigned during the migration will depend on this evaluation. Put another way, the amount of technical and logistical support, as well as training that they require will depend on this evaluation.
If the technical autonomy of users is good, designating ambassadors remains optional and the user support can be more lightweight. If users have significant autonomy, it will be possible to:
There are large companies, whose size exceeds 10,000 employees, which delegated the migration to their end users (for example, account configuration, importing existing data, and so on). Still, such a situation remains rather uncommon.
Human factors should not be neglected. A migration involving a population of mostly recalcitrant users will obviously not take place in the same way as one where people take a proactive stance with respect to change. One thing should be clear though: the migration to Google Apps can ultimately be justified to users only by increased functionality, as compared to the status quo. The pilot project, which will be the topic of Chapter 13, The Pilot Project, can turn out to be very useful for detecting inertia among users and taking appropriate measures.