Introduction

This article is reflecting my own experience in planning and executing migration projects from an Exchange mail system to Google Apps for Work… I will try to make it as organized as possible while I make sure I include all the information and problems that I came across during my time working with these projects…

Why it is important to have a plan as close to 100% accuracy as possible?

First planning every project is the most important and critical phase. If you plan wrong, you will fail, if you plan well, your project will get through… But if you fail to plan, then you are making a plan to fail… whatever you do in the project planning phase/stage/time is considered a plan, whether a good one or a bad one… So doing that right is very important to everyone…

Second, when talking about an existing infrastructure of a system, it mean we are talking about the associated culture with it as well. Having an in-house Exchange Server, and an Active-Directory means an IT team, whether that team is a single person or multi-person team, you will have a team… to be able to go through the process of changing how this team thinks about their environment you will need a plan to manage that change… There will be types of IT who oppose this project and will do whatever is possible to either delay it, hold it, or even kill it completely… while other type will endure the change, and even take a key role with the project implementation team… So it is important to understand all the possible personalities of the IT team to be able to make the project a success…

Of course there are many reasons for the IT team to embrace the new change, but as I came across many cases, I really found their reasons to reject this change to be weak and are easily countered, such as the fear of being left out with nothing to do, or no system to manage, or being stripped or all the control and authority he used to have with the in-house system… Well that can happen if HE wanted it to happen that way…

Instead of that negative thinking, he might use the extra space he will get to improve on a certain service or process in his department that is unaffected by this migration project, or he might engage the end-users with workshops to introduce them to the cloud culture and the means to collaborate with cloud email and workspace… He can actually start a new change management process that will help the project team finish their project, and the end-users to get through the new learning curve, and at the end he will be participating with even more than what he used to do with in-house system…

So, after this brief (not really) introduction, I will move to the core of this topic, which is observations and notes to take into consideration when preparing and planning a migration project to Google Apps.

I will talk about the following points, starting with the first in the next part:

1. System survey and data gathering
2. Providing the right work scenarios
3. Risks and stopping points

So, I’ll be around soon with part 2, and maybe will talk about more than one point if I manage to.

Follow with the series:

1. Planning a migration project to Google Apps the right way – Part 1: Introduction (you are here)
2. Planning a migration project to Google Apps the right way – Part 2: System survey and data gathering 1/2
3. Planning a migration project to Google Apps the right way – Part 2: System survey and data gathering 2/2