Google Office 365

Posted on 01-05-2021 by admin

Google Office 365 Student Login
Google Office 365 Free Download
Google Office 365 Outlook Login

-->

You can migrate batches of users from Google Workspace to Microsoft 365 or Office 365, allowing a migration project to be done in stages. This migration requires that you provision all of your users who will be migrated as mail-enabled users outside of the migration process. You must specify a list of users to migrate for each batch.

All of the procedures in this article assume that your Microsoft 365 or Office 365 domain has already been verified and your TXT records have been set up. For more information, see Set up your domain (host-specific instructions).

Note

Google Workspace migration is not currently available for Office 365 US Government GCC High or DoD.

Make sure you can access your contacts everywhere by adding new contacts in Office 365 to FullContact, Google Contacts, and other apps. Organize all your to-dos in one place by adding new Office 365 events in Trello, Todoist, or other project management apps. Collaborate for free with online versions of Microsoft Word, PowerPoint, Excel, and OneNote. Save documents, spreadsheets, and presentations online, in OneDrive. Share them with others and work together at the same time. Switch to SharePoint in Microsoft 365 from Google Sites and start working together with these quick instructions on how to access, upload, and share the content, information, and apps your team relies on with SharePoint in Microsoft 365.

Overview of the process

Before beginning your migration, review the following diagrams to understand how a Google Workspace staged migration works. The diagrams show how a fictitious company named Fabrikam, Inc., with the domain name fabrikaminc.net performed their migration.

Prior to their migration, the MX record for the base 'fabrikaminc.net' domain points to the Google Workspace tenant or mail server were all or most of Fabrikam, Inc.'s users are. Note that users have their primary email addresses at that domain.

The MX record for the primary domain 'fabrikaminc.net' still points to Google Workspace, where all the primary mailboxes reside. To prepare for the migration, new routing domains have been created: the gsuite.fabrikaminc.net domain points to Google Workspace and the o365.fabrikaminc.net domain points to Microsoft 365 or Office 365.

On the Google Workspace side, aliases have been added for all of the users in the Google Workspace routing domain. On the Microsoft 365 or Office 365 side, MailUsers have been provisioned for all of the users from the Google Workspace tenant. The ExternalEmailAddress field for MailUsers on the Microsoft 365 or Office 365 side were configured to point back to the primary mailbox using the address at the routing domain for the Google Workspace side. Additionally, there should be aliases for the user in the Microsoft 365 or Office 365 routing domain.

The green arrow indicates how, at this point in the migration, User 2 still contacts User 1 through their Google Workspace email addresses.

User 1 and User 2 are part of the first migration batch to Microsoft 365 or Office 365, while User 3 and User 4 will be part of a later batch. The MX record for the primary domain 'fabrikaminc.net' still points to Google Workspace, where all the primary mailboxes still reside. Because User 1 and User 2 have had their migrations started, they've been converted from MailUsers to Mailboxes on the Microsoft 365 or Office 365 side.

The ExternalEmailAddress for each user has been moved to a ForwardingSmtpAddress, so that messages sent to User 1 and User 2 will be delivered back to their source mailboxes on the Google Workspace side by rerouting the message back to the Google Workspace routing domain. This is indicated by the red arrows in the above diagram. Mail is still being synced from the source Google Workspace side to the Microsoft 365 or Office 365 side.

The MX record for the primary domain 'fabrikaminc.net' still points to Google Workspace. Now that User 1 and User 2 have been fully migrated to Microsoft 365 or Office 365, they should start working out of Microsoft 365 or Office 365. On the Google Workspace side, automatic mail forwarding has been set up for migrated users, so that new emails sent to their Google Workspace address will be delivered instead to the Microsoft 365 or Office 365 address via the routing domain. This is shown by the green arrows in the above diagram.

Important

If your organization has disabled a user's ability to set a forwarding address, the Google Workspace migration tool will also be unable to set the forwarding address. You must enable permissions to set SMTP forwarding in order for forwarding to be set successfully during your migration.

Meanwhile, the forwarding address has been removed from the Microsoft 365 or Office 365 user object, so emails will be delivered to that user in the Microsoft 365 or Office 365 routing domain (as shown by the red arrows above).

