Migrating from Google Workspace to Microsoft 365

Do not start with “BitTitan versus native tooling versus another migration platform.” Start with how the business should operate in Microsoft 365 after the move.

Google Workspace and Microsoft 365 are not identical containers:

• Gmail labels are not the same as Exchange Online folders. A message can have multiple Gmail labels, which can create duplicates or unexpected folder placement depending on the migration method.
• Google Shared Drives are not the same as SharePoint sites. SharePoint information architecture, permissions, sensitivity, retention, and external sharing must be designed.
• Google Groups can function as mailing lists, collaborative inboxes, access control groups, and discussion spaces. In Microsoft 365, those functions may map to distribution groups, shared mailboxes, Microsoft 365 Groups, Teams, or Microsoft Entra ID security groups.
• Google Vault retention and holds do not simply become Microsoft Purview retention policies or eDiscovery holds. Requirements must be preserved, exported, or recreated deliberately.

Build a current-state inventory by business function, not just by object count:

• User mailboxes: active users, suspended users, aliases, delegates, forwarding, send-as/send-on-behalf needs.
• Shared addresses and groups: accounting@, support@, hr@, sales@, project groups, external-facing lists.
• Calendars: user calendars, resource rooms, equipment calendars, shared calendars, booking links.
• Drive data: My Drive, Shared Drives, externally owned files, shortcuts, orphaned files, stale data, sensitive data.
• Identity: Google users, aliases, admin roles, SSO-connected apps, MFA status, recovery methods.
• Security and compliance: Vault retention, legal holds, DLP rules, external sharing, OAuth app grants, audit needs.

Ownership is the practical risk. If a former employee owns key client files in My Drive, migrating only active users does not fix the exposure. If a Shared Drive has broad external access, copying it into SharePoint without redesigning permissions recreates the same problem in a new tenant.

For a small environment, discovery may take days. For a larger tenant with years of Drive sprawl, remediation often takes longer than the mailbox migration itself.

Pick the migration pattern based on complexity, not only user count.

A cutover migration moves users during one change window, often over a weekend. It is best for smaller or simpler environments where leadership accepts a defined outage or disruption window. It reduces coexistence complexity, but it concentrates risk: DNS, authentication, Outlook profiles, mobile devices, mail flow, and support all change at once.

A staged migration moves users in waves. It is safer for larger organizations, multi-location businesses, VIP-heavy environments, or departments that cannot all change on the same day. The tradeoff is coexistence: some users are still in Gmail while others are in Exchange Online, so routing, calendars, delegation, and user instructions must be tightly managed.

A coexistence-heavy migration is appropriate only when the business requires an extended transition because of regulatory, acquisition, geographic, or operational constraints. It may involve dual delivery, routing rules, directory synchronization, calendar coexistence, identity federation, and phased file migration. It reduces user shock but increases cost, duration, and failure points.

Use cutover when the environment is simple and the organization can absorb a short change window. Use staged migration when there are multiple domains, complex calendars, regulated data, many shared addresses, heavy Google Drive usage, or more than a few hundred users. Use extended coexistence only when the business case justifies the additional operational risk.

A 75-person legal firm with Vault holds, delegated mailboxes, and complex Drive permissions can be harder to migrate than a 400-person manufacturer that uses basic mail and document storage.

Object mapping is the planning work that prevents Monday tickets.

Email usually moves cleanly, but Gmail labels require user expectations. A single Gmail message with several labels may appear in more than one folder after migration, depending on the tool and configuration. Label-heavy users should know what their mailbox will look like in Outlook before go-live.

Shared addresses need explicit decisions:

• Use a shared mailbox when a team needs a mailbox workflow, shared replies, and access delegation.
• Use a distribution group when the address only broadcasts mail to members.
• Use a Microsoft 365 Group when the team needs a shared mailbox-like conversation space, shared calendar, membership, and Microsoft 365 collaboration features.
• Use a Team when chat, channels, meetings, and Teams-connected SharePoint files are part of the workflow.
• Use a Microsoft Entra ID security group when the object is primarily for access control.

For Google Drive, design the Microsoft 365 destination around the business structure. My Drive content usually maps to OneDrive for Business. Shared Drives usually map to SharePoint sites, including Teams-connected SharePoint sites where Teams collaboration is required. Departmental and project content should be separated into clear sites such as Finance, HR, Operations, Sales, and Client Projects, with access assigned through groups rather than individual users where possible.

Resolve these Drive issues before migration:

• Externally owned files may not migrate because the organization does not own them.
• Shortcuts can break if the target file is not migrated or the user lacks permission.
• Orphaned files need ownership review and reassignment where possible.
• Google Docs, Sheets, and Slides conversion to Microsoft formats can affect formulas, formatting, scripts, macros, comments, and embedded links.
• Large numbers of unique permissions can make SharePoint difficult to manage and audit.
• Sensitive or regulated content may need labels, retention, or restricted sites in Microsoft 365.

Do not treat data reduction as optional. If a tenant contains stale, duplicate, or former-employee-owned data, migrating everything may only transfer risk and cost into Microsoft 365.

Microsoft 365 depends on Microsoft Entra ID for identity. Before workload migration, confirm each user’s user principal name, primary SMTP address, aliases, licenses, MFA status, admin roles, and required app access.

The common identity failure is a naming mismatch. A user signs in to Google as jane@company.com, but the Microsoft 365 account is jane.smith@company.com with jane@company.com only as an alias. That can be valid, but it must be intentional and communicated because it affects sign-in, Outlook profile creation, Teams access, OneDrive sharing, and user support.

Treat cutover as a high-risk security period. Users are expecting sign-in changes, admins are under time pressure, and phishing messages that imitate Microsoft sign-in prompts are more believable. Review controls before go-live, not after.

Pre-cutover security checks should include:

• Gmail forwarding rules, delegates, and send-as settings.
• Gmail filters that hide, archive, delete, or redirect messages.
• Google third-party OAuth app grants and risky connected apps.
• Super admin accounts in Google Workspace and privileged roles in Microsoft 365.
• MFA coverage and Conditional Access policies in Microsoft Entra ID.
• Exchange Online authentication settings, including SMTP AUTH requirements and blocked legacy protocols where applicable.
• SPF, DKIM, and DMARC records for all sending domains and third-party senders.
• SharePoint and OneDrive external sharing defaults.
• Retention, eDiscovery, audit, and legal hold requirements in Microsoft Purview.

A migration is a good time to implement baseline controls: MFA for all users, Conditional Access for risky sign-ins, separate admin accounts, least-privilege roles, audit logging, retention policies, and a defined external sharing model. Do not recreate weak Google Workspace practices in Microsoft 365.

A Google-to-Microsoft cutover needs a runbook with owners, timestamps, rollback criteria, escalation contacts, DNS steps, user communications, validation checks, and support coverage.

Prepare DNS before the change window. Lower TTL values 24 to 48 hours ahead where your DNS provider allows it. At cutover, update MX to Exchange Online, configure or validate Autodiscover, verify SPF, enable or confirm DKIM for Microsoft 365, and review DMARC alignment so legitimate mail is not rejected after routing changes. Include third-party senders such as payroll, CRM, ticketing, marketing, scanners, and line-of-business apps.

Pre-stage data. Most migration tools support an initial sync followed by delta passes. Use that model for mail and files where possible. Do not try to move all mailboxes and Drive data in one weekend if bulk data can be copied ahead of time and finalized during the cutover window.

User communication must be specific. Tell users:

• When Gmail stops being the primary mail system.
• When Outlook and Exchange Online become the source of truth.
• Which username and password to use.
• How to set up Outlook and mobile mail.
• Where OneDrive, SharePoint, and Teams files will be located.
• What will and will not migrate.
• How long Google Workspace will remain available, if at all.
• Where to get help on the first business day.

Plan Monday support as part of the migration, not as an afterthought. Common issues include missing autocomplete entries, mobile mail not syncing, delegated mailboxes not appearing, calendar permission differences, Outlook profile confusion, Teams sign-in issues, and users looking for Drive content in the wrong OneDrive or SharePoint location.

Keeping Google Workspace active after cutover may be necessary for validation, retention, or legal reasons. Leaving it unmanaged is the problem.

A stale Google tenant can retain sensitive data, active OAuth tokens, externally shared files, admin accounts, groups, and mail routing rules outside the Microsoft 365 governance model.

Create a post-migration control plan:

• Validate migrated mail, calendar, contacts, and files against migration reports and user sign-off.
• Confirm retention, eDiscovery, Vault, and legal hold requirements before deleting or disabling anything.
• Remove unnecessary Google licenses or shift to the minimum required archive/compliance licensing where appropriate.
• Disable old forwarding and routing rules that are no longer required.
• Revoke risky OAuth app access and reduce Google admin privileges.
• Block new external sharing in Google if the tenant is read-only.
• Document any remaining Google services, owners, purpose, and decommission date.

Do not cancel Google Workspace immediately if Vault holds, audits, or historical records are still required. Do set a date-driven decommissioning plan, such as a read-only validation period followed by final export, retention decision, or deletion.

The goal is not only to move users. The goal is to arrive in Microsoft 365 with cleaner identity, safer sharing, predictable collaboration spaces, and supportable operations.