Migrate Large Google Workspace Mailboxes

What Makes a Google Workspace Mailbox "Large" in Migration Terms

Size alone is not the only variable that matters. A 30 GB mailbox made up mostly of plain-text threads migrates faster and more predictably than a 15 GB mailbox packed with 20 MB video attachments or nested folder structures carried over from years of label reorganization. Three factors tend to drive complexity more than raw gigabytes:

• Attachment density: Mailboxes with a high ratio of large binary attachments (design files, scanned contracts, video assets) consume more API calls and bandwidth per item than text-heavy mailboxes of the same size.
• Label and folder depth: Gmail's label system does not map one-to-one to folder structures in Exchange or Office 365, and mailboxes with deeply nested or overlapping labels need more careful mapping to avoid duplication.
• Item count, not just volume: A mailbox with 200,000 small items can take longer to process than one with 50,000 larger items, since each item still requires a discrete API call regardless of its size.

Before starting, it helps to run a scan of the source mailboxes to identify which of these factors apply. EdbMails allows administrators to preview mailbox contents and attachment sizes before committing to a full migration, which makes it possible to flag outliers early rather than discovering them mid-run.

How Large Attachments Affect Migration Reliability

Attachments are usually where large migrations fail, not the email body text. A few specific issues come up repeatedly:

API payload limits

Google Workspace and the destination platform (Office 365, Exchange, or IMAP) each enforce their own limits on message and attachment size. Gmail itself caps individual attachments at 25 MB for sending, but stored mailbox items, especially older ones migrated from other systems, can exceed platform-specific thresholds on the receiving end. Items that exceed the destination's limits need to be flagged and handled separately, either by compressing them, splitting them, or routing them through a shared drive link instead of a direct attachment.

Timeout risk on individual items

A single 20 to 25 MB attachment takes measurably longer to transfer than a handful of small messages, and if a connection drops mid-transfer on a large item, that item needs to be retried rather than the entire batch.

Corruption during interrupted transfers

If a migration job is interrupted while a large attachment is mid-transfer, the item can end up partially written on the destination side. A migration tool needs to detect this and reprocess the item cleanly rather than leaving a corrupted or incomplete copy behind.

EdbMails handles this at the item level; each email and its attachments are treated as a single transactional unit, so a failed or interrupted transfer on one item does not corrupt the destination mailbox or require the whole job to restart. Failed items are logged and can be reprocessed individually during a follow-up incremental pass, described further below.

Recommended Network and Bandwidth Conditions

Migration speed is governed as much by network stability as by raw throughput. A few practical guidelines:

• Use a wired connection where possible: Wi-Fi introduces packet loss and latency variance that Ethernet does not, and for a migration job running over several hours, that variance adds up in the form of retried requests.
• Plan for sustained, not peak, bandwidth: A connection rated at 100 Mbps but shared across an office network will not sustain that speed for the duration of a multi-hour migration. Estimate based on available bandwidth during business hours, not the connection's advertised maximum.
• Account for Google's own API rate limits: Even with unlimited local bandwidth, Google Workspace enforces per-user and per-project request quotas. A migration tool that manages these limits automatically, rather than hammering the API and triggering throttling, will finish more reliably even if it is not the fastest on paper. EdbMails includes automatic request throttling to stay within Google's published limits, which reduces the number of temporary blocks or slowdowns during a run. Organizations running Exchange as the target should also review the Exchange throttling policy, since the destination side enforces its own limits independently of the source.
• Run large migrations during off-peak hours when the option exists: This reduces contention with other office traffic and generally results in more consistent transfer speeds.
• Check available disk headroom on the migration machine, even though EdbMails does not cache mailbox content locally during transfer. A small amount of metadata is stored locally to support incremental migration, and around 100 MB of free space is recommended for the application itself. Full system requirements are listed in the system requirements and supported platforms guide.

Staging the Migration With Size and Date Filters

Rather than migrating an entire large mailbox in a single continuous run, breaking it into stages by size or date range gives administrators more control. It makes it far easier to isolate problems.

Filter by date range first