After all migration batches have been completed, all users can use their migrated mailboxes on Microsoft 365 or Office 365 as their primary mailbox. A manual MX record update for the primary domain 'fabrikaminc.net' then points to the Microsoft 365 or Office 365 organization instead of the Google Workspace tenant. The routing domains and extra aliases can now be removed, as can the Google Workspace tenant. The migration of mail, calendar, and contacts from Google Workspace to Microsoft 365 or Office 365 is now complete.

Migration limitations

Note

The largest single email message that can be migrated is based on the transport configuration for your configuration. The default limit is 35 MB. To increase this limit, see Office 365 now supports larger email messages.

Throughput limitations for contacts and calendars completely depend on the quota restrictions for your tenant's service account on the Google Workspace side.

Other migration limitations are described in the following table:

Data type	Limitations
Mail	Vacation settings, Automatic reply settings, Filters/Rules will not be migrated
Meeting rooms	Room bookings will not be migrated
Calendar	Shared calendars, cloud attachments, Google Hangout links, and event colors will not be migrated
Contacts	A maximum of three email addresses per contact are migrated over
Contacts	Gmail tags, contact URLs, and custom tags will not be migrated

Tip

If you will be starting your migration batch with Exchange Online Powershell, as described later in this article, you can use the -ExcludeFolder parameter to prevent certain folders from being migrated. This will reduce the amount of data in your migration, as well as the size of a user's new Exchange Online mailbox. You can identify folders you don't want to migrate by name, and you can also identify Gmail labels that apply to multiple messages in order to exclude those messages from the migration. For more information on using -ExcludeFolder, see New-MigrationBatch.

Create a Google Service Account

Important

Use Chrome to create your Google Service account. Other browsers may not allow you to do this properly.
Because elements of the Google Workspace user interface can change over time, the screens you see might vary from the examples in this section. The locations of certain fields may vary as well. Please look at Google's Documentation for how to Create a Service Account for clarifications in case the UI has changed significantly.

In Chrome, go to the Google Cloud Platform and sign in as a Google user (such as the Google Workspace admin).
Click Create to create and name a new project for the onboarding (such as 'Google Workspace project'), or click Select to select an existing project.
Navigate to IAM & Admin > Service Accounts > Select Project and then click Create Service Account and, in Service account name, give the service account a name, such as 'Google Workspace Onboarding.' Click Create.
On the Service account permissions (optional) screen, click Continue.
On the Grant users access to this service account (optional) screen, click Done.
Once you have been returned to the page listing the service accounts, click on the Email for the Service Account you just created to enter the details page, then click the Edit button. Alternatively, you can click the ellipsis under the Actions column and select the Edit action.
On the Service account details page, note the Unique ID. This is the ClientId that you will provide later in the instructions for Grant access to the service account for your Google tenant.
If you see an area that says Show Domain-Wide Delegation, click to expand that section. Next, enable the checkbox to Enable G Suite Domain-wide Delegation, enter the product name to configure the consent screen, and then click Save at the bottom of the page.
On the Service account details page, click Add Key and select the Create new key option.
Under Key type, make sure JSON is selected, and then click Create.
Keep track of the JSON key file that is automatically downloaded, as you will need its filename during the steps under Create a migration endpoint in Microsoft 365 or Office 365. Close the pop-up dialog and click Save.

Enable API usage in your project

If your project doesn't already have all of the required APIs enabled, you must enable them.

Go to the Developer page for API Library and sign in as the Google user you used above in Create a Google Service Account.
Select the project that you used above.
Search for the following APIs, and then for each one, if necessary, click Enable to enable them for your project:
- Gmail API
- Google Calendar API
- Contacts API

Grant access to the service account for your Google tenant

Go to the Google Workspace Admin page and sign in as Google Workspace admin for your tenant.
Click Security, then click API Controls, and then click Manage Domain Wide Delegation.
Next to the API Clients list, click Add new.
In Client ID, type the ClientId for the service account you created in the Create a Google Service Account section above.
In OAuth Scopes, add the required scopes in comma-separated format, with no spaces in between. For example, https://mail.google.com/,https://www.googleapis.com/auth/calendar,https://www.google.com/m8/feeds/,https://www.googleapis.com/auth/gmail.settings.sharing. If the OAuth Scopes are entered incorrectly, the resulting list won't match and the migration process will fail later, after you start the migration batch.
Click Authorize. Verify that the resulting list shows the expected four (4) OAuth scopes.
Note
It may take a substantial length of time for these settings to propagate (anywhere from 15 minutes to 24 hours).

