Business

Migrating company mail: ten mailboxes and up

Moving one mailbox is an evening of technical work. Moving forty is a week of coordination in which the technical part takes the least time of all.

What breaks at scale

A single migration forgives improvisation: wrong click, restart, forget. Across forty mailboxes every small thing is multiplied by forty, and a technical slip turns into an organisational one.

Three problems show up every time: nobody has the exact list of mailboxes, some passwords are unknown, and staff learn about the move at the moment their mail stops working.

The working order

A sequence that holds up across dozens of mailboxes. The first two steps take longer than the migration itself and save the most.

  1. Build the exact inventory: address, size, owner, and whether the mailbox is needed at all. Mark aliases separately — they are not migrated, they are recreated.
  2. Create the mailboxes on the new server with the same addresses and issue app passwords or temporary ones.
  3. Start with one mid-sized mailbox: it reveals the real speed and catches configuration mistakes before they multiply.
  4. Migrate the rest in batches rather than all at once: providers cap simultaneous connections per account or per address.
  5. Compare per-folder message counts for each mailbox and record the result in the inventory.
  6. Switch MX, then run a second pass over every mailbox a day later.

What to tell your colleagues

A note the day before the switch removes most of the support calls. It needs four things: when it happens, what to do in their mail client, that the old mail is already there, and where to write if something looks wrong.

Two normal side effects are worth mentioning up front: messages may re-sort by the date the new server received them, and mobile clients will ask for the password again.

Who can run it

A company migration does not have to be a cloud one. If policy forbids sending mailbox passwords outside, a local client does exactly the same work on your own machine: credentials and mail never leave the perimeter.

That also answers the volume question: a local migration has no gigabyte cap, and forty mailboxes of ten gigabytes each is an ordinary case.

FAQ

Common questions

Can all mailboxes be migrated at once?

Technically yes, practically no: providers cap simultaneous IMAP sessions, and batches of three to five usually finish sooner than everything at once.

What about mailboxes of former employees?

Migrate them as an archive and leave them closed on the new server: the mail stays available to the company and nobody reads the mailbox.

Do I need the staff passwords?

You need IMAP access to each mailbox. In practice that means app passwords, issued by the administrator or by each user.

How long does it take?

Estimate from the largest mailbox and add headroom for batching. Provider speed figures are in a separate article.

Where to next

Move your mail with MoveMailbox

More posts

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.

Code on GitHub · built on imapsync · no sign-up