← All articles

Secure Cutover for IT Admins Migrating Google Workspace to 365

Playbook for IT teams migrating Google Workspace to Microsoft 365. Run a 2–5 user pilot, provision accounts, and harden security at cutover.

IT administrator planning secure cloud migration

Choose native Microsoft tooling, meaning Exchange automated migration and Migration Manager, for mail-first tenants under about 50 seats. Choose a dedicated third-party migration tool with incremental sync for larger or Drive-heavy tenants on a tight deadline. Either way, the first task is identical: verify your domain in Microsoft 365, then run a 2 to 5 user pilot before touching production mailboxes. What follows is the planning, execution, and cutover sequence that turns that decision into a completed migration.

TL;DR:

  • Native Microsoft tools are sufficient for small tenants under 50 seats, but larger or Drive-heavy organizations benefit from third-party tools with features like incremental sync and concurrency.
  • Verifying your domain, provisioning accounts with correct aliases, and completing a pilot run are critical steps before starting the migration, as skipping these causes delays or failures.
  • Accurate discovery by measuring mailbox and Drive volumes prevents underestimating scope, ensuring proper batch sizing and realistic timelines.
  • For Drive migration, mapping Shared Drives to SharePoint sites carefully and planning permission management reduces post-migration cleanup, especially for large estates.
  • During cutover, lowering DNS TTL beforehand and executing a staged sequence minimizes downtime and eases rollback if issues arise.

Table of Contents

How Do You Choose a Google Workspace to Microsoft 365 Migration Method?

The right method depends on four variables: seat count, Drive volume, deadline pressure, and compliance requirements. A 30-person consultancy with modest Shared Drive usage rarely needs anything beyond what Microsoft ships natively. A 300-person firm with terabytes of Shared Drives and a six-week deadline almost always needs concurrency and delta sync that native tools don’t offer.

Exchange automated migration and Migration Manager move mail, contacts, calendars, and Drive files in batches, and both require domain verification and pre-provisioned mailboxes before the first batch runs. They work well for straightforward moves but stop short of the audit trails larger organizations need.

  • Native tooling costs nothing extra but caps concurrency and offers limited reporting.
  • IMAP migration moves mail only. It leaves calendars, contacts, and permissions behind, and produces no meaningful audit log.
  • Third-party tools run concurrent migrations, incremental syncs, and preserve permission fidelity, which matters most once you’re past a few hundred mailboxes.

For SMBs under 50 seats, native tooling usually delivers adequate fidelity while saving on licensing cost. For organizations with many users or a heavy Shared Drive estate, third-party tooling tends to pay for itself in saved manual hours.

What Prerequisites Do You Need Before Migrating?

Skipping prechecks is the single most common cause of a stalled migration. Work through these in order, and don’t schedule your first batch until every item is closed.

  1. Verify your domain in Microsoft 365 and map out your DNS TTL changes now, since lowering TTL days ahead of cutover shortens your rollback window later.
  2. Create a Google Cloud service account and enable the API scopes Microsoft’s automated migration expects, then download the project JSON key you’ll need for the EAC migration endpoint.
  3. Provision mail-enabled user accounts in Microsoft 365 and assign Exchange licenses ahead of migration, not during it. A mailbox with no license attached will fail silently mid-batch.
  4. Confirm administrative roles in both tenants and export a clean inventory CSV template with headers your migration tool expects, typically EmailAddress, Username, and Password columns.

Rushing step one is the mistake that costs teams the most time. A domain verification failure discovered on cutover night is far more expensive than one caught during planning.

How Do You Scope and Plan the Migration?

Discovery is where most timeline estimates go wrong, usually because admins guess at data volume instead of measuring it. Run an actual inventory before you commit to a date.