Create a subdomain for mail routing to Microsoft 365 or Office 365

Go to the Google Workspace Admin page and sign in as a Google Workspace admin for your tenant.
Click Domains, then Manage domains, and then click Add a domain.
Note
The option Add a domain will not be available if using the legacy free edition of G Suite.
Enter the domain that you will use for routing mails to Microsoft 365 or Office 365, then click Continue and verify domain ownership. A subdomain of your primary domain is recommended (such as 'o365.fabrikaminc.net' when 'fabrikaminc.net' is your primary domain) so that it will be automatically verified. Keep track of the name of the domain you enter because you will need it for the following steps, and later in the instructions as the Target Delivery Domain when you Create a migration batch in Microsoft 365 or Office 365.
Note
A sub-domain of your primary domain is recommended. If another domain (such as 'fabrikaminc.onmicrosoft.com') is set, Google will send emails to each individual address with a link to verify the permission to route mail. Migration won't complete until the verification is completed.
Follow any subsequent steps that are then required to verify your domain, making sure that the status is shown as Active. If you chose a subdomain of your primary domain in step 3 above, your new domain may have been verified automatically.
Log into your DNS provider and update your DNS records so that you have an MX record at the domain you created above in step 3, pointing to Microsoft 365 or Office 365. Ensure that this domain that you created above is an accepted domain in Microsoft 365 or Office 365. Follow the instructions in Add a domain to Microsoft 365 to add the Microsoft 365 or Office 365 routing domain ('o365.fabrikaminc.net') to your organization and to configure DNS to route mail to Microsoft 365 or Office 365.

Note

The migration process won't be able to complete if a routing domain is used that is not verified as described above. Choosing the built-in 'tenantname.onmicrosoft.com' domain for routing mail to Office 365 instead of a sub-domain of the primary Google Workspace domain occasionally causes issues that Microsoft is not able to assist with besides to recommend that the user manually verify the forwarding address or contact Google support.

Create a subdomain for mail routing to your Google Workspace domain

Go to the Google Workspace Admin page and sign in as a Google Workspace admin for your tenant.
Click Domains, then Manage domains, and then click Add a domain alias.
Enter the domain that you will use for routing mails to Google Workspace, then click Continue and verify domain ownership. A subdomain of your primary domain is recommended (such as 'gsuite.fabrikaminc.net' when 'fabrikaminc.net' is your primary domain) so that it will be automatically verified.
Follow any subsequent steps that are then required to verify your domain, making sure that the status is shown as Active. If you chose a subdomain of your primary domain in step 3 above, your new domain may have been verified automatically.
Follow Google's instructions to Set up MX records for Google Workspace Gmail for this domain.
Note
It may take up to 24 hours for Google to propagate this setting to all of the users in your organization.
Important
If you are using non-default Transport settings in your Microsoft 365 or Office 365 organization, you should check that mail flow will work from Office 365 to Google Workspace. Be sure that either your default Remote Domain ('*') has Automatic Forwarding enabled, or that there is a new Remote Domain for your Google Workspace routing domain (e.g. 'gsuite.fabrikaminc.net') that has Automatic Forwarding enabled.

Provision users in Microsoft 365 or Office 365

Once your Google Workspace environment has been properly configured, you can complete your migration in the Exchange admin center or through the Exchange Online PowerShell.

Before proceeding with either method, make sure that Mail Users have been provisioned for every user in the organization who will be migrated (either now or eventually). If any users aren't provisioned, provision them using the instructions in Manage mail users.

For more advanced scenarios, you may be able to deploy Azure Active Directory (Azure AD) Connect to provision your Mail Users. See Deploy Microsoft 365 Directory Synchronization in Microsoft Azure for an overview, and Set up directory synchronization for Microsoft 365 for setup instructions. Then, you need to deploy an Exchange server in your on-premises environment for user management, and mail-enable your users using this server. For more information, see How and when to decommission your on-premises Exchange servers in a hybrid deployment and Manage mail users. Once the Mail Users have been created in Microsoft 365, the Azure AD Connect may need to be disabled in order to allow the migration process to convert these users into mailboxes - see Turn off directory synchronization for Microsoft 365.

