As was described in the second part of this book, the Google Apps offering is structured around two themes:
It is thus necessary to precisely qualify the requirements regarding these two topics, to identify which applications will actually be made available to users. Depending on the needs or constraints of a company, it is sometimes better not to enable some of them: Google Talk, Google Video, or even Google Documents, and so on.
Usually, choosing among communication and office tools in Google Apps is rather obvious. The choice might be more delicate for other Google services, though. Among these, the following might prove particularly useful:
To this, one should add the data-transfer tasks, which means importing existing data into Google Apps. For each Google application, this will determine the workload during the preliminary analysis phase as well as during the actual migration phase.
A lack of data transfer requirements might make the pilot phases superfluous. On the other hand, importing data (because the mail system is obsolete, has an exotic configuration…) could imply specific, ad hoc developments. Although a number of tools are provided by Google, they won't necessarily suffice in all situations.
Advanced integration of the Google Apps in the IS often implies planning a larger migration project. One or more additional steps can be required. As examples, let's mention the following projects:
Security and availability of tools are among the most often quoted assets which motivate the SaaS model. However, during a migration project, these two perceived advantages might sometimes be put to the test. One priority of the pilot project is to mitigate and, when possible, eradicate any concerns related to these topics.
Finally, depending on the desired integration level, it could be necessary to anticipate a rollback plan, which warrants a phase of its own in the migration project.