The honest answer depends on things that can be counted before anything starts: how much mail there is, how many mailboxes, and who holds the keys to the old system. Here is where the time really goes.
Most of an email migration is background copying that nobody notices: mailbox data syncs to the new system while everyone keeps working in the old one. The visible part, the cutover, is a DNS change and a short verification, scheduled for a quiet moment. Staged this way there is no dead window where the business has no email.
What decides the calendar time is the size of the mailboxes, the number of them, how cooperative the old system is about letting data out, and, more often than anything technical, whether anyone can actually get into the old system and the DNS. We will not quote a number of days for a migration we have not scoped; what we can do is show you exactly which parts take the time, so any schedule you are given makes sense.
It helps to see that a migration has two different kinds of time in it, and only one of them should ever be felt.
The bulk of the elapsed time is the initial copy: every mailbox, folder by folder, from the old system to the new. Years of attachments add up, and providers deliberately limit how fast data leaves and arrives, which is rate limiting you cannot negotiate with. None of this touches the working day. Mail keeps flowing through the old system while the copy runs, and after the first pass, smaller catch-up syncs keep the new side current.
The switch itself is short and deliberately boring: the DNS records that route your mail are changed to point at the new system, authentication records for the new sender are verified, and test messages are sent both ways. It is scheduled for a quiet period not because it is risky when prepared, but because preparation is exactly what makes it unremarkable.
When someone describes a migration as a weekend of no email, they are describing the two clocks collapsed into one: data copied in a panic during the same window as the switch. That is a choice, and not a good one.
Who controls the old email system, the domain, and the DNS. The least technical step and the most common source of delay, because logins from three providers ago have a way of belonging to nobody.
Accounts, mailboxes, aliases, shared mailboxes and groups created on the new system, matching what actually exists rather than what people remember existing.
The long pole. Runs unattended in the background, throttled by both providers, while everyone works normally. Large archives simply take as long as they take.
After the first pass, each sync copies only what changed, so the new system sits a short distance behind live until the switch.
DNS routing changed, authentication records for the new system verified, mail tested in both directions. Short, scheduled, and dull when the previous steps were done.
The old system stays on while cached DNS answers expire across the internet, so nothing delivered to the old address is lost. Then, and only then, it gets decommissioned.
Notice what is not on the list: the number of employees, on its own, matters less than people assume. Ten tidy mailboxes move faster than three enormous undocumented ones.
The migration itself is a well-trodden path. What we add is the sequence discipline: audit first, copy in the background, switch once, lose nothing.
Not if it is staged properly, and this is the part worth being direct about: a well-run migration has no dead window. The copying happens in the background while everyone keeps working in the old system. The switchover is a DNS change that redirects new incoming mail to the new mailboxes, and old mail is already there waiting.
The migrations that produce downtime are the ones run in the wrong order: mailboxes switched before the data finished copying, or the DNS records changed before the new system was ready to receive. Sequence, not speed, is what protects you.
Access, not data. The technical copying is well-trodden; what routinely costs days is discovering that nobody has the admin login for the old system, the domain is registered to a web person who moved on, or the DNS is controlled by an agency that takes a week to answer email.
Every one of those is findable in advance, which is why the audit comes first. A migration that starts with all the keys in hand tends to run at the speed of the data. One that starts without them runs at the speed of the slowest inbox.
Usually it is not missing, it is arriving at the old address. DNS changes take time to reach every mail server on the internet, because servers cache the old answer until it expires. During that window some senders reach the new mailbox and some still deliver to the old one, which is why the old system stays running and monitored after the cutover rather than being switched off the same day.
Planned for, this is a non-event: the stragglers get copied across and nothing is lost. Unplanned, it looks exactly like vanished mail and produces exactly that phone call.
It can, in both directions. Mail is trusted partly on authentication records that live in DNS, and a migration replaces the system those records were written for. Carry them across unchanged and they now describe the wrong sender; the new provider's records have to be set up and verified as part of the cutover, not remembered afterwards.
Done right, a migration is often the moment deliverability improves, because the records finally get set up properly. If your mail already lands in spam today, that diagnosis is written up in business email going to spam.
Move mailboxes to a new provider without losing mail or downtime.
Business email, files and calendars on your own domain.
The settings worth getting right when you set up or inherit a tenant.
Authentication, reputation, and the fixes that actually move the needle.
DNS records, nameservers, SSL, caching and protection, configured properly.
Plain definitions for the records and terms you get asked about.
Tell us what you are on now and where you want to be. The audit that answers the timeline question is the same one the migration starts with anyway.