Migrate Exchange to Google Workspace with GWMME

You've signed the Workspace contract and the on-prem Exchange server (or your hosted Exchange tenant) has a date to go away. The mail, calendars, and contacts of every user have to come along. Google maintains a free, supported tool for exactly this called GWMME (Google Workspace Migration for Microsoft Exchange), and it's the right choice for most projects of this shape. This guide covers source prep, GWMME configuration, batch sizing, when to reach for a desktop IMAP tool instead, and the cutover sequence that minimizes mail interruption.

Why GWMME instead of IMAP#

For an Exchange-to-Workspace project, GWMME is usually the better tool. Here's why.

GWMME talks to Exchange over EWS, which means it can pull metadata that IMAP doesn't expose. Categories, sender display names, calendar items, contacts, and the Drafts folder all come across in higher fidelity than an IMAP migration would manage.

GWMME is supported by Google. If you hit an edge case, you can open a Workspace support ticket and someone will look at it. Third-party tools may or may not have responsive support depending on the vendor.

GWMME runs on your own Windows workstation, so the bandwidth path goes from Exchange to your workstation to Google's API. This is different from the Data Migration Service, which runs in Google's infrastructure. The local path gives you more visibility and control, but uses your bandwidth.

The tradeoffs: GWMME is Windows-only, the UI is dated, and it doesn't handle deep folder structures as gracefully as some third-party tools. For very complex mailboxes (deeply nested folders, unusual character sets, edge-case metadata), a desktop IMAP tool like Mailbox Taxi can complement GWMME by handling the difficult mailboxes individually.

Source preparation#

Exchange-side prep is the same regardless of which tool you use, but for GWMME specifically there are a few extra requirements.

Verify Exchange version and patch level#

GWMME requires Exchange 2010 SP3 or later, or Exchange Online. Verify with Get-ExchangeServer | Format-List Name, AdminDisplayVersion in Exchange Management Shell. Older versions will technically work over IMAP, but you'll lose all the metadata benefits and might as well use a different tool.

Confirm EWS is accessible#

GWMME connects over EWS. From the workstation where you'll run GWMME, test the EWS endpoint: https://mail.yourdomain.com/EWS/Exchange.asmx. You should get a 401 challenge. If you get a connection error, EWS publishing isn't working from the GWMME workstation. Fix that before installing GWMME.

Create a migration service account with impersonation#

GWMME needs to impersonate every source mailbox. Create a dedicated AD account, give it a strong password, and grant ApplicationImpersonation in Exchange RBAC:

New-ManagementRoleAssignment -Name "GWMMEImpersonation" `
  -Role ApplicationImpersonation -User gwmme-svc@yourdomain.com

Verify the assignment with Get-ManagementRoleAssignment -Role ApplicationImpersonation.

Take a per-mailbox baseline#

Before any data moves, capture per-mailbox stats:

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
  Select DisplayName, ItemCount, TotalItemSize, LastLogonTime |
  Export-Csv -Path .\baseline.csv -NoTypeInformation

Save this. You'll compare against it to verify each batch.

Raise EWS throttling for the service account#

Exchange's default EWS throttling is conservative. For migration, you'll want more headroom. Create a dedicated throttling policy:

New-ThrottlingPolicy -Name "GWMMEPolicy" -EwsMaxConcurrency 10 `
  -EwsMaxBurst Unlimited -EwsRechargeRate Unlimited -EwsCutoffBalance Unlimited
Set-Mailbox gwmme-svc -ThrottlingPolicy "GWMMEPolicy"

This applies the relaxed policy only to the service account, leaving normal users on the default policy.

Destination preparation on Workspace#

The Google side has its own list.

Provision destination users#

Every Exchange mailbox needs a matching Workspace user with the same primary address. Use the bulk-create CSV in the Admin Console for under 200 users, or the Directory API for larger numbers. If you're keeping the same domain, users are created but mail keeps flowing to Exchange until MX records change.

Allocate sufficient storage#

Workspace Business Standard pools 2 TB across the org; Business Plus pools 5 TB. Enterprise is higher. If you're migrating 200 mailboxes averaging 8 GB each (1.6 TB), Business Standard is borderline. Plan headroom.

Disable directory hardening features temporarily#

If you have aggressive sender verification, DKIM enforcement, or strict spam policies that might reject mail with old timestamps, relax them during the migration window. Mail from years ago can fail modern checks. Re-enable after.

Configure GWMME authentication on the Google side#

GWMME authenticates to Google via OAuth2 with a service account. Create a service account in the Google Cloud Console, enable the Gmail API, Calendar API, and People API, and download the JSON key. Then in Workspace Admin, grant the service account domain-wide delegation for the relevant scopes. Google's GWMME setup docs have the exact scope list; copy it verbatim because typos will cause unhelpful errors.

Running GWMME#

