Migrating Google Workspace to Microsoft 365: a guide

How to translate collaboration from Google Workspace to Microsoft 365

Migrating from Google Workspace to Microsoft 365 requires deciding where each type of information should reside. Personal content and departmental shared documents should not necessarily be assigned the same destination by default. Ownership, collaboration requirements, and future maintenance needs must be reviewed before assigning data to OneDrive, SharePoint, or the appropriate workspace.

For example, consider a shared drive containing business proposals managed by multiple individuals. Moving everything to an individual employee’s personal account could create a dependency that did not exist under the departmental model. A designated lead must approve a destination that includes the correct owners and groups. The migration tool should then be configured according to this decision, rather than relying on default settings to dictate the organizational structure.

Documents also require functional testing. A spreadsheet with formulas, a linked file, or an automated process may behave differently outside its original environment. The pilot phase should include the formats and processes the company deems critical, documenting whether they remain functional, require adaptation, or need an entirely different solution. Simply converting a file does not guarantee functional equivalence.

How to coordinate email, calendars, and identity during the transition

Preparing users involves more than just setting up their destination mailboxes. It requires reviewing email addresses, groups, shared calendars, and any applications that use the account for sign-in purposes. The identity map must ensure that users and their permissions are correctly aligned, preventing the creation of duplicate accounts if data already exists within the Microsoft 365 tenant.

The pilot should cover standard email and calendar workflows: sending and replying to messages, searching for emails, opening attachments, and attending meetings. Additionally, access should be verified across the intended devices and through relevant business applications. These tests identify supporting tasks that must be included in the change window, and they prevent the project from being marked as complete before users are actually able to work.

What migrating from Google Workspace to Microsoft 365 really entails

A full-scale migration can affect multiple platforms simultaneously. First, there is email: Gmail, Google Calendar, and Google Contacts must be transitioned into Exchange Online mailboxes, which users will then access via Outlook and Outlook on the web. Then, there is document-based information: data stored in Google Drive must be distributed across OneDrive and SharePoint, based on ownership and usage.

There is also an identity layer. Google Workspace users must have a corresponding identity within Microsoft Entra ID, complete with their respective groups, domains, licenses, and security controls. Finally, there is collaboration: Google Chat, Meet, Shared Drives, and other work mechanisms must be adapted to the new way of working using Teams, SharePoint, OneDrive, and Microsoft 365.

When it makes sense to migrate from Google Workspace to Microsoft 365

There is no universal reason why Microsoft 365 is always better than Google Workspace. Both platforms are mature, and each can be a suitable fit for different organizations. Migration often makes sense when there is a specific need for standardization or integration. Intensive use of Microsoft Office. Companies that work extensively with Word, Excel, PowerPoint, and Outlook may prefer to have their email, files, and collaboration tools all within the same ecosystem.

Adoption of Microsoft Teams. Teams can become the central hub for meetings, chats, channels, documents, and Microsoft 365 applications. However, to leverage it effectively, it is also necessary to organize SharePoint, OneDrive, permissions, and identity. Technological consolidation. In business groups where the corporate platform is Microsoft 365, maintaining a subsidiary on Google Workspace can lead to redundant administration, separate identities, and disparate tools.

Mergers and acquisitions. When an acquired company uses Google Workspace and the parent company uses Microsoft 365, migration can be part of the business integration process. Identity and security. Some organizations seek to centralize authentication, applications, devices, and access controls around Microsoft Entra ID and the broader Microsoft platform.

What can be migrated from Google Workspace

Not all components use the same tool or offer the same level of fidelity.

What Microsoft currently offers for migrating from Google

Microsoft has significantly expanded its own suite of tools and now offers a migration experience from Google Workspace to Microsoft 365 that encompasses various workloads. It is important to distinguish between the two primary ones. Email: Exchange Online Migration. For Gmail, Microsoft provides a specific migration path to Exchange Online that can handle email, calendar, contacts, and rules. Additionally, there are separate procedures for permissions, delegations, rooms, resources, and tasks.

Files: Migration Manager

For Google Drive, Microsoft uses Migration Manager, integrated into Microsoft 365. Migration Manager allows you to:

