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:
- Very small companies, which have fewer than 10 employees
- Small companies, which have between 10 and 250 employees
- Middle-sized companies with 250 to 2,000 employees
- Large companies with more than 2,000 employees
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:
- Companies and branches sharing a single mail server for the whole IS
- Companies and branches sharing a single mail server, which is outsourced to some provider
- Companies having one dedicated mail server for each subsidiary
- Companies having one dedicated mail server for each international subsidiary
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:
- End users who are largely autonomous with technical matters (for example, employees of a software engineering company)
- End users who are not autonomous but are motivated technically (imagine a company that has recurring mail problems, like unavailability, and so on)
- End users who are not autonomous and are poorly motivated (companies for which reducing costs is a priority and for which the IS is not part of the core business)
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:
- Industrialize the migration
- Delegate most of the migration to the end users
- Make the support and training phases optional
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.