1. Install GWMME on a clean Windows workstation

   GWMME runs best on a dedicated Windows 10 or 11 workstation with 16 GB RAM and a wired connection. Download GWMME from the Workspace admin downloads page. Install. Sign in with a Workspace super admin account. Configure the source as Exchange and paste in the service account credentials and EWS URL.

2. Validate the connection

   Use GWMME's connection test on a single mailbox before bulk loading the user list. The test should report the mailbox size and item count. If it fails, check EWS reachability, service account password, and impersonation rights. Don't proceed until a single mailbox connects cleanly.

3. Configure migration scope

   Decide what to migrate per user: mail, calendar, contacts, or a subset. For a full Exchange-to-Workspace cutover, all three. Set the date range. The default is everything; restricting to the last 7 years is common to leave older noise behind. Configure label/folder mapping: GWMME maps Exchange folders to Gmail labels by default with reasonable mappings (Sent Items → Sent, Deleted Items → Trash).

4. Run a pilot with 3 to 5 mailboxes

   Pick a mix: a small mailbox, a medium one, one with deep folder structure, one with heavy calendar usage. Run GWMME against just those mailboxes. Let it finish completely. Then verify in Gmail and Calendar that data is present, dates are right, attachments open, calendar items are on the right dates and times. Fix any configuration before scaling.

5. Break the full user list into waves

   For estates over 100 mailboxes, migrate in waves of 50 to 100. This keeps each wave small enough to verify in one sitting and limits blast radius if something goes wrong. Schedule waves over the course of two to four weeks, leaving days between waves for verification and any cleanup.

6. Run waves off-hours, monitor for throttling

   Start each wave in the evening. GWMME will run for many hours on real data. Monitor the GWMME log and Exchange's performance counters. If you see EWS throttling on the source, lower GWMME concurrency. If you see slowdowns on the Google side, GWMME will back off automatically.

7. Verify each wave against the baseline

   After each wave, compare per-mailbox item counts in Gmail (via the API) against your baseline CSV. Variance under 1 percent is usually fine, the deduplication and meeting-invitation handling can account for small differences. Variance over 5 percent is a red flag. Spot-check ten messages per mailbox for content fidelity.

8. Do a final delta before MX cutover

   On cutover day, run GWMME in delta mode for all migrated mailboxes. This catches mail that arrived during the long migration. It runs much faster than the full migration because most data is already present.

When to reach for a desktop IMAP tool#

GWMME is great for the bulk of users, but a few mailboxes per project always end up being problematic. Symptoms:

• A specific mailbox fails repeatedly with the same error.
• A folder with deeply nested subfolders truncates at some depth.
• Messages with very unusual MIME structure (legacy clients, weird attachments) fail to migrate.
• A user with a 100 GB mailbox keeps hitting EWS timeouts no matter how you configure throttling.

For these cases, a desktop IMAP tool gives you per-message visibility and control GWMME doesn't. Run Mailbox Taxi against the difficult mailbox specifically: connect to the source Exchange over IMAP, connect to the destination Gmail over IMAP with an app password, and migrate the problem folders directly. This is a fallback, not the default path, but it's saved many projects from being stuck on the last 5 percent.

MX cutover and decommissioning#

The migration runs over weeks; the cutover is a single window.

Pick a cutover window#

Off-hours, ideally Friday evening or a weekend morning. Notify users at least a week in advance.

Lower TTLs on MX records#

48 hours before cutover, lower MX TTL to 300 seconds. This means changes propagate faster on cutover day. If your DNS is hosted somewhere with slow change propagation, factor that in.

Flip MX records to Google#

On cutover day, change MX records to point at Google's MX endpoints (aspmx.l.google.com and the alternates). New mail starts flowing to Workspace within minutes for fast DNS resolvers and within an hour or two for the slowest.

Run final delta with GWMME#

While DNS propagates, mail will continue to land at Exchange for some senders. Run GWMME in delta mode every few hours during the first 24 hours after cutover to catch this stragglers.

Configure forwarding on Exchange#

After the 24-hour delta sweep, configure Exchange to forward any incoming mail to Workspace as a belt-and-suspenders measure. This catches senders whose DNS resolvers are unusually slow or who have hardcoded the Exchange MX.

Decommission Exchange in stages#

Keep Exchange running for 30 days minimum after cutover. After 30 days, dismount mailbox databases. After 60 days, decommission servers. Before final shutdown, export every mailbox to PST and store on cold backup. Users will ask for old mail months later; the PSTs are your insurance.

For pure on-prem to Gmail (not full Workspace), see the Exchange to Gmail walkthrough. For the M365 alternative, Exchange to Office 365. The Exchange migration guide covers the source side in depth, the Google Workspace migration guide covers the destination, and the tenant-to-tenant migration guide covers project management patterns that apply to this kind of move.