Skip to main content

Articles in this section

Completing an Exchange/Microsoft 365 to Google Workspace Migration using DMS

On this page, you will find procedures on how to set up an Exchange/M365 to Google Workspace Migration using the Google Data Migration Service (DMS) tool.

The scope for Exchange/M365 migration includes Microsoft Exchange servers that support Exchange Web Services (EWS), specifically Microsoft 365, Exchange 2013, Exchange 2010, or Exchange 2007.

Exchange/M365 migrations are straightforward projects because all email, calendars and contacts can be moved server-to-server with very little point-of-contact (POC) involvement. Whether on-premise or hosted, the requirements and procedures to migrate data to Google Workspace are the same.

For distribution lists (known as Groups in Google Workspace) and aliases, the POC must inventory these and you will need to show the POC how to recreate them manually in Google Workspace before the DNS cutover.

About Account Impersonation

For Exchange/M365 migrations, you only need the POC’s password to test the Exchange environment during setup. Remember, you are not allowed to see any passwords. Instead, the POC must type the password through a screen sharing session. 

The POC does not need to know the passwords for the accounts being migrated because they can up set account impersonation, which allows a single user account to connect to any inbox in their organization You are not responsible for executing the impersonation steps because carrying out configurations in a customer’s source system is not allowed. However, you are required to know the steps involved in account impersonation so you can provide the POC with the necessary guidance.

Testing the Connection to the Source System

Since DMS can only handle one data type at a time, you’ll need to create three different migration projects to run one at a time (i.e one for email, one for calendars, one for contacts).

Before starting the Exchange migration, you’ll need to test that you can connect to the source system for each data type before starting the migration. To do that, the POC must have configured account impersonation and you’ll need to configure three separate test migrations by starting with calendars, and then contacts, and finally email because email has the longest wait time. Once the connectivity is tested, you’ll need to complete a partial migration because this helps us with performance benchmarking so we can estimate how long a migration may take based on the connection to the source server. Some providers could be quick, while others may throttle connections.

Setting Expectations with the POC

To set expectations with the POC and to help them understand the various steps in a migration project, you can send them the Migration Overview email (use the Common Email Responses::Google Workspace Migration::Migration Overview Email macro). You can also send them the help articles on how to create account aliases, groups, etc. so that they can follow the steps on their own time.

Setting Up the Data Migration Service (DMS) Tools for an Exchange/Microsoft 365 to Google Workspace Migration

  1. Confirm where you can migrate from. Refer to the Check where you can migrate from article from Google. 

  2. Make sure the POC's new Google Workspace domain is ready for the migrated data. Refer to the Set up the new Google Workspace domain article from Google.
  3. Create a TLS certificate on the source environment. Refer to the Set up TLS certificate article from Google.

  4. Prepare the source environment. Refer to the Prepare your legacy environment article from Google.

  5. Set up the migration in DMS to migrate email, contacts and calendars to Google Workspace. Refer to the Migrate data article from Google.
    • Complete a connectivity test.
      • Ask the POC to identify five accounts to test calendar connectivity, then contact connectivity and finally email connectivity in this order because email has the longest wait time.
    • Complete a partial migration benchmark
      • For migrations of 5 users or more, complete a partial migration benchmark by having the POC identify 5 accounts which they believe are large inboxes. A partial migration helps to estimate the time a full migration can take.
      • Plan a follow-up call with the POC to monitor the ongoing migration project.
        • If there are issues during the partial migration, resolve the issues and establish another callback in 24 hours.
        • If the partial migration is successful, configure the remaining accounts in DMS and establish a callback based on the following formula: total number of seats ÷ 5 = callback time in hours. For example, if you’re migrating 15 seats, you’ll call the POC back in 3 hours.

  6. Once the migration is set up, monitor its status in the Google Admin Console. Refer to the Monitor a migration article from Google.
  7. Complete the DNS cutover.
    • In order for mail to be routed correctly to the new target platform, changes must be made on the domain name host. These changes will announce to the world that mail for the customer domain must now be sent to the new system and not the old. This is accomplished by modifying the MX (Mail Exchange) records on the domain name host. Refer to the Google Workspace MX records values article from Google.
    • Once these changes are applied, a short period of time (no longer than 24 hours) is required in order for all servers on the planet to be informed of the change. During this propagation period, it is possible that email sent to the customer domain will be routed to either the old or new server. Once all servers are updated worldwide, you should expect that all mail is relayed to the new server. You can use online tools to monitor and track the status of domain name changes. 

  8. Complete the final sync to ensure that all accounts in Google Workspace have the latest email, contacts and calendars from the source environment. Refer to the Pause, cancel, or exit a migration article from Google.

Comments

0 comments

Article is closed for comments.

Related articles