Moving a company’s mail differs from moving one mailbox organisationally, not technically: thirty mailboxes mean thirty passwords, thirty owners and one evening when everything has to work. Below is the plan that removes the main risks: a pilot before the bulk, waves instead of "all at once", and a reconciliation that proves nothing was lost.
Inventory: no plan without it
The first thing you need is a table of mailboxes. Not "about forty" — an exact list with volumes, because both the schedule and the plan on the receiving side depend on it.
Address, owner, size and message count for every mailbox.
Shared and functional mailboxes (info@, sales@) — separate credentials, often a separate owner.
Mailboxes of people who left: usually archived rather than moved onto the new platform.
The total volume — it decides the migration time and the space needed on the new plan.
Access: where preparation usually stalls
In cloud services the ordinary password rarely works over IMAP, and that tends to surface at the worst possible moment.
Microsoft 365: basic authentication for IMAP is off by default. The working route is app passwords with MFA enabled; if tenant policy forbids them, an administrator opens access.
Google Workspace: IMAP is enabled in the settings, and app passwords are issued only when 2-step verification is on.
Own server or hosting: mailbox passwords are usually enough, but check in advance that IMAP is not blocked by a firewall.
Issue single-purpose passwords for the migration and revoke them right after — an app password is revoked in one click.
A pilot, then waves
Going bulk without a pilot is the expensive mistake: if something is wrong with access or folders, you will learn it thirty times in a row.
Take one average mailbox and migrate it end to end. Measure the time — the whole plan scales from it.
Reconcile by folder: message counts on both sides have to match.
Split the rest into waves of five to ten rather than all at once: providers cap concurrent IMAP sessions.
Migrate the least active mailboxes first and management and sales last.
Cutover and reconciliation
A migration needs no downtime, so the MX switch happens after the bulk is already on the new side.
Switch MX once every wave is done.
A day later, re-run the migration across all mailboxes: it collects what arrived during the switch and creates no duplicates.
Reconcile folder counts once more, and only then retire the old mailboxes.
Keep the old system reachable for at least a week — cheaper than recovering a single lost message.
What an IMAP migration does not solve
Worth telling management up front rather than discovering on moving day.
Calendars, contacts and tasks — moved with the platform’s own tools.
Delegation rights ("the assistant sees the director’s calendar") are configured again.
Exchange public folders — a separate store that IMAP cannot see.
Outlook rules, signatures and auto-replies — set up on the new side.
How long does a 30-mailbox company migration take?
Count by volume, not by mailbox count: the bottleneck is the provider’s export speed. The pilot mailbox shows the real rate and the rest scales linearly from it. For Microsoft 365 our measurements land around half a gigabyte per hour per mailbox.
What about mailboxes of former employees?
They usually go into a single archive mailbox on the new side instead of consuming licences. Over IMAP it is the same migration, only the destination is the archive.
Can we migrate while people are working?
Yes. The source is never modified, messages are only read. The only thing to schedule is the moment their mail clients get the new settings.
Do we need administrator access?
Not always. If every mailbox has a password (or an app password), no administrator is involved. One is needed where tenant policy forbids app passwords.
Find out how big your mailbox is. It costs nothing.
Connect two servers, look at the size and decide. Or take the client and keep everything on your side.