Splitting a mailbox into quarterly or yearly chunks lets you migrate older, less time-sensitive data first and current data last, minimizing the window during which the user's most recent mail is in transition. It also means that if something goes wrong in one date range, only that segment needs to be rerun, not the entire mailbox history.

Filter by folder or label for targeted testing

Migrating a single folder, such as an archive or a specific project label, is a useful way to validate mapping and attachment handling before committing to the full account. This is particularly useful for mailboxes where certain folders are known to contain unusually large attachments.

Combine filters for oversized mailboxes.

For accounts in the tens of gigabytes, combining a date filter with a folder filter can break the job into batches small enough to complete predictably within a single session, rather than running as one long, unbroken transfer that has to be restarted from scratch if it fails near the end.

EdbMails supports both date range and folder-based filtering when configuring a migration job, letting administrators define exactly which data moves in each pass. This is set up during the migration scenario configuration step, before the job is scheduled to run.

Handling Interruptions Without Duplicating Data

Large mailbox migrations that span multiple sessions run into a common problem: restarting from the beginning duplicates everything that already transferred successfully. This is where incremental migration matters.

Instead of comparing entire mailboxes on every run, an incremental pass identifies only the items that were not previously transferred, based on item-level metadata rather than a full mailbox comparison. This makes it possible to:

• Resume a migration that was paused or interrupted by a network drop, without reprocessing already-migrated items.
• Run a final sync closer to cutover, capturing only the mail that arrived since the previous pass, which keeps the user's downtime to a minimum.
• Rerun a failed batch (for example, one containing several oversized attachments that needed manual review) without touching the rest of the mailbox.

For more details, refer to the incremental migration guide.

Validating Migration Completeness After the Run

Once the migration completes, validation confirms there was no data loss, not the absence of error messages during the run. A migration report should account for:

• Total item count on the source versus the destination, broken down by folder or label.
• Items that failed to migrate, with a reason (oversized attachment, unsupported format, permission issue).
• Attachment-specific failures separated from message-body failures, since these usually require different remediation steps.

Administrators should reconcile this report against the pre-migration mailbox scan mentioned earlier. If the counts do not match, the incremental migration pass can be used to close the gap without re-running the entire job.

A Practical Checklist for Large Gmail Migrations

1. Run a pre-migration scan to identify mailbox size, attachment density, and label structure.
2. Confirm network conditions can sustain the transfer for the expected duration, and schedule off-peak where possible.
3. Set up a date range or folder filters to break the mailbox into manageable batches.
4. Migrate a test batch first to validate mapping and attachment handling before running the full job.
5. Monitor for API throttling or timeout errors during the run and let the tool's retry logic handle transient failures.
6. Run an incremental pass to capture any items missed in the initial run and to sync last-minute changes before cutover.
7. Reconcile the final migration report against the original mailbox scan.

Frequently Asked Questions

1. What is considered a large Google Workspace mailbox for migration purposes?

   There is no fixed threshold, but mailboxes above 15 to 20 GB, or those with a high proportion of large attachments, generally benefit from a staged migration approach rather than a single continuous migration run.

2. Can large attachments cause data loss during migration?

   Attachments that exceed the destination platform's size limits, or transfers interrupted without proper retry handling, are the most common cause of incomplete migrations. Filtering, item-level transaction handling, and incremental follow-up passes help prevent these issues.

3. Does migrating in batches slow down the overall process?

   Not significantly. Batching by date or folder adds a small amount of setup time but reduces the risk of restarting a large migration job after a failure, which usually saves more time overall.

4. How is duplicate data avoided when a migration is resumed?

   Incremental migration compares item-level metadata with data already transferred, so only new or missing items are processed during resumed or follow-up migration runs.

5. Does a large mailbox migration cause any downtime for the user?

   No. The mailbox remains online during migration, so users can continue sending and receiving email while data transfers in the background. A final incremental pass near cutover captures any new items that arrived after the main migration completed.

6. How long does migrating a large Gmail mailbox typically take?

   The duration depends more on attachment volume and item count than on total mailbox size. Mailboxes with many large attachments take longer per gigabyte than text-heavy mailboxes, and running migrations in parallel across multiple mailboxes reduces total project time even though it does not increase the speed of a single mailbox migration.