We recommend that the primary address (sometimes referred to as the 'User ID') for each user be at the primary domain (such as 'will@fabrikaminc.net'). Typically, this means that the primary email address should match between Microsoft 365 or Office 365 and Google Workspace. If any user is provisioned with a different domain for their primary address, then that user should at least have a proxy address at the primary domain. Each user should have their ExternalEmailAddress point to the user in their Google Workspace routing domain ('will@gsuite.fabrikaminc.net'). The users should also have a proxy address that will be used for routing to their Microsoft 365 or Office 365 routing domain (such as 'will@o365.fabrikaminc.net').

Note

We recommend that the Default MRM Policy and Archive policies be disabled for these users until after their migration has been completed. When such features remain enabled during migration, there is a chance that some messages will end up being considered 'missing' during the content verification process.

Start a Google Workspace migration batch with the new Exchange admin center (New EAC)

Important

Microsoft’s data migration tool is currently unaware of tools enforcing messaging records management (MRM) or archival policies. Because of this, any messages that are deleted or moved to archive by these policies will result in the migration process flagging these items as 'missing'. The result is perceived data loss rather than actual data loss, which makes it much harder to identify actual data loss during any content verification checks.
Therefore, Microsoft strongly recommends disabling all MRM and archival policies before attempting any data migration to mailboxes.

In the new Exchange Admin center, navigate to Migration > Batch.
Click New Migration batch and follow the instructions in the details pane.
In Migration Onboarding section, enter the batch name, select the mailbox migration path and click Next.
Select the migration type as G Suite (Gmail) migration from the drop-down list and click Next.
In G Suite migration prerequisites section, manually configure G-Suite for migration.
In Set endpoint section, select the migration endpoint from the drop-down list and click Next.
Note
To migrate Gmail mailboxes successfully, Microsoft 365 or Office 365 needs to connect and communicate with Gmail. To do this, Microsoft 365 or Office 365 uses a migration endpoint. Migration endpoint is a technical term that describes the settings that are used to create the connection so you can migrate the mailboxes.
Create a CSV file containing the set of all of the users you want to migrate. You will need its filename below. The allowed headers are:
- EmailAddress (required). Contains the primary email address for an existing Microsoft 365 or Office 365 mailbox.
- Username (optional). Contains the Gmail primary email address, if it differs from EmailAddress.
In Add user mailboxes section, import the CSV file and click Next.
In Move configuration section, enter the details and click Next.
In Schedule batch migration section, verify all the details, click Save, and then click Done.
Once the batch status changes from Syncing to Synced, you need to complete the batch.
Note
When the batch starts, all the users to be migrated will be converted from MailUsers to Mailboxes. The Microsoft 365 or Office 365 Exchange license must be assigned only after this moment. You have 30 days to assign the license.
To complete the batch, select the migration group.
In the details pane, select the preferred option to complete the batch and click Save.
The batch status will then be Completed.

During completion, another incremental sync is run to copy any changes that have been made to the Google Workspace mailbox. Additionally, during completion, the forwarding address that routes mail from Microsoft 365 or Office 365 to Google Workspace is removed, and a forwarding address that routes mail from Google Workspace to Microsoft 365 or Office 365 is added. This ensures that any messages received by migrated users at their Google Workspace mailboxes will be sent to their new Microsoft 365 or Office 365 address. Similarly, if any user who has not yet been migrated receives a message at their Microsoft 365 or Office 365 address, the message will get routed to their Google Workspace mailbox.

Start a Google Workspace migration batch with the Classic Exchange admin center (Classic EAC)

