How Long Does Email Migration Take? Factors Behind Speed
Confused about how long does email migration take? Don’t worry, read and learn everything that determines total duration.
TL;DR
- Benchmark: Generally, the transfer rate is between 0.5 GB/hr and 1 GB/hr per user account. When moving server-to-server.
- Bottleneck: Google, Microsoft, & even locally run private mail servers apply provider throttling. Putting an upper limit on both data ingestion and extraction.
- Strategy: My recommendation is to schedule transfers during periods of lower server load, such as holidays or off-hours, to reduce how long email migration takes.
How Long Does Email Migration Take? The Reality Check
There is a misconception in the industry. Users believe that if they just improve the internet bandwidth, transfer speeds automatically improve.
This is not true. A hidden factor, “Provider Throttling,” has a much greater impact on the number of mailboxes you can move at once. .
Major email service providers (Microsoft and Google) enforce a per day and even per hour API limits. This is done to protect servers against malicious actors.
Organizations that run on-premises email servers follow a similar rule.
Moreover, other technical aspects play a role as well. For example the average mailbox file size, number users you are planning to move, and what kind of hardware you possess.
So you can’t calculate exactly how long does email migration take but you can still estimate it.
Find the Approximate Time via A Tabular Distribution
For IT admins who have a B2B transfer on the horizon can start the estimation by figuring out the raw data that is in the server. Make sure you also consider the daily increase in volume while developing a projection.
The process you opt for must have a concurrency control mechanism (how many mailboxes move together), as it will help you to shorten the overall timeline.
See the table below and understand the approximate duration:
| Business Size | Mailbox Count | Estimated Duration | Strategy |
| Small Business | 1 – 50 Users | 1 – 3 Days | “Big Bang” (Single Cutover) |
| Mid-Size | 50 – 500 Users | 2 – 4 Weeks | Pre-Stage Migration |
| Enterprise | 500+ Users | 1 – 3 Months | Rolling Batches / Phased |
Disclaimer: This is a projected timeline and not an official answer, so take these metrics with a grain of salt.
What Determines How Long Does Email Migration Take?
Once you understand the bottlenecks, you can plan to bypass them. First things first, your internet connection speed is not something you should worry about much.
Here are the real points that dictate the pace of your migration.
1. Provider Throttling
I explained this term earlier in the text. That was a more functional definition, so let me clear things up a bit.
Think of provider throttling as the gate to enter or exit a building. The size of the gate can’t be changed. So even if multiple people are carrying boxes, they can’t enter/exit all at once.
Major providers publish their numbers:
| Provider | Protocol / Area | Official Limit | Scope |
| Google Workspace | Gmail API quota | 15,000 quota units/min per user | API call rate |
| Gmail API quota | 1,200,000 quota units/min per project | API call rate | |
| SMTP send | 2,000 msgs/day per user | Daily send limit | |
| SMTP recipients per message | 100 via IMAP/SMTP clients | To, Cc, Bcc count | |
| IMAP session length | ~24 hours continuous | Maximum per session | |
| Microsoft 365 | Graph API global | 130,000 req/10s per app | All tenants |
| Graph API per tenant | 350 req/10s per app | Same tenant | |
| Exchange SMTP concurrent | 3 connections | Sending via SMTP | |
| SMTP send rate | 30 msgs/minute | Outbound SMTP client send |
Note: Your your Office 365 plan has nothing to do with these limits.
2. Item Count (and Volume)
Another one of the cloud migration challenges is to understand that the number of items matters more than the total size of the data.
So it will take you more time to move (100x) 10 MB mails than (20x) 50 MB mails, despite both scenarios having nearly the same overall volume.
This is because every time a new message is processed, a distinct server handshake takes place, the most time-consuming ritual of the entire process.
Take the Closest Estimation of the Actual Deadline
Benchmarks are fine, but often IT admins require something presentable. Especially when they have to explain their findings to a non-technical audience. I have been in a similar situation before, and for that, I have come up with a formula:
Total Time = ((Total Data Volume ÷ Throughput Speed) / Concurrency) + 20% buffer
Here is what the variables mean:
- Total Data (GB): The complete sum of all data inside every single mailbox in your organization.
- Throughput (GB/hr): The average speed allowed by the destination server.
- Concurrency: The maximum number of accounts being moved together at the same time.
- 20% Buffer: This buffer helps to take into account the hidden variables that disrupt migrations.
Pro Tip: In this formula, the variable that you have the most control over is the Concurrency. So choose a tool which is the best IMAP to IMAP Migration software and contains a built-in Concurrency adjustment mechanism.
Download the demo today and speed up your inter-account mailbox movements.
Strategies That I Used to Accelerate Email Movement
Prepare the server and the data: This has been my guru mantra for developing a foolproof cloud migration strategy. You don’t always have to move every last bit of data that is on the source server. Intelligent filtering can help you save up a lot of time that would have otherwise been wasted on migrating unnecessary mailboxes.
Reduce the background processes: Ideally, you would want your entire hardware to be dedicated to migrating mails to finish it as early as possible. However, I know that practically it isn’t possible. Instead, try to maximise the total available resource by shutting of non critical process ahead of the migration date.
Bottomline
So now you have a solid idea of how long does email migration take and you can explain the same to all stakeholders. I explained that platform throttling is the strongest parameter determining the overall duration. At the same time, it is also the factor you have the least control over. One key finding of this discussion is that you should use an email migration tool that has built-in concurrency management options.
FAQ
Q: Is downtime included in the overall duration? How can I minimise it?
Yes, it is a major chunk of the total time it takes to change email providers. If you implement a pre-stage strategy, such as moving recent emails first and copying the rest of the data in the background. You only ever face downtime the moment you have to update the MX Records (DNS propagation).
Q: Why is there so much variation in self-reported metrics on how long email migration takes?
This is purely a reflection of how different people use emails. Some are strong followers of the zero email philosophy. While others keep multiple copies of the same message. So the data that is there in the source varies drastically, and so does the time to migrate it.
Q: If I keep using my email at the time of transfer, does it affect the overall duration?
Not in a way you would expect. The process you use for shifting email data takes the last email inside the inbox as the starting point. Any other emails that enter the inbox after that need to be moved via the incremental transfer facility. So it would increase the total time but only by a slight amount, i.e., if the migration was supposed to end at 3 pm, it would run till 6 pm.