How to Avoid Email Delays When Migrating from Exchange to Gmail

The riskiest moment in an Exchange-to-Gmail migration is not when the first mailbox starts copying. It is the period before and after MX cutover, when old mail flow, new mail flow, throttled imports, DNS caches, and user expectations all overlap. If the goal is to avoid Microsoft Exchange email delays during the move to Gmail, treat the project as four separate controls running inside one lifecycle: data transfer speed, coexistence delivery, DNS behavior, and post-cutover reconciliation.

That framing matters because “slow” is not always a failure. Microsoft’s own migration performance guidance shows that, for on-premises onboarding into Microsoft 365, a 10–50 GB mailbox has a median duration of about 2 days and a P90 duration of about 6 days.[1] Those figures are not an Exchange-to-Google forecast. They come from Microsoft 365 migration scenarios, not Google Workspace imports. Still, they are useful because the same pressure points keep showing up: mailbox size, network throughput, service-side throttling, and migration concurrency. A 40 GB executive mailbox taking more than a few hours is not automatically a crisis. A whole batch stalling because every account is being throttled is.

The Seven-Phase Route, Before Anyone Touches MX

Decision-makers usually want one cutover date. Administrators need a migration route with checkpoints. The practical flow looks like this:

The middle phases deserve the most attention. Assessment and tool selection set the ceiling for speed, but EWS throttling, dual delivery, DNS propagation, and delta sync decide whether users experience the migration as routine maintenance or as a mail outage.

Phase 1: Cut the Transfer Load Before It Becomes a Queue

The first useful assessment is not a license count. It is a mailbox inventory that tells you which accounts will dominate the migration window: executives with large historical mailboxes, shared finance mailboxes, legal archives, service accounts, and users with unusually large attachments.

Microsoft’s migration best-practice guidance treats mailbox size as one of the major determinants of duration, and that principle carries cleanly into Exchange-to-Google work even when the destination platform changes.[1] Every gigabyte you remove before migration is data that does not need to be read through Exchange Web Services, transmitted, transformed, written into Gmail, and checked again during delta sync.

• Identify mailboxes above the normal range for the organization and move them into smaller pilot batches.
• Archive or exclude old mail only where policy allows; do not let cleanup become an undocumented retention decision.
• Find shared mailboxes and delegated workflows early, because the owner is often not the person who will notice missing mail.
• Check source-side health before migration, especially if Exchange is on-premises and already showing transport or database issues.

Vendor migration guides often recommend removing duplicates, stale mail, and large attachments before moving data. That advice is commercially framed in some third-party material, but the operational logic is sound: smaller source data reduces transfer time in proportion to what is actually excluded from the job.[2]

Phase 2: Choose the Tool for the Failure Mode, Not the Logo

Google’s migration options now cover a wider range than many older playbooks describe. In June 2025, Google announced that the Admin Console data import tool supports migrating email and calendar content from Microsoft Exchange Online to Google Workspace for up to 1,000 users at a time, including delta migration capability.[3] That is a meaningful improvement for small and mid-sized Exchange Online tenants because it removes some of the older setup ceremony around separate migration tooling.

It does not remove the need to plan throttling, coexistence, DNS, or verification. The Admin Console import tool can be a good fit when the source is Exchange Online, the user count is within Google’s stated limit, and the migration does not need complex transformation rules. Larger environments, mixed on-premises estates, or migrations with unusual permission and folder requirements may still need Google Workspace Migrate, GWMME, or a vetted third-party tool. Google’s migration documentation continues to separate paths by source system and migration need rather than treating one tool as universal.[4]

The selection test is simple: can the tool show which mailboxes are delayed, retry without duplicating work, run a final delta, and give you enough logs to defend the cutover decision? If not, it may still move mail, but it will not give you control during the hours when control matters.

Phase 3: Make EWS Throttling Boring

EWS throttling is where many migrations start to look haunted. Jobs run well for a while, then throughput drops. Mailboxes remain “in progress” long after the dashboard estimate looked safe. Restarting the job may briefly help, then the same pattern returns. To a stakeholder, that looks like a bad migration tool. To an admin, it usually looks like back-off.

Microsoft applies throttling to protect Exchange Online service health, including limits affecting EWS activity. Practitioner migration guidance commonly points to EWS request ceilings in impersonation-based migrations and recommends tuning concurrency rather than simply adding more threads.[5] OneCal’s migration guide, for example, recommends running GWMME in multithreaded batches while keeping throughput around 4 GB per hour per server to avoid overrunning practical throttling limits.[5] That is vendor-authored guidance, not an independent benchmark, but it lines up with the platform behavior administrators see when EWS back-off begins.

The fix is not to chase the highest possible concurrency. It is to find the point where aggregate throughput is stable. If ten mailboxes move cleanly and fifty mailboxes trigger repeated back-off, the faster plan is usually closer to ten than fifty.

• Pilot with real mailbox sizes, not only newly created test accounts.
• Separate very large mailboxes from normal batches so one account does not distort the whole schedule.
• Increase concurrency gradually and watch sustained throughput, retry counts, and server-side errors.
• Run migration batches outside peak business hours where possible, especially if Exchange is also serving active users.
• Document the tested batch size so the cutover weekend does not become an improvisation exercise.

EdbMails describes the user-visible symptom well: slow Google Workspace migrations often involve EWS back-off, oversized batches, and concurrency settings that look efficient on paper but reduce real throughput once throttling starts.[2] Because EdbMails sells migration software, its product conclusions should be read with that bias in mind. Its description of the failure mode is still useful because it matches the official reason throttling exists: protecting service stability.

A Practical Batch Pattern