Pull counts for every mailbox, every Shared Drive, every Google Group, and every third-party app integration tied to Workspace. You need real numbers, not estimates, to size batches correctly.

  • Decide your Shared Drive to SharePoint mapping pattern before you migrate a single file. Treat this as architecture work, not file copying — the mapping choice determines whether users can find anything after cutover.
  • Flag oversized mailboxes, archived data, and any Google Vault retention or MRM policies that will need equivalent handling in Microsoft 365 compliance settings.
  • Record every exception (shared ownership, orphaned files, departed employees) in the same inventory sheet you’ll use for provisioning.
  • Estimate batch sizes and project timeline from actual mailbox and Drive counts, not from headcount alone.

Provisioning Accounts and Assigning Licenses in Entra ID

Accounts must exist in Microsoft 365 before mail migration starts, and they need to match Google addresses exactly, including any alias domains users rely on for incoming mail.

  • Provision each account with proxy addresses covering every alias the Gmail account currently accepts, or you’ll generate silent bounces after cutover.
  • Assign Exchange Online licenses and any service plans required for mailbox storage before the first batch, since license propagation can take time to settle across Entra ID.
  • Use a CSV template and a bulk provisioning script rather than manual account creation. Manual entry at scale is where typos turn into missed mailboxes.
  • If you’re using Migration Manager for Drive content, note that its service account needs separate API scopes from the mail migration service account. Don’t assume one credential covers both workflows.

How Do You Migrate Mailboxes Using Exchange Admin Center?

Exchange Admin Center’s automated flow handles the mechanics once your prerequisites are closed. Here’s the sequence:

  1. In EAC, create a migration endpoint using the Google service account’s JSON project key, and confirm the Client ID and scopes validate before proceeding.
  2. Set concurrency limits on the endpoint. Higher concurrency finishes faster but risks tripping Google’s API rate limits, so start conservative on your first batch.
  3. Prepare your CSV with EmailAddress, Username, and Password columns, matching the format EAC expects exactly, then import it as a migration batch.
  4. Name batches by department or wave (e.g., “Finance_Wave1”) so monitoring dashboards stay readable once you’re running several batches concurrently.
  5. Watch for message size limits and Mail Records Management archival mismatches. Large attachments or Vault-retained messages are the most common cause of stalled items.
  6. For any failed item, isolate it and re-run individually rather than restarting the entire batch, which wastes time re-syncing mail that already succeeded.
  7. Run your validation checklist: item counts on source versus target, a send/receive test from each migrated mailbox, and confirmation every account has its Exchange license and storage active.

Pro Tip: Run your first migration batch against the pilot group only, and let it sit for 24 to 48 hours before scaling up. Problems that look like one-off glitches at 5 mailboxes often turn out to be systemic issues that would have broken 500 mailboxes at once.

Moving Google Drive to OneDrive and SharePoint

File migration is where fidelity problems surface, mostly because Shared Drives don’t map to OneDrive or SharePoint in any single obvious way.

Three mapping patterns dominate in practice. Mapping each Shared Drive to its own SharePoint site keeps permissions cleanest but multiplies site sprawl. Consolidating several Shared Drives into one site with subfolders reduces sprawl but complicates permission inheritance. Mapping My Drive content to each user’s OneDrive is the default and rarely needs debate, but Shared Drives deserve a deliberate decision, not a default.

  • Migration Manager moves My Drive and Shared Drive content to OneDrive and SharePoint and preserves much of the associated metadata, though file and mail migrations run as separate workflows with separate credentials.
  • Google Docs, Sheets, and Slides convert to Office formats automatically, but version history and some comment threads don’t always survive the conversion cleanly.
  • Choose Migration Manager for straightforward, smaller Drive estates. Choose a third-party tool when you need concurrency, delta sync, or migration reporting detailed enough to satisfy an audit.
  • Budget a post-copy permission review. Permission translation is rarely perfect, and reconciling unique sharing exceptions after the bulk copy is normal, not a sign something went wrong.

Pro Tip: Don’t migrate the “Shared with me” view. It’s a virtual view in Google Drive with no equivalent in SharePoint or OneDrive, and treating it as a real folder to copy just duplicates files users already have access to elsewhere.

What Happens to Calendars and Contacts During Migration?

