Migrate On-Prem Exchange to Gmail: Workspace DMS and IMAP

You're decommissioning an on-prem Exchange server (probably 2013, 2016, or 2019) and landing on Google Workspace. Mailboxes, folder structure, categories, and several years of mail need to come along. The path has more options than a typical IMAP-to-IMAP move because Exchange exposes EWS, and Google Workspace ships with a free Data Migration Service that knows how to talk to it. This guide covers when to use DMS, when to use a desktop IMAP tool, and how to sequence the cutover so nothing drops on the floor.

Decision framework: DMS vs. desktop tool#

Before any technical setup, decide which migration path you're taking. The choice depends on three things: estate size, metadata sensitivity, and visibility requirements.

Google's Data Migration Service is free, server-side (runs in Google's infrastructure, not your network), supports both EWS and IMAP, and works well for small estates with simple mailboxes. Its weaknesses are around visibility (limited per-folder reporting), retry behavior (you can't pause and resume cleanly), and edge cases (unusual folder names, very large messages, deeply nested folders sometimes fail silently).

A desktop IMAP migration tool like Mailbox Taxi runs on your workstation, gives you full per-folder counts, handles per-message retries, and lets you pause-and-resume across days. The tradeoff is that you're using your workstation's bandwidth and the tool can't talk EWS directly; it's IMAP only.

The rule of thumb most engineers settle on: under 30 mailboxes and under 5 GB average, use DMS. Over that, or whenever you need per-folder verification or want EWS metadata preserved precisely, use a hybrid approach. DMS for the bulk pull plus a desktop tool for the difficult mailboxes.

What carries over from on-prem Exchange#

Be specific about what you're moving.

Messages, headers, attachments, dates, read/unread state, and folder hierarchy all move cleanly through both paths.

Sent Items, Drafts, Deleted Items: these move, mapped to Gmail's Sent, Drafts, and Trash respectively. If you're using Gmail's label model rather than folders, mail still appears in those system labels.

Categories: EWS preserves these and DMS maps them to Gmail labels. IMAP does not preserve them.

Flags: both paths preserve the flagged/starred state.

Calendar items, contacts, tasks, public folders, shared mailboxes: these are separate migrations. Calendar and contacts can be moved through DMS too, but require their own configuration. Public folders are the hardest part of any Exchange decommission and usually need a dedicated archiving plan. Shared mailboxes work but need to be re-provisioned on the Google side as delegated mailboxes or Google Groups.

Server-side rules and signatures: do not survive. Users must reconfigure these in Gmail.

Retention tags and managed folder policies: Exchange-specific, do not survive. If retention is a legal requirement, plan for that with a separate archiving tool.

Source-side preparation#

The Exchange side needs to be ready before any tool connects.

Confirm EWS is reachable#

EWS is the primary Exchange Web Services endpoint. From outside the network, run a quick HTTPS test against https://mail.yourdomain.com/EWS/Exchange.asmx. You should get a 401 challenge. If you get a connection refused or a TLS error, the external publishing of EWS isn't working and you need to fix that before DMS or any external tool can reach the server.

Verify autodiscover#

Autodiscover lets migration tools find the right EWS endpoint without hardcoding. Test it with the Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) using a real mailbox credential. If autodiscover fails but EWS works, you can pass the EWS URL directly to DMS, but autodiscover is preferred.

Enable IMAP if you're going the IMAP path#

In Exchange Management Shell, check that Microsoft Exchange IMAP4 and Microsoft Exchange IMAP4 Backend services are running and set to Automatic. IMAP4 listens on port 993 with SSL. Test it from outside the network with openssl s_client -connect mail.yourdomain.com:993 and confirm the TLS handshake completes and you can log in with LOGIN user@domain.com password.

Create a service account with impersonation#

Both DMS and most desktop tools support a single service account that impersonates all source mailboxes, instead of asking you to enter every user's password. Create a dedicated account in Active Directory, give it a strong password, and assign the ApplicationImpersonation RBAC role scoped to the mailboxes you're migrating. The PowerShell is New-ManagementRoleAssignment -Name "MigrationImpersonation" -Role ApplicationImpersonation -User migration-svc@yourdomain.com.

Take a baseline#

Before any data moves, document per-mailbox sizes and item counts. Get-MailboxStatistics in PowerShell will dump everything: Get-MailboxStatistics -Server EX01 | Select DisplayName, ItemCount, TotalItemSize. Save this to CSV. You'll use it for verification later.

Destination-side preparation on Google Workspace#

The Google side is simpler but has its own gotchas.

Provision users in Workspace#

Every source mailbox needs a corresponding Google Workspace user with the same primary email. Use the bulk-create CSV in the Admin Console or, for larger estates, the Directory API. If you're keeping the same domain, the users are provisioned but mail still flows to Exchange until MX records change at the end.