Start with a pilot batch containing a normal mailbox, a large mailbox, a shared mailbox, and at least one delegated or executive-assistant workflow. Measure the actual hourly transfer rate and error pattern. Then build production batches around stable throughput, not around department charts. Sales may need to cut over together for workflow reasons; archive-heavy users may need to migrate earlier because they consume the transfer window.

This is also where the Microsoft duration benchmark is useful as a sanity check. If several 10–50 GB mailboxes take days to complete, that may be normal depending on the path and throttling conditions.[1] If small mailboxes are also crawling, or if the job alternates between short bursts and long idle periods, investigate throttling, authentication, tool concurrency, or source health before assuming Gmail is the bottleneck.

Phase 4: Use Dual Delivery Before DNS Becomes a Blame Game

Dual delivery is the safety net for the awkward middle hours. During transition, inbound mail can be delivered to the existing Exchange environment and also routed to Google Workspace, so users do not depend on a single instant where every sender, resolver, and mail gateway agrees that the new route is live. Google documents dual delivery as a supported routing pattern for delivering mail to more than one inbox during a transition.[6]

For Exchange Online, practitioner guides commonly implement this with transport rules that redirect or copy mail toward the Google Workspace routing domain while Exchange remains authoritative during the transition.[5] The exact configuration depends on the tenant, accepted domains, and routing design, so it should be tested before production cutover with accounts that receive external mail, internal mail, calendar invites, and messages from systems such as scanners or CRM platforms.

• Confirm whether dual-delivered messages preserve the headers your security and compliance tools need.
• Test mail from external senders, internal Exchange users, Google users, and automated systems.
• Watch for loops before expanding the routing rule to the whole domain.
• Tell the help desk which inbox is authoritative during each transition window.

Dual delivery is not a substitute for migration. It keeps mail flowing while historical data and recent deltas catch up. That distinction prevents a common mistake: seeing new messages arrive in Gmail and assuming the migration is complete while yesterday’s messages are still only in Exchange.

Phase 5: Lower TTL Early, Then Cut MX With a Clock Running

Google warns that MX record changes can take up to 48 hours to propagate.[7] That is a planning ceiling, not a prediction that every sender will take two days. Many paths update faster. The problem is that you do not get to choose which customer, bank, payroll provider, or executive contact is behind a resolver that still has the old answer cached.

Lower the DNS TTL at least 48 hours before the planned MX change. A common operational target is 300 seconds, or 5 minutes, where the DNS provider allows it. Lowering TTL five minutes before cutover does not help resolvers that already cached the old longer value. The clock has to start before the cutover window, not during it.

The cutover watch should include more than “send a test from my personal account.” Test from different networks and systems that matter to the business. If finance receives bank notifications, test that route. If sales depends on CRM-generated mail, test that route. If executives receive mail through assistants and delegated calendars, test the workflow rather than only the mailbox address.

Phase 6: Run Delta Syncs for the Messages Users Will Actually Miss

The first migration pass moves history. The delta pass protects the recent window: messages, calendar updates, and mailbox changes that arrived after the first copy started. Google’s June 2025 Admin Console import update explicitly includes delta migration capability for supported Exchange Online imports, which is why it deserves a fresh look in 2026 planning.[3]

A final delta just before cutover reduces the gap. A second validation pass after MX cutover catches mail that arrived through the old path while DNS propagation was still uneven. Some migration teams define the delta window as the last several days of mail because that is where user memory is sharpest and business response time is most exposed. The exact window should come from the tool capability, mailbox volume, and cutover schedule, not from a generic promise of “zero downtime.”

• Run a pre-cutover delta after the main historical migration is complete.
• Keep dual delivery active while DNS propagation is still being observed.
• Run post-cutover reconciliation for users and shared mailboxes that received mail during the transition.
• Compare message counts, spot-check recent folders, and verify calendar behavior for high-risk users.

This is the phase that prevents the familiar Monday morning complaint: “Gmail works, but I am missing the message from Friday.” New mail arriving in Gmail proves routing works. It does not prove the recent Exchange window has been reconciled.

Phase 7: Decommission Exchange Only After the Old Path Is Quiet

Decommissioning is not the cleanup paragraph at the end of the project plan. It is the point where you decide Exchange is no longer the emergency fallback. That decision should wait until delivery lag has cleared, deltas have completed, mail routing is stable, and the help desk has no open pattern of missing-message tickets.

Google Workspace Migrate and other migration paths have documented edge cases and known issues, especially in complex environments, so the absence of a failed job is not enough by itself.[8] Check the things users actually depend on: recent mail, shared mailbox access, delegated assistant workflows, recurring calendar meetings, resource calendars, aliases, groups, and system-generated messages.

• Leave old Exchange routing observable until post-cutover mail flow is stable.
• Retain migration logs and batch reports long enough to answer missing-message claims.
• Disable or remove forwarding rules only after confirming they are no longer part of coexistence.
• Retire connectors, accepted domains, and transport rules in a staged order, not all at once.
• Keep a rollback or retrieval plan for archived Exchange data until retention requirements are satisfied.

The migration is not done when Gmail starts receiving mail. It is done when old and new delivery paths have been reconciled, recent messages are present, propagation lag has stopped mattering, and Exchange can be retired without becoming the hidden support system everyone still depends on.

References

1. Microsoft 365 and Office 365 migration performance and best practices, Microsoft Learn
2. Fix Slow Google Workspace Migration, EdbMails
3. Migrate email and calendar content from Microsoft Exchange Online to Google Workspace, Google Workspace Updates, June 2025
4. Migrate data from Exchange, Google Workspace Admin Help
5. How to migrate from Microsoft 365 to Google Workspace, OneCal
6. Set up dual delivery, Google Workspace Admin Help
7. Avoid issues when changing MX records, Google Workspace Admin Help
8. Google Workspace Migrate known issues, Google Workspace Migrate Help