Official reference: Microsoft – Migrate Google Workspace to Microsoft 365 with Migration Manager.

Assessment: understanding Google before building out Microsoft 365

The biggest mistake would be to set up the destination tenant based on assumptions. First, we need to know what actually exists in Google.

Volume is not the only factor.

A user with 200 GB in Drive might be easy to migrate if the data is personal and has limited permissions. A 20 GB Shared Drive, however, may require much more analysis if it involves hundreds of users, external access, and documentation used by various departments.

Users and Microsoft Entra ID

Data should not be migrated until it is clearly established who will own it in Microsoft 365. The target identities determine email, SharePoint and OneDrive permissions, and the overall user experience. UPN and email address. A user can retain an identity such as: ana.garcia@empresa.com However, that address must already exist and be properly configured in Microsoft 365 before other workloads can correctly associate with it.

Users who should not be migrated. It is also common to discover the following during the assessment: old accounts, suspended users, service accounts, test users, and mailboxes that no longer have a valid owner. Not all of these should automatically be converted into a Microsoft 365 license.

Google Identity Sync: a new capability worth knowing about

Microsoft currently provides Google Identity Sync—a feature designed to facilitate the preparation of users and groups before migrating the remaining workloads. The synchronization is unidirectional, from Google Workspace to Microsoft 365.. Current availability. Microsoft currently documents Google Identity Sync for tenants with fewer than 300 licensed users.For larger organizations, the status of this feature should be verified at the time of the project; if it is not yet available, an alternative provisioning method must be used.

How it handles users.

It is not a destructive synchronization. If a user is subsequently deleted in Google, Google Identity Sync does not automatically delete the corresponding user in Microsoft Entra ID. This reduces the risk of using synchronization as a mechanism for unintended deletions, but it means that the end-of-life stage of the user lifecycle must be managed deliberately. Official reference: Microsoft – Google Identity Sync.

Google Groups: not all should be converted into the same type of group

A Google Group can be used for various purposes. Therefore, migrating just the name and the members is not always sufficient.

Google Identity Sync and groups. Within its current scope, Google Identity Sync can synchronize Google Groups and create Microsoft 365 Groups for compatible groups. While this may reduce the workload in smaller-scale scenarios, it does not mean that every Google Group should be functionally transformed into a Microsoft 365 Group. During the design phase, we continue to recommend reviewing the actual purpose for which each group is used.

Migrating from Gmail to Exchange Online

For businesses, we do not recommend treating Gmail simply as an IMAP server when there are specialized tools available that can retrieve more comprehensive information. Microsoft currently offers a dedicated migration path from Google Workspace via Exchange Online. What the primary procedure can migrate.

Furthermore, Microsoft now provides specific procedures for other components, such as delegations, permissions, rooms, resources, and tasks. Why it is preferable to IMAP for enterprise Google Workspace environments. IMAP only provides access to messages and folders. A migration process designed specifically for Google Workspace can also access calendars and contacts, and offers better handling of features unique to Gmail. Official reference: Microsoft – Automated Google Workspace Migration.

Simplified Gmail Migration and larger-scale projects

Microsoft offers different migration experiences depending on the size of the Google environment. Simplified Gmail Migration. Current Microsoft documentation defines Simplified Gmail Migration (SGM) for Google Workspace environments with up to 1,000 source mailboxes. This experience allows you to discover mailboxes and select: which users to migrate, the time range of data to transfer, the types of data, and the specific labels or folders to include.

Large mailboxes. The process also distinguishes between standard-sized mailboxes and large mailboxes; therefore, the data volume should be determined before starting the project. More than 1,000 users. Microsoft directs larger environments toward its migration experience designed for large-scale Google tenants. This illustrates why it is unwise to define an architecture simply by stating, “we will use the native tool.” Even within the Microsoft ecosystem, there are different workflows.

Official reference: Microsoft – Simplified Gmail Migration.

Gmail labels vs. Outlook folders

This is one of the functional differences that is most important to explain to users. Gmail uses labels. A single message can be associated with multiple labels simultaneously, without requiring multiple physical copies of that message. Outlook and Exchange, by contrast, primarily use a folder-based structure. Consequently, a Gmail structure such as: Cliente A + Factura + Pendiente does not necessarily translate perfectly into three distinct Exchange folders.

