How Long Does an Email Migration Take? Realistic Timelines by Size

"How long will this take" is the second question every email migration project gets, right after "what does it cost". The honest answer is "it depends on six things", but that does not help you plan. This post gives you realistic timeline ranges by organisation size, the math behind the ranges, and the variables that push you toward the optimistic or pessimistic end of each band. Use these numbers to plan, not to quote — your specific environment will sit somewhere inside the range.

The six things that determine migration duration#

Before the size tables, the inputs that matter.

Mailbox count. Most obvious, least useful in isolation. 100 mailboxes of 200MB each is a different project from 100 mailboxes averaging 25GB.

Total data volume. Sum of mailbox sizes. This sets the lower bound on how long bulk copy takes.

Per-mailbox throttling. Source providers throttle per account. Gmail caps IMAP fetch rates aggressively. Microsoft 365 throttles via TenantThrottlingPolicy. iCloud has undocumented limits that engage above ~3 concurrent connections per account. Your batch size cannot exceed what the source allows.

Concurrent mailbox parallelism. How many mailboxes you can move at the same time. Tool-dependent and provider-dependent. Realistic numbers are 5–20 mailboxes in parallel for most setups.

Folder count per mailbox. Each IMAP folder requires a separate traversal. Heavy folder hierarchies multiply the per-mailbox time even when total data is small.

Complexity of the destination. Microsoft 365 with hybrid Exchange, AD attribute sync, and Outlook profile remediation has overhead that pure-IMAP destinations do not.

The headline duration estimates below assume average case. Mailboxes with very large messages, very deep folder trees, or unusual character encodings will push you to the upper end.

1–25 mailboxes: one week#

The smallest projects are constrained by calendar more than by data. The bulk move is fast; the planning around it takes most of the week.

Realistic schedule:

• Day 1: Discovery and tool setup. Inventory mailboxes, capture sizes, test authentication to source and destination.
• Day 2: Pilot 2–3 mailboxes. Verify the migration tool works end-to-end with your specific provider pair.
• Day 3: Pilot validation. Have pilot users sign off.
• Day 4: Production migration begins. For 25 mailboxes, this is usually a single overnight run.
• Day 5: Cutover. Update MX, run final delta, communicate.
• Day 6: Validation. Folder counts, shared mailbox access, mobile devices.
• Day 7: Closeout. Documentation, source decommission planning.

Throughput math. 25 mailboxes averaging 5GB = 125GB total. At realistic IMAP throughput of 50–150 MB/min per mailbox with 5 mailboxes in parallel, that's 200–600 minutes of compute. Comfortably fits in an overnight window with margin.

What pushes you to two weeks. Unusual source (legacy hosted Exchange, ProtonMail Bridge, obscure cPanel IMAP). One or two very large mailboxes (50GB+). Stakeholder availability constraints, especially around cutover scheduling.

For smaller projects, the migration checklist is enough planning artifact; you do not need a full project plan.

25–100 mailboxes: two to three weeks#

This is the typical SMB project. Now you need a pilot phase, a real batch plan, and meaningful communications.

Realistic schedule:

• Week 1: Discovery (3 days) and design (2 days). Tool selection, batch planning, communication plan drafted.
• Week 2: Pilot (5–10 mailboxes) over 3 days, validation for 2 days. Pre-stage of production data begins late in the week.
• Week 3: Production cutover. Cutover weekend, validation on Monday-Tuesday, closeout by Friday.

Throughput math. 75 mailboxes averaging 8GB = 600GB total. With 10 mailboxes parallel at 100 MB/min each = 1 GB/min aggregate = 600 minutes of bulk copy = 10 hours. Pre-staged over 2 days, the cutover-window delta is small.

What pushes you to four weeks. Cross-provider authentication setup (Google Workspace OAuth scope review, M365 service principal creation, custom SAML). Compliance review if the data is regulated. End-user training if the destination UI is materially different.

The big risk at this size is treating it like a 25-mailbox job and skipping pilot. A surprise in pilot is recoverable; the same surprise during production migration is a missed deadline.

100–500 mailboxes: four to eight weeks#

Mid-market projects. Now you need a project manager, formal stakeholder mapping, and batched execution rather than single-window cutover.

Realistic schedule:

• Weeks 1–2: Discovery. Larger inventory, more shared mailboxes, more integrations to map. Stakeholder workshops.
• Week 3: Design and tool selection. Security review. Communication kickoff.
• Week 4: Pilot. 15–25 mailboxes from mixed departments.
• Week 5: Pilot validation. Adjust based on findings. Pre-stage planning.
• Weeks 6–7: Pre-stage and delta syncs. Most data moved in this window.
• Week 8: Cutover weekend and validation week.

Throughput math. 300 mailboxes averaging 10GB = 3TB total. Pre-stage at 50–100 GB/hour aggregate = 30–60 hours of pre-stage time. Spread over 5 days, this runs in the background while users continue normal operations.

What pushes you to twelve weeks. Hybrid Exchange in the source environment. Cross-tenant Microsoft 365 with public folders. Heavy compliance regime (HIPAA, FINRA). Multinational team requiring local-language communications and per-region cutover windows.

For projects in this range, the project plan is mandatory, not optional.

500+ mailboxes: eight to sixteen weeks#

Enterprise scale. Often involves multiple business units, regulated data, or M&A circumstances. Pure technical execution is no longer the bottleneck; coordination is.

Realistic schedule:

• Weeks 1–3: Discovery and stakeholder alignment. Multiple workshops. Cross-functional steering committee established.
• Weeks 4–5: Design, security review, compliance signoff.
• Weeks 6–7: Pilot, possibly multi-phase (technical pilot, then department pilot).
• Weeks 8–12: Production pre-stage in batches. Each batch sized to a department or business unit.
• Weeks 13–14: Phased cutover. Different batches cutover on different weekends.
• Weeks 15–16: Validation and closeout, including formal sign-off from compliance and security.

Throughput math. 1500 mailboxes averaging 15GB = 22.5TB total. Now you are constrained by provider throttling on both source and destination. Microsoft 365 destination ingestion throttles per-tenant; Gmail source has per-account caps. Realistic aggregate throughput is 200–500 GB/hour. Total pre-stage time is 45–110 hours, spread over multiple weeks of background runs.

What pushes you to twenty-four weeks. Multi-country operations with data residency requirements. Hybrid Exchange decommissioning as part of the project (this alone can be a 4-month workstream). Concurrent M&A activity that changes the destination mid-project.

At this scale, running parallel mailbox migrations is unavoidable — you cannot complete a 1500-mailbox project as a single linear queue. Batches run in parallel across different parts of the org.

Throttling math you need to know#

Source and destination throttling is the most common reason actual timelines miss estimates. The numbers below are approximate; specific providers shift their limits periodically.

Gmail / Google Workspace. IMAP fetch rate caps engage at roughly 2,500 messages per hour per account. Beyond this you see slowdowns rather than hard errors. Concurrent connections per account cap at 15, but practical performance peaks around 7–10.

Microsoft 365 / Exchange Online. Per-mailbox throttling via TenantThrottlingPolicy. EWS migrations cap around 20 concurrent mailboxes per service account. Graph-based migrations have similar limits with different headers.

iCloud. Tightly throttled. 3–5 concurrent connections per account before degradation. Migrations over 50GB per mailbox often need to be split across multiple sessions.

Yahoo Mail. Surprisingly tolerant on read, throttles on writes (so destination-side migrations into Yahoo are slow). Plan 30–50% longer when Yahoo is the destination.

Hosted Exchange / cPanel IMAP. Wildly variable. The hosting provider's throttling configuration matters more than the protocol. Test in pilot.

Fastmail, Zoho, Fastmail-class providers. Generally permissive. Plan for typical throughput numbers above.

Batch sizing rules of thumb#

A few defaults that hold across most setups:

• Parallel mailboxes per batch. 5–10 for most providers, 3 for iCloud, 15–20 for permissive destinations.
• Mailboxes per batch. 50–150 for staged migrations. Below 50 wastes coordination overhead; above 150 makes a single batch's failure too costly to retry.
• Time per batch. Plan for the longest mailbox in the batch, not the average. The batch finishes when the slowest one finishes.
• Gap between batches. 30–60 minutes for delta syncs and validation. Do not start the next batch until the current one is verified.

For staged migrations specifically, cutover vs staged vs hybrid covers when staged is the right approach.

What pilots tell you about timing#

The pilot is also your most accurate timing benchmark. Measure these during pilot:

• Total elapsed time for the pilot batch.
• Wall-clock duration per mailbox (not just sum-of-sizes).
• Error rate by category (auth, throttle, malformed message, encoding).
• Hours of engineer time per 100 mailboxes (including babysitting failed batches).

Extrapolate to production. If pilot achieved 200 MB/min aggregate throughput across 5 parallel mailboxes, production at 10 parallel will likely hit 350–400 MB/min (less than linear scaling, because per-mailbox throttling kicks in earlier than aggregate limits).

A pilot that finishes faster than expected does not mean production will. Pilots often draw a happier cross-section of mailboxes than production reveals.

Cutover weekend itself#

Regardless of org size, the cutover window has a similar shape:

• T-4 hours: Final delta starts.
• T-1 hour: Pre-cutover comms sent. Source sending stopped.
• T-0: MX records updated. SPF/DKIM/DMARC reviewed.
• T+30 min: Delta completes. Validation checks begin.
• T+2 hours: User access enabled on destination.
• T+24 hours: First-day monitoring complete.

The cutover itself is rarely the long part. For a well-pre-staged project, cutover technical work fits in 4–6 hours. The other 18 hours of the weekend are buffer for the things that go wrong.

When timelines slip#

Most migrations slip by 10–25%. The common causes:

1. Discovery missed a category. A forgotten distribution list, an alias forwarding externally, a shadow mailbox. Discovery extends to handle it.
2. Authentication setup took longer than expected. OAuth scope reviews, service principal approvals, MFA configuration on service accounts.
3. Pilot surfaced an unexpected issue. Almost always good — better in pilot than in production. Add a week for remediation.
4. Cutover date was unrealistic. Frequently the date was set in the kickoff meeting based on optimism rather than data. Reset.

A 10–25% slip on a 4-week project is one week. Acceptable. A 100% slip means the discovery phase was wrong; reset the project.

Putting it together#

The shortest honest answer to "how long will this take" is: "Tell me your mailbox count, total data volume, source provider, destination provider, and how much pre-cutover communication you want, and I will give you a date." Without those inputs, the question is unanswerable.

For planning purposes, this table holds:

• Up to 25 mailboxes: 1 week
• 25–100 mailboxes: 2–3 weeks
• 100–500 mailboxes: 4–8 weeks
• 500+ mailboxes: 8–16 weeks

If you are sizing your specific project against these ranges, run through the migration checklist and project plan in parallel. The checklist confirms you know what you have; the plan confirms you know how to move it. Together they sharpen the timeline from "an estimate" to "a commitment".

FAQ#