So, after the introduction in part 1, I will start with this subject, which is the most critical of the whole project, because based on the output of this step or phase, your plan and your action and teams will be decided.

System survey and data gathering

For me, the most important tasks that always created issues and troubles in every project, can be resolved by making sure the following items are all known and documented before starting to make the plan:

1. Make sure the domain to be migrated is not registered with Google Apps
2. Confirm the customer has access to the public domain DNS zone, and get the access
3. Internet connection: its stability and available bandwidth
4. Find out if a mail security or anti-spam solution is in use, and email flow route
5. Find out the most important workflows and processes that are related to the email system
6. Check about any forwarding rules and any contact object in AD and Exchange
7. Make sure AD is structured logically and cleaned up from any unneeded objects, so GADS can be used
8. Check for any transport rules on Exchange server
9. Confirm the number of users to be migrated
10. Get an estimated data size for all users and for each user
11. Make an inventory of all groups that are mail enabled
12. Make sure a password policy that match requirements by Google is active in the local network with no exceptions
13. Check local DNS to confirm local domain name and relation with public domain name
14. 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
15. 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
16. Confirm there are available PCs to be used for GAMME when needed for data migration
17. 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

I will go through all these points one by one to explain why they are important, and what problems each of these can create if it left out not undocumented

Make sure the domain to be migrated is not registered with Google Apps

It might be a case where you want to start your project after setting the plan, and suddenly you are blocked right before you even start. A new control panel for the same domain will not be possible to create until the old one is completely deleted.

What is the problem here?

Well, the customer might have created that control panel long ago and forgot about it… When you come and start working on his new project, you will then know that there was a long lost forgotten control panel that no one has access to…

What do to if you find out that this is the case?

First, make sure that control panel is completely dead and no one is using it. Then open a case with Google Apps support asking to delete the old control panel. This process will take around 7 days, but usually is completed much earlier than that.

You will need to provide domain validation through a record Google support will ask you to create on the domain you want to delete.

Confirm the customer has access to the public domain DNS zone, and get the access

What is the problem here?

You will need to access the DNS zone of the domain, without it you will be unable to do the following tasks:

1. Verify domain after control panel creation
2. Changing MX records to point to Google Apps
3. Cannot provide DNS verification to Google support when needed

The first 2 tasks are the most critical to the whole project, so it is important to make sure you know how to access the public DNS zone management

If you started the project without this information, then expect a lot of delays and holding time until you get that key information.

Internet connection: its stability and available bandwidth

Well, Google Apps is a cloud service, means it needs an internet connection to work… I would say that the available bandwidth should at least allow for normal web browsing and email communications. There are many resources and tools that will allow to calculate the required bandwidth, of them, I know 2 good tools, one of them is an actual calculator and the other is a good article on how to calculate the bandwidth and what to consider when doing so (and an additional document form Google about network best practices for large deployment):

1. Calculator: http://www.integratelecom.com/resources/pages/a/big-data-network-bandwidth-calculator.aspx
2. Article: https://www.technibble.com/estimate-bandwidth-needs-customers/
3. Google document (PDF): Networking Best Practices for Large Deployment (http://static.googleusercontent.com/external_content/untrusted_dlcp/ggg.re/en/us/support/enterprise/static/gapps/docs/admin/en/nftf/networking_guide/gapps_networking_guide.pdf)

Usually, I don’t consider the bandwidth to upload/migrate user data to be among the required minimum, because it will be a temporary resource. But we do prefer to be able to do the migration from the customer’s site. If the bandwidth will not allow for that, then I will have the plan to export the data to PST files and upload them from different location

Find out if a mail security or anti-spam solution is in use, and email flow route

This is an important task and information to find out about, later on this information might help with co-existence scenarios troubleshooting or issue investigation, it is important to know how email is being processed once delivered to the old Exchange server before reaching the intended end destination.

It is also important to understand the routes the message is taking when outbound and inbound, this knowledge will also be critical to any troubleshooting activities that are related to co-existence setup

I recently got an issue with a project where a SonicWALL was in use as an SMTP gateway of the Exchange server, due to the security on SonicWALL it was marking all emails that get received from Google through the default routing rules as spoofed and spam emails, some of them are being deleted as well… That was fixed by fixing the SPF records to include Google Apps servers so SonicWALL will stop marking emails as spoofed/spam and delete them.

Find out the most important workflows and processes that are related to the email system

Well, this is a tricky one… Basically you will need to get into their own work process, you will have to investigate and collect information about any automated process or workflow they have that is depending on the email service…

Such as a specific requirement for a customer that forces approval for every email coming from specific external recipients to internal recipients, or any email that is going outside the domain should be approved first by an administrator or a department head or secretary…

Another case which an automated ticketing system, or an inventory system or ERP system or any custom application that is built and using email as a core function or as a configurable feature to allow communication with end-users.

What is the problem here?

Basically, there is no direct problem if we left this part unknown and unchecked, but if in the middle of the project you have discovered that there is such a requirement was hidden and now it stopped working, a lot of confusion and dissatisfaction will happen from the end-users, which will affect how the project go… This will be significant when there is a strong internal rejection or refusal to the change that is coming with Google Apps.

Check about any forwarding rules and any contact object in AD and Exchange

This is easily one of the points that is forgotten or left unchecked most of the time. This will cause issues when enabling the co-existence scenario, so it is important to know what is being forwarded on the Exchange server ahead of changing anything related to it, so it could be documented and also to know what to change later on from Google side…

Also finding out about the contact objects in Exchange and Active Directory will help us put the domain shared contacts into good use in case that was needed and we will use GADS.

What is the problem here?

When applying the forwarding for the co-existence scenario, all existing forwarding rules on Exchange will get over-written with the rules to Google Apps, this will cause workflows and processes to breakdown, and will bring unwanted dissatisfaction from end-users. This could be easily avoided by making sure we document every forwarding rule and contact object on Exchange server.

Make sure AD is structured logically and cleaned up from any unneeded objects, so GADS can be used

It is important to make sure the AD structured cleanly and neat, and all users information are filled and correct (such as telephone numbers, addresses and organization details). This is critical to get GADS to do proper syncs with Google Apps, as GADS will perform AD -> Google Apps sync, it will copy the same structure that we select in AD.

What is the problem here?

Badly configured GADS or a bad OU structure in AD might cause confusion with the IT personnel, which might lead to accidental user suspension or even deletions. AD structure must be checked and confirmed correct and ready in case of GADS to be used.

Check for any transport rules on Exchange server

These rule are important to check so we can replicate them using the proper matching setting with Google Apps. These rules might be related to workflows or processes or some special filtering policies that need to be replicated to Google Apps before shutting down the Exchange server.

I believe this is enough for one post, I’ll follow up with the remaining points in the next one, until then I might add more if I feel more tasks or activities should be watched out for…

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 (you are here)
3. Planning a migration project to Google Apps the right way – Part 2: System survey and data gathering 2/2

Thanks for reading