Implications for the migration. Depending on the method used, labels may be converted into folders or handled according to the specific rules of the migration tool. During the pilot phase, it is advisable to select users who make intensive use of labels and verify: what structure they will end up with in Outlook, and whether the result is intuitive for them.

Gmail elements that require special attention

Even when using Microsoft’s dedicated migration solution, there are fundamental platform differences to consider.

Message size. Microsoft currently documents a default limit of 35 MB per message for migrations from Google, which can be configured up to 150 MB. This type of limit should be reviewed before each project, as it is subject to change. Contacts with multiple addresses. Current documentation specifies a maximum of three email addresses that can be migrated per contact using the relevant procedure. Official reference: Microsoft – Google Workspace automated batch migration overview.

Migrating from Google Calendar to Exchange Online

The calendar is a critical component; an issue here does not just affect historical data—it can also impact future meetings. What we should test.

Future meetings and platform changes. We must also distinguish between the calendar and the platform used for the meeting. An appointment might migrate successfully to Outlook while still containing a Google Meet link. The decision on whether future meetings should be kept, recreated, or modified will depend on the collaboration strategy and the acceptable level of impact.

Permissions, delegates, rooms, resources, and tasks

Microsoft has expanded its Google Workspace migration capabilities, providing specific procedures for items that previously might have required a much more manual reconstruction process. Current documentation covers:

This does not mean we should assume perfect equivalence. These are precisely the elements that should be prioritized for testing during the pilot phase, as they may involve rules, behaviors, or permissions that differ between Google and Exchange. Official reference: Microsoft – Permissions, Delegates, Rooms, Resources, and Tasks Migration.

Migrating Google Contacts

Contacts may seem less important than email—until a business user opens Outlook on a Monday and discovers that none of their regular clients are there. That is why they must be included in testing. What to review.

Migrating Google Drive to Microsoft 365

Document migration should be designed separately from the Gmail migration. Microsoft currently uses Migration Manager to move content from Google Drive to OneDrive and SharePoint. The process is not a simple drag-and-drop. Migration Manager can analyze drives before moving them, generate reports, map identities, and migrate metadata and permissions, provided that appropriate mappings exist. A fundamental difference: the data is copied.

Migration Manager does not delete the original files from Google. During the migration: the content is copied to Microsoft 365 while continuing to exist in Google Drive. This is very useful for reducing risks, but it creates a new operational requirement: deciding at what point users should stop modifying the source content. Official reference: Microsoft – Migrate Google Files to Microsoft 365.

My Drive: OneDrive or SharePoint?

The typical mapping is: My Drive → OneDrive. However, this should not be applied without reviewing the content. A user might have documents in their “My Drive” that are used by their entire department because they were historically shared from that user’s account. If that user leaves the company, such documentation should not remain dependent on their OneDrive.

A migration is a great opportunity to fix content that is currently owned by the wrong person.

Shared Drives: SharePoint is generally the natural equivalent

Shared Drives are organizational by design and, therefore, usually map better to SharePoint. However, a Shared Drive does not necessarily have to become a single SharePoint site. We might need to: group several drives together, split a drive that is too large, or map it to different sites based on departments, projects, or permission requirements. What we analyze beforehand.

How Migration Manager for Google Workspace works

The current Microsoft methodology is particularly useful because it includes an analysis phase before any data is moved. 1. Connect to Google. The relevant migration application is installed and authorized within Google Workspace. 2. Scan & Assessment. Drives are selected and scanned. The goal is to identify any issues prior to execution. 3. Add to migration list.

Drives that are ready are added to the migration project. 4. Review destinations. It is defined which Drive will end up in which OneDrive or SharePoint location. 5. Map identities. Google users, groups, and domains are linked to their corresponding Microsoft objects. This step is essential for correctly preserving permissions. 6. Migrate and monitor. Jobs are executed, followed by a review of reports and errors.

A “Completed” status does not necessarily mean there were no issues at all. Microsoft notes that certain unsupported elements can cause file-level errors while still allowing the overall task to appear as “completed.” For this reason, detailed reports should always be reviewed.

What happens to Google Docs, Sheets, Slides, Forms, and other items

A common concern involves what happens to proprietary Google formats. Migration Manager uses the Google export API to convert the main document types.

Conversion does not guarantee perfect fidelity

A simple Google Sheet is likely easy to convert. However, a sheet containing complex formulas, links, scripts, add-ons, or Google-specific features should be tested manually. The same applies to highly elaborate documents and presentations that include specific, unique components. Official reference: Microsoft – Unsupported Files in Migration Manager.

Google Drive and SharePoint permissions

Migration Manager can migrate permissions, provided that identities are correctly mapped. This is particularly important for Shared Drives. Google Groups. If a Shared Drive uses a Google Group to grant access, an equivalent identity or group must exist in Microsoft 365, and the corresponding mapping must be performed. Do not confuse the migration of permissions with the auditing of permissions. Just because we can technically reconstruct a permission does not mean it should be retained.

Before migrating legacy access rights, we recommend reviewing: inactive users, vendors who no longer work with the company, groups without an owner, and access rights that were granted on a temporary basis years ago.

What happens to shared links and external users

This is a significant limitation that should be communicated prior to the migration. External links. Microsoft currently states that Migration Manager does not automatically recreate external sharing links. New links will need to be set up subsequently in Microsoft 365, wherever they are still required. External collaborators. Migration Manager also does not automatically re-share content with external collaborators. This is a deliberate security decision.

This means the project must include a review of external access:

This can actually be an advantage. Although it adds extra work, it prevents the automatic migration of years’ worth of external links and historical access permissions without first verifying whether they are still valid. Official reference: Microsoft – Migration Manager Google FAQs.

Incremental migrations: what happens if Google keeps changing

Migration Manager allows you to re-run a migration and perform a differential sync. This facilitates a pre-migration model. Example. We can copy a large portion of the content on a Monday, allow users to continue working in Google, and then run another pass before the cutover. In this subsequent run, only new or modified files are primarily processed.

However, do not reorganize the source during the migration.

Microsoft warns of an important consequence: if you rename folders or modify structures during the transition, Migration Manager may interpret these changes as new content, resulting in the creation of duplicates.

Structural cleanup should ideally be performed either before starting the migration or after it has been completed—not while synchronizations are in progress. The original files remain in Google. Consequently, there may be two copies for a period of time. A clear date must be established from which Microsoft 365 becomes the primary working environment, while Google remains in a transition phase or serves solely as a reference until it is decommissioned.

Google Chat and Google Meet vs. Microsoft Teams

This component should be considered separately from Gmail and Drive. Teams is not simply “Microsoft’s version of Google Meet.” It integrates: chat, meetings, teams, channels, applications, SharePoint, OneDrive, and Microsoft 365 Groups.

We do not design migrations based on the assumption of a 1:1 copy.

Google Chat history, spaces, meetings, and related items must be analyzed separately if there is an explicit retention requirement. In many projects, the transition primarily consists of:

The decision regarding whether to migrate historical data, archive it, or start a new phase in Teams must be part of the project scope and should not be assumed.

Corporate domain and DNS

One of the most visible moments during a migration is when email stops arriving in Google and begins to arrive in Exchange Online. The domain can be verified in Microsoft 365 beforehand without immediately changing the email flow. MX. During the cutover, the MX record must direct new messages to Exchange Online once the target environment is ready.

SPF. SPF must reflect Microsoft 365 and any other platforms that continue to legitimately send email using the domain. DKIM. Message signing from Microsoft 365 will be configured for the relevant domains. DMARC. This should be reviewed in conjunction with SPF and DKIM. We do not recommend abruptly tightening a DMARC policy without first validating all legitimate email sources. Autodiscover. After the change, Outlook will use the Exchange Online infrastructure to correctly locate the mailbox.

Applications connected to Google Workspace

A company might successfully migrate Gmail and Drive, yet still face a serious incident because an application relied on Google for authentication. Sign in with Google. Applications that use Google as an Identity Provider may need to be migrated to Microsoft Entra ID, or alternatively, retain Google access on a temporary basis. OAuth and APIs. It is necessary to identify applications using: OAuth, Google APIs, service accounts, domain-wide delegation, or internally developed integrations.

Application-based email. Systems that currently send email via Gmail or Google SMTP may require a different method for Microsoft 365.

Security during the transition

The Microsoft 365 tenant must be prepared before users begin working in a production environment. MFA. Multi-factor authentication (MFA) should be part of the initial design. Furthermore, Microsoft enforces MFA for its administrative tools and portals, so administrative accounts must be configured accordingly. Security Defaults or Conditional Access. The chosen solution will depend on the licensing in place and the level of granularity required.

When using Conditional Access, we recommend piloting policies before applying them broadly. Temporary migration permissions. Applications used to access Google and Microsoft environments may require significant permissions. Such consents must be: documented, restricted whenever possible, and reviewed upon project completion.

Microsoft 365 licensing

The same plan should not be automatically purchased for all users; profiles should be defined first.

Coexistence period. During the transition, there may be a period where the organization continues to pay for Google Workspace licenses while users also already have Microsoft licenses. This temporary cost must be included in the planning.

Native Microsoft tools or a specialized third-party tool?

Native Microsoft tools currently cover a significant portion of a Google Workspace migration. For many projects, they may be sufficient.

When a specialized platform might be beneficial. We may evaluate third-party tools when we need: a different reporting model, more workloads managed from a single console, different coexistence capabilities, handling of elements not covered by Microsoft, or a different operational strategy. Tools that can be evaluated.

The final selection should be made after the assessment and, for critical elements, confirmed during the pilot phase.

Recommended phases for a Google Workspace to Microsoft 365 migration

1. Discovery. We create an inventory of users, Gmail, Calendar, Contacts, Drive, Shared Drives, groups, applications, and domains. 2. Destination design. We define which information will go to Exchange Online, OneDrive, SharePoint, and Teams. 3. Identity. We prepare users, UPNs, groups, and licenses. Once the scenario meets the current requirements, we can evaluate Google Identity Sync. 4. Baseline security. We configure the agreed-upon measures for MFA, administration, and access before onboarding users.

5. Tools. We connect Google and Microsoft, grant permissions, and configure mappings. 6. Technical assessment. We run available scans and analyze potential errors. 7. Pilot. We migrate a representative set of users and Drives. 8. Pre-migration. When the tool allows, we move data in advance. 9. Final synchronization. We process any changes that have occurred since the initial load. 10. Cutover. We update the email routing and establish Microsoft 365 as the working environment.

11. Validation. We verify email, calendar, contacts, documents, and permissions. 12. Hypercare. We address issues related to the transition and finalize the stabilization of the new environment.

What the pilot phase should include

A pilot should seek out problems, not avoid them.

Expected outcome. After the pilot, we should know: Actual speed, errors, limitations, changes for users, and necessary manual tasks.

Cutover: when Microsoft 365 becomes the production environment

The final change must be documented.

Google should not be removed immediately. Even after the MX record change, it may be advisable to temporarily maintain the source environment in a controlled manner while verifying that no data or processes remain pending. The date for final decommissioning should be included in the plan.

How to validate that the migration has been completed successfully

A green screen in the tool is only one part of the validation process.

Migration Manager reports must be reviewed. A job may appear as completed even if it contains individual unsupported files. Therefore, we review errors, exclusions, and items requiring further attention before considering the document migration accepted.

The changes that users will actually see

For the user, the migration is not an API project. It is a transition from:

Training should focus on these differences. In particular: How to log in, how to use Outlook, where to save documents, the difference between OneDrive and SharePoint, how to share files, and how to use Teams. It is not necessary to teach every feature of Microsoft 365 before day one.

Outlook, mobile devices, and other hardware

The cloud migration project and the individual configuration of workstations should be considered separate tasks. After the cutover, some users may need to install Microsoft applications, authenticate in Outlook, or reconfigure mobile apps. Kloudeal We can provide procedures and coordinate with the client’s IT department, but individual, hands-on work on each computer or phone should not be assumed to be included unless it is explicitly stated in the scope..

How long a Google Workspace to Microsoft 365 migration takes

It cannot be accurately calculated based solely on the number of users.

The assessment allows for an initial estimate, and the pilot helps refine it into a more realistic timeline.

Factors that determine the cost of the migration

Two companies, each with 100 users, may have completely different projects.

We do not recommend calculating the project based on a flat rate per user without first considering at least these factors.

Common mistakes when migrating from Google Workspace

Checklist for migrating from Google Workspace to Microsoft 365

Frequently asked questions about migrating from Google Workspace to Microsoft 365

Should all content from Drive be moved to OneDrive?

No. The destination should be determined by the ownership and usage of the information. Personal content and departmental documentation may require different locations and governance policies. Before copying, it is advisable to establish ownership, permissions, and structure—ensuring that information shared by a team does not end up dependent on a single personal account.

Do Google documents retain all their functionality upon conversion?

Compatibility must be tested using the actual documents the company uses. Formulas, links, automations, and other elements may require adjustments. The pilot phase should document any discrepancies and the chosen solutions. The fact that a file can be opened in the destination environment does not guarantee that the processes relying on it will continue to produce the expected results.

What needs to be reviewed in the accounts before migration?

Source and destination users, email addresses, groups, and application access must be mapped. If accounts already exist in Microsoft 365, it must be verified which ones each individual should continue using. This mapping is essential for maintaining the intended permissions and preventing the creation of duplicates that could complicate future access or administration.

When can email reception be switched to Microsoft 365?

Once the recipients are ready, user access is configured, and testing for email flow and domain authentication has been completed. The plan must also define how information that changes during the transition will be captured. The decision should be based on the pilot phase and the list of cutover criteria, rather than solely on the percentage of messages copied.

Final recommendations: migrating from Google Workspace to Microsoft 365 is essentially translating one platform into another

A Migrating from Google Workspace to Microsoft 365 This should not be approached as a simple, automatic product replacement. Gmail and Exchange Online organize email differently. Google Calendar and Exchange share similar concepts, but their behaviors are not always identical. Google Drive and SharePoint utilize different models for ownership and permissions. Furthermore, Google Groups, Chat, Meet, and user identities each require their own specific strategy.

Microsoft’s native tools have evolved significantly. Exchange Online supports the migration of Gmail, calendars, contacts, and rules, and also includes specific procedures for handling delegates, permissions, rooms, resources, and tasks. Migration Manager allows for the analysis of Google Drive prior to the transition, identity mapping, the transfer of permissions, the conversion of Docs, Sheets, and Slides, and the execution of incremental synchronizations. It is also important to be aware of its limitations: external links and collaborators require review; Google Sites and Maps cannot be migrated using this tool; and orphaned files must be identified beforehand.

Google Identity Sync also adds a new capability for provisioning users and groups in Microsoft Entra ID for organizations that meet its current requirements. Therefore, a successful migration begins with designing the target environment. First, we determine what information belongs in Exchange Online, what should go to OneDrive, what should be organized in SharePoint, which groups are required, and how users will work with Teams.

Next, we configure identity and security, conduct discovery and assessment, test the technology through a pilot, carry out any possible pre-migration tasks, and coordinate the cutover. The project concludes when users are able to log in to Microsoft 365, use Outlook, locate their meetings, access their documents, collaborate with their teams, and continue the business processes that are essential to them..

Recommended official documentation

Overview: Google Workspace → Microsoft 365

• Microsoft – Switch from Google Workspace to Microsoft 365 for Business
• Microsoft – Consolidated Google Workspace Migration

Gmail, calendars, and contacts.

• Microsoft – Automated Google Workspace Migration
• Microsoft – Automated Google Workspace Batch Migration Overview
• Microsoft – Google Workspace Migration Prerequisites
• Microsoft – Simplified Gmail Migration

Permissions, delegates, rooms, resources, and tasks.

• Microsoft – Migration of Permissions, Delegates, Rooms, Resources, and Tasks

Google Drive → OneDrive / SharePoint.

• Microsoft – Migrate Google Workspace with Migration Manager
• Microsoft – Migrate Google Files to Microsoft 365
• Microsoft – Migration Manager Google FAQs
• Microsoft – Unsupported Files in Migration Manager

Identity.

• Microsoft – Google Identity Sync
• Microsoft – Microsoft Enter ID

Email and DNS.

• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC