System survey and data gathering (2/2)

To complete the second part of this section, I am going to talk about the following points:

1. Confirm the number of users to be migrated
2. Get an estimated data size for all users and for each user
3. Make an inventory of all groups that are mail enabled
4. Make sure a password policy that match requirements by Google is active in the local network with no exceptions
5. Check local DNS to confirm local domain name and relation with public domain name
6. Confirm access to the Exchange server with an administrator user that has “Full-Access” permission and “Receive-As” permission on all the databases and all users
7. Confirm access to Active Directory and local DNS services with an administrator user with proper permissions to create/edit/delete user objects and DNS records
8. Confirm there are available PCs to be used for GAMME when needed for data migration
9. Agree on a policy and plan to confirm all users data has been migrated 100%, and identify reasons for data migrations failures and required actions before you even start that activity

Confirm the number of users to be migrated

Knowing how many users will actually get migrated is very important as it is going to affect how you are going to prioritize the users-related tasks in your project. For example if you know that 500 users will get migrated, you can get the number of how many users with data larger than 2GB and do them first, or schedule them on a holiday or weekend. Also it can give you an estimate on the overall time the project might take.

Get an estimated data size for all users and for each user

You want to know the data sizes that you will work with, this is critical and important, because it will tell you how much time you will spend with the data upload and migration. It will make you decide how to do this step… Either doing it in parallel with users training, or after user training or before users training and before even they begin to use the new Google Apps service.

Once you get the whole data size, you can get it for each user, you can segment users by department, importance or alphabetical order… You want to put your data migration plan impression on this step because this step will be the first time you know about the current data size and your reaction is very important to measure the expected time and resources that this activity requires.

Make an inventory of all groups that are mail enabled

Almost all organizations use mail enabled groups to communicate. It is extremely important to have those groups inventoried and listed with all of their members and their permissions so they can be replicated in Google Apps… In the case of too many groups, GADS can be used to sync the groups with their members to Google Apps, otherwise they have to be manually created from the Groups control panel.

Leaving out the groups will result in many complains and inconveniences by users who move to Google Apps and try to send to an old group to get an NDR…

Make sure a password policy that match requirements by Google is active in the local network with no exceptions

This is an important thing to check, if you want to use GAPS (Google Apps Password Sync), the tool will NOT work and will NOT sync passwords to Google unless Google’s password policies are met. If you don’t make sure that the local password policy meets Google’s policies, users will be locked out of their accounts waiting for admin to reset it for them.

Check local DNS to confirm local domain name and relation with public domain name

When using a single domain name internally and externally, this might create an issue when changing MX records, as Exchange server will use the local DNS to look for the MX records (since the domain name is the name both internally and externally). if you want to use a subdomain to enable dual delivery such as (apps.domain.com), then you need to explicitly create that zone in the local domain and create the related Google Apps MX records in that zone; otherwise Exchange server will not be able to send or forward emails to that sub-domain.

Confirm access to the Exchange server with an administrator user that has “Full-Access” permission and “Receive-As” permission on all the databases and all users

Having the correct access level to Exchange server is critical to make sure all forwarding rules, transport rules or changing the domains settings is all going as planned. Getting the required access to the Exchange is critical to make sure co-existence and migration activities can go smooth and without errors.

Confirm access to Active Directory and local DNS services with an administrator user with proper permissions to create/edit/delete user objects and DNS records

This step is required to be able to create contact objects, user objects, OUs and to modify any attribute or properties that are required by the coexistence scenario and setup. It is also required to have administrative access to be able to setup scheduled tasks and to setup the tools and scripts.

Confirm there are available PCs to be used for GAMME when needed for data migration

If GAMME is going to be used, then it is recommended to have it setup on a separate computers and not to have it on the AD or Exchange servers. Having the GAMME installed on AD server might cause an extra load to the server. And having GAMME on Exchange server might cause data store corruption!.

Agree on a policy and plan to confirm all users data has been migrated 100%, and identify reasons for data migrations failures and required actions before you even start that activity

Sometimes the handover and the completion of the project is halted because of this critical issue… you need to make sure before telling the customer that their data has been migrated to Google Apps, that the data is actually got migrated in the right way. Telling the customer that the data has been migrated, then either you or the customer find out that there are missing data is a bad thing…

You need to set a plan, activities list, and a process to confirm and validate the migration result, and to take the necessary actions in case of any failures, or missing data.

Of course the above points are not everything you need to watch out for, but I have did my best to list all the issues that I encountered, and will make sure that I update the article with more points or missed important information as I go.

Next part I will start with the actual planning work and what might affect or make your decisions go in a certain way or approach.

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 (you are here)