In the Exchange Admin center, click recipients, and then click migration.
Click 'New' to create a new migration batch, and then click Migrate to Exchange Online.
In the New Migration Batch window, select G Suite (Gmail) migration, and then click Next.
Create a CSV file containing the set of all of the users you want to migrate. You will need its filename below. The allowed headers are:
- EmailAddress (required). Contains the primary email address for an existing Microsoft 365 or Office 365 mailbox.
- Username (optional). Contains the Gmail primary email address, if it differs from EmailAddress.
Under Select the users, click Choose File and navigate to the CSV file of all the users you are migrating in this batch. If your CSV file contains more columns besides the two mentioned above, click to select Allow unknown columns in the CSV file.
After selecting the CSV file, click Open. Back on the new migration batch page, click Next.
Enter the email address for the super admin within the Google Workspace environment. This is not the service account you just created, it should be the email address of the Google Workspace admin. This email address will be used to test connectivity between Google Workspace and Microsoft 365 or Office 365.
Under Specify the service account credentials using the JSON key file, click Choose File, and then select the JSON file that was downloaded automatically when you created your service account. This file contains the private key for the service account. Click Open to select the file, and then, back on the new migration batch page, click Next.
Note
Click to select Skip verification if you don't want to verify the migration endpoint.
In the fields under Move configuration, name your migration batch, and enter the target delivery domain, which is the domain you created for routing mail to the Microsoft 365 or Office 365 target organization from the Google Workspace source organization. Optionally, you can also specify any folders that should be excluded from the migration. R play remote play for ps4 windows 10. When done, click Next.
Note
The target delivery domain you will want to use will not automatically show up in the dropdown - instead you should click within the text box and type it in. The target delivery domain must be different from the primary domain of the users in Google Workspace.
Under Start the batch, fill in the names or aliases of anyone who should be notified about the batch progress. Then select how you want to begin and complete the batch. Lg motherboards driver download. When done, click new.
After the batch status changes from Syncing to Synced, you need to complete the batch. The batch status will then be Completed.
Note
When the batch starts, all the users to be migrated will be converted from MailUsers to Mailboxes. The Microsoft 365 or Office 365 Exchange license must be assigned only after this moment. You have 30 days to assign the license.

Start a Google Workspace migration with Exchange Online PowerShell

Create a migration endpoint in Microsoft 365 or Office 365

Connect to Exchange Online PowerShell.
Find the email address for the super admin within the Google Workspace environment. This email address will be used to test connectivity between Google Workspace and Microsoft 365 or Office 365. The following steps use 'admin123' as an example.
Run the following command:
Verify the test is successful.
If successful, run the following command:

Create a migration batch in Microsoft 365 or Office 365

Connect to Exchange Online PowerShell.
Create a CSV file containing the set of all of the users you want to migrate. You will need its filename below. The allowed headers are:
- EmailAddress (required). Contains the primary email address for an existing Microsoft 365 or Office 365 mailbox.
- Username (optional). Contains the Gmail primary email address, if it differs from EmailAddress.
Run the following command:
Tip
See New-MigrationBatch for an explanation of all of the individual parameters you can use with this cmdlet.
Start the migration batch.
Note
When the batch starts, all the users to be migrated will be converted from MailUsers to Mailboxes. The Microsoft 365 or Office 365 Exchange license must be assigned only after this moment. You have 30 days to assign the license.

Complete the migration batch in Microsoft 365 or Office 365

When the migration batch has reached the state of Synced, it needs to be completed by running the Complete-MigrationBatch cmdlet.

During completion, another incremental sync is run to copy any changes that have been made to the Google Workspace mailbox. Additionally, the forwarding address that routes mail from Office 365 to Google Workspace is removed, and a forwarding address that routes mail from Google Workspace to Office 365 is added.

Note

Forwarding addresses are not needed when doing a cutover migration from Google Workspace to Exchange Online.

Finalizing your migration

After you have successfully migrated all of your Google Workspace users to Microsoft 365 or Office 365, you can switch your primary MX record to point to Microsoft 365 or Office 365. The update to the MX record will propagate slowly, taking up to the length of time in the record's previous TTL (time to live). At this point, you are free to decommission your source Google Workspace tenant.

For over a decade, Google has tried to win over Microsoft Office users. The one advantage the Google G Suite of productivity apps once had over Microsoft Office was simpler file sharing and better real-time collaboration on documents. By storing Google Documents in the cloud-based Google Drive, users could in one click share the document with anyone inside or outside an organization. Called “co-authoring,” this enabled or more people to edit the shared document in real time.

However, the co-authoring advantage didn’t last long for Google as Microsoft quickly added similar functionality to its cloud-based Office 365 suite to close the gap. The most recent cloud storage and collaboration features added by Microsoft make a compelling case for Google G Suite users to switch to Office 365. They’re confident enough to offer companies using Google (and Box or Dropbox cloud storage) free access to Microsoft OneDrive for Business for the remainder of their contracts with the other file-sharing providers—essentially buying them out from competitors. But should your company make such a move?