Enable IMAP for destination users (if using a desktop tool)#

Gmail has IMAP off by default for some Workspace editions. In the Admin Console under Apps → Google Workspace → Gmail → End User Access, ensure IMAP access is allowed. Each user can then enable IMAP in their Gmail settings, or you can do it administratively through the Gmail API.

Generate app passwords if 2-step verification is on#

If Workspace has 2-step verification enforced, users need app passwords for IMAP. For DMS this is handled differently because DMS uses Google's own auth. For a desktop tool, generate app passwords at myaccount.google.com/apppasswords per user.

Decide on storage allocation#

Google Workspace Business Standard includes 2 TB pooled across the org. Business Plus is 5 TB pooled. Enterprise tiers are higher. Confirm your aggregate Exchange mailbox size fits comfortably. The Google Workspace migration guide has more on capacity planning.

Running the migration#

Two paths from here. Pick one and follow it through.

1. Run a pilot with two or three mailboxes

   Whatever path you've picked (DMS or desktop tool), run it on two or three test mailboxes first. Pick a mix: a small mailbox, a medium one, and one with deep folder structure or unusual content. Migrate them. Compare folder counts and message counts to the baseline you took. Open ten messages each in Gmail and verify rendering. This pilot catches configuration errors before they cost you 40 hours.

2. Plan batches by size

   For a real estate, don't migrate everyone at once. Group mailboxes into batches of 10 to 25 by size. Smaller mailboxes can be batched larger; very large mailboxes (over 50 GB) get their own batch. This keeps any single failure from cascading and gives you cleaner per-batch verification.

3. Start the first batch off-hours

   Off-hours means after 8pm local time and ideally on a Friday so the long-running portion happens over the weekend. Both DMS and desktop tools will run for hours on real data. Off-hours start avoids competing with normal user mail flow and gives you Monday morning to verify before the next batch.

4. Monitor for throttle errors

   Gmail's ingestion is throttled per destination account. You'll see slow-downs in DMS or Throttling concurrent connections errors in a desktop tool. Both react appropriately if you let them. Don't try to force higher concurrency by running multiple tool instances against the same destination, you'll just hit the throttle harder.

5. Verify each batch before moving on

   After a batch completes, compare per-mailbox message counts against the baseline. Variance under 1 percent is usually genuine deduplication. Variance over 5 percent means a folder failed and needs a delta run. Spot-check ten messages per mailbox: dates, attachments, rendering.

6. Do a final delta before MX cutover

   On the day of MX cutover, do one more delta pass over all migrated mailboxes to catch any mail that arrived during the long migration. With DMS this is the same job rerun in delta mode. With a desktop tool, it's a resume of the same job which only fetches new messages.

7. Flip MX and run one more delta

   After flipping MX records to Google, wait 24 hours for DNS propagation, then run one final delta to catch any mail that arrived at Exchange during the transition. Exchange will still receive mail from senders whose DNS hasn't refreshed yet, so this last delta matters.

EWS vs. IMAP path specifics#

EWS gives you better metadata (categories, server-side flags, native Exchange properties) and slightly higher throughput. DMS uses EWS by default when it can. A desktop IMAP tool obviously uses IMAP.

When IMAP is the only option (older Exchange, no EWS publishing, firewall constraints), you'll lose the category mapping. Plan for that.

When EWS is available but you're worried about its load on the source server, run the migration during off-hours and configure Exchange's EWS throttling policy to allow higher concurrency for the migration service account. The policy is Set-ThrottlingPolicy with EwsMaxConcurrency, EwsMaxBurst, and related parameters.

After cutover#

The technical move is done. The cleanup matters.

Notify users with a specific cutover guide. Sending a generic "we're moving to Gmail" email is not enough. Send specific instructions for what they need to do: open Gmail, reconfigure their phone, recreate their signature, recreate filters and forwarding rules. The shorter and more concrete this is, the smoother the first week goes.

Run a 30-day forwarding rule on Exchange. Configure Exchange to forward any incoming mail at the old SMTP endpoints to the Gmail address. This catches senders whose DNS resolvers are slow to update and external services configured with stale MX records.

Decommission Exchange in stages. Don't shut down the server the day after MX cutover. Run it for 30 days minimum with forwarding active. After 30 days, dismount mailbox databases. After 60 days, decommission the server.

Archive Exchange before shutdown. Before the final shutdown, export each remaining mailbox to PST and keep them on cold storage. You will get one request, six months from now, from a user looking for an email they thought they didn't need. The PSTs are your insurance.

For more context on the source side, the Exchange migration guide has deeper coverage. If you're considering Office 365 as an interim or alternate destination, the Exchange to Office 365 walkthrough covers that path. If you want a Workspace-specific deep dive, see Exchange to Google Workspace. And the complete email migration guide covers project sequencing across any provider pair.