Recurring events, meeting invitees, and basic contact fields transfer reliably through both native and third-party tools. What doesn’t survive as cleanly: calendar color coding, room resource bookings tied to Google-specific resource calendars, and custom contact tags or labels unique to Gmail’s contact model.

When your migration tool doesn’t support a specific field, export it manually via Google Takeout and reimport it after cutover rather than losing it silently. Watch timezone handling closely. If users span multiple time zones, verify a sample of recurring meetings post-migration to confirm start times didn’t shift. After cutover, spot-check ten to fifteen calendars across departments, confirming recurring series, attendee lists, and any linked video conferencing details all migrated intact.

What Happens to Calendars and Contacts During Migration? — overview diagram

What Is the Right Sequence for Cutover Day?

Cutover succeeds or fails based on sequencing, not effort. Work backward from your target hour.

  1. T-14 to T-7 days: Lower your DNS TTL so changes propagate fast when it matters, and pre-stage records like autodiscover and your SPF include statements without activating them yet.
  2. T-1 day: Run your final full sync, confirm every pilot and wave mailbox shows a completed status, and freeze non-essential changes in the Google tenant.
  3. Cutover hour: Run one last delta sync to capture any edits made since the full sync, then change your MX records to point to Microsoft 365’s mail endpoints.
  4. Immediately after: Verify SPF, DKIM, and DMARC records resolve correctly, then send test messages both inbound and outbound to confirm mail flow is live.
  5. First 2 hours: Monitor mail queues and help desk tickets closely. If inbound mail fails broadly or authentication breaks for a critical percentage of users, that’s your rollback trigger.

Rolling back means reverting MX records to the Google Workspace values you documented before cutover, which is exactly why lowering TTL early matters. A short TTL means a bad decision costs you minutes of propagation delay, not hours.

Why Do Rate Limits Matter More Than Bandwidth?

Bandwidth is rarely the constraint people expect it to be. The real bottleneck is API rate limiting from Google and Microsoft, which throttles how fast any single connection can pull or push data regardless of your network capacity.

The fix is distribution, not brute force. Running multiple concurrent workers across staged batches, and scheduling the heaviest jobs overnight or on weekends, spreads the load in a way a single high-bandwidth pipe never can. The proven pattern is a large initial bulk copy well ahead of cutover, followed by a short delta sync right before the DNS switch, which minimizes the disruption users actually notice.

Bulk copy and delta sync cutover workflow

How Do You Verify the Migration Actually Worked?

A migration isn’t done when the last batch shows “completed.” It’s done when you’ve proven the data is complete, accessible, and correctly permissioned.

  • Run item-count reconciliations between source and target for a representative sample of mailboxes and Shared Drives, not just the ones that look easy.
  • Open sample files directly in Shared Drives migrated to SharePoint and confirm permission fidelity matches what owners expect.
  • Pull tool logs and error reports to triage any mismatches, and document remediation steps for anything that required manual fixing.
  • Get sign-off from both IT and the business owner of each migrated department before retiring the corresponding Google Workspace accounts.

Only after that checklist clears should you consider decommissioning the source tenant.

What Doesn’t Migrate Automatically?

Set these expectations with stakeholders before the project starts, not after someone notices something’s missing.

Google Groups and Google Chat have no direct one-to-one equivalent in Microsoft 365, and both typically require manual recreation as Microsoft 365 Groups or Teams channels. Distribution lists built in Google Groups need to be rebuilt, not just copied. External file-sharing links break entirely; anyone outside your organization with a shared link will need a new one issued after the file lands in SharePoint or OneDrive. Mailbox delegates and some Gmail labels also need manual repair post-migration. Before you migrate anything, disable or explicitly account for Google Vault retention policies and MRM rules, since active retention holds can block or corrupt in-flight migration items.

What Does the Execution Runbook Look Like?