At Amaxra, we’ve worked with both Google G Suite and Microsoft Office 365 to best understand the pros and cons of each. We’ve also heard how numerous business customers—from startups to enterprises—have gone from Office 365 to G Suite (and often back again). With the latest updates, we believe users of Google G Suite should move to Microsoft Office 365 for three big reasons:

Office 365 has a better price-performance ratio than G Suite

Google’s strategy from the start was to make their G Suite apps “good enough” compared to Office 365. Because their primary business model is to serve advertising on Internet searches, Google could offer their G Suite apps for a couple of dollars per month less than Microsoft Office 365. By undercutting Microsoft on price and offering the flashy co-authoring feature, Google was able to convince some budget-conscious companies to switch. However, these companies quickly learned the lower price didn’t equate to the superior performance of Microsoft Office apps.

An IT professional at a midsize networking software company relayed to me how they were sold on Google G Suite for no other reason than it was $2 cheaper per month than Office 365. Her company was at the end of their onsite licensing agreement for Microsoft Office and wanted to move to the cloud. Google showed the company how paying $2 per month less across almost 500 seats meant tens of thousands in savings over a typical Office 365 contract. However, the IT pro notes that $2 per seat savings was quickly exceeded by the labor, consulting fees, and value-add services to migrate Microsoft Outlook email to Gmail and moving files stored in highly-structured and centralized Microsoft SharePoint folders to unstructured personal Google Drive storage accounts. In addition, she noted the company had to buy Microsoft Office licenses for their finance department (who revolted against a mandate forcing the usage of Google Sheets) and employees in key customer-facing roles who objectively noted the Google alternatives to Microsoft Excel, Outlook, and PowerPoint were nowhere near feature parity.

OneDrive + SharePoint is centralized with “in-place” file recovery

We have written about the many benefits of Microsoft SharePoint and OneDrive For Business cloud storage in previous blogs. In Office 365, every user by default receives their own personal allotment of OneDrive For Business cloud storage. For secure structured storage of files for teams, there’s SharePoint. But in Google G Suite, users are given their personal Google Drive storage and there’s no analogue to SharePoint. Although it is simple to share and collaborate on files in Google Drive, the lack of structured file storage often causes problems with team file ownership.

An example of this was when a marketing professional told me how he attempted to organize a folder on his Google Drive for his team. He then shared the folder with his team as their “Marketing Drive,” given each member edit permissions for their own subfolders. For over a year, the marketing team had moved files onto the Google Drive because it was the only way to have a collaborative space for the team. In an attempt to clean up what appeared to be redundant files in his personal Google Drive, the marketing professional accidentally deleted numerous business-critical files used by his team. Adding insult to injury, restoring users’ lost files on the old shared “Marketing Drive” folder required each individual to go through a convoluted recovery process. Due to the design of Google Drive’s file permission architecture, the company’s IT department could not perform an in-place recovery so that the files and folders were restored to their original locations.

In Office 365, this team would’ve used a SharePoint portal site for their structured file storage—which has cloud-based, enterprise-grade redundancy to protect against file removal. And in the event that the employee’s personal account’s OneDrive For Business was used for team file storage, Microsoft offers a superior in-place file recovery solution with Files Restore. Unlike the limited restore features in Google Drive, the Microsoft Files Restore solution is self-service recovery for files compromised due to accidental deletion, file corruption, or malware infection.

Office 365 works perfectly well on Mac and iOS devices

Companies with investments in Apple hardware such as MacBooks, iPads, and iPhones often claim that Google G Suite apps work better on the Apple platform than Office 365 apps for macOS and iOS. However, starting in 2017 there were steady feature updates to the Mac and iOS versions of Office 365 from Microsoft to enhance how teams create content on the platform. For example, the latest updates from Microsoft to the Office 365 apps for Mac and iOS enabled online document co-authoring, autosaving for files stored in OneDrive and SharePoint, improved search in Outlook, and the ability to drag-and-drop content or files in the native iOS apps for Office 365.

While these features were already available for Office 365 users on Windows PCs and (ironically) Google Android mobile devices, they were all features that Mac and iOS users requested or required before looking at switching from G Suite. The Mac user holdouts have lost their key excuses not to switch.