A runbook turns this guide into something an engineering team can actually run without you in the room.

  1. Pilot with 2 to 5 users spanning at least two departments; require a clean 48-hour validation before approving wave scheduling.
  2. Wave sizing: group by department, keep waves under 100 mailboxes where possible, and sequence low-risk departments before finance, legal, or executive mailboxes.
  3. Pre-cutover: confirm DNS TTL is lowered, run the final delta sync, and send stakeholder communications 48 hours ahead with an expected downtime window.
  4. Cutover hour: execute the MX and DNS sequence, verify mail flow both directions, and keep the help desk staffed for immediate escalation.
  5. Post-cutover: run your validation checklist, clean up temporary migration accounts, and retire Google Workspace licenses only after sign-off.

Keep a standard user communication template and a named escalation path ready before wave one starts. Improvising either during cutover week costs more time than writing them in advance.

Why Security Posture Matters More During Migration Than After

Cutover is the cheapest moment you’ll ever have to fix identity gaps, and most teams waste it. Applying conditional access and multi-factor authentication the moment mailboxes go live prevents the exact window attackers look for: freshly created accounts with default settings and no monitoring yet in place.

Data loss prevention and mailbox protection policies are far easier to configure into a clean tenant than to retrofit after users have built months of habits and exceptions around a looser setup. That’s the case for treating migration as a security project first, a data-movement project second. Rapid incident response and continuous monitoring during the cutover window reduce the odds that a migration-related gap turns into an actual breach, rather than just a support ticket.

— 247techify Team

Get a Managed Google Workspace to Microsoft 365 Migration

If you’d rather not run this entire runbook internally, A managed migration engagement includes a cybersecurity-first approach focused on identity hardening, conditional access, and configuring DLP at cutover rather than afterward.

247techify

A managed migration engagement covers planning and discovery, mailbox and Drive migration execution, DNS cutover, post-migration verification, and security hardening across your new Microsoft 365 tenant. For most small and mid-market organizations, the engagement duration depends on factors like mailbox count and Shared Drive volume. Regulated businesses in healthcare, finance, or legal often add a compliance review pass to satisfy audit requirements alongside the migration itself, which our IT compliance and auditing services can scope directly into the project. If you want a second set of hands without giving up internal control, our co-managed IT services model lets your team stay hands-on while we run the technical execution and 24/7 monitoring. Request a migration assessment through our managed IT services page and we’ll scope your cutover before you commit to a date.

Key Documentation to Keep Open During the Project

Bookmark these before you start your first migration batch. You’ll reference them repeatedly during EAC configuration and cutover week.

Microsoft’s own Google Workspace migration overview and the automated EAC migration guide cover the exact prerequisites and batch mechanics referenced throughout this article. For Drive content, the SharePoint Migration Manager overview documents mapping behavior in detail. For a breakdown of when native tools stop being sufficient, see ShareGate’s migration considerations post. For ongoing tenant management once your migration is complete, our Microsoft 365 support page and optimization services cover governance and post-migration tuning.

Sources

FAQ

Can I have both Google Workspace and Microsoft 365 running at the same time?

Yes. Coexistence during migration is normal and often intentional, letting you run mail through Google while testing Microsoft 365 with a pilot group before full cutover, though maintaining both long-term adds licensing cost and administrative overhead most organizations avoid past the transition period.

Is it cheaper to use Google Workspace or Microsoft 365?

Cost depends heavily on tier and seat count for each platform, and licensing comparisons change frequently enough that a direct answer here would go stale fast. Base your decision on total cost including admin time, storage needs, and compliance requirements rather than sticker price alone.

How do I migrate data from Google Workspace to Microsoft 365?

Verify your domain, provision matching Microsoft 365 accounts, then use Exchange automated migration for mail and Migration Manager or a third-party tool for Drive content, followed by a DNS cutover and post-migration validation.

How can I migrate my Google Drive to Microsoft 365?

Map your Shared Drives to SharePoint sites and My Drive content to individual OneDrive accounts, then run the copy through Migration Manager for straightforward estates or a third-party tool when you need concurrency and permission fidelity at scale.

What’s the biggest mistake IT teams make during this migration?

Skipping the discovery and inventory phase and guessing at mailbox or Drive volume, which almost always produces an inaccurate timeline and undersized batch sizing once real migration begins.