Mail Server Migration Stories


EQ Forum Admin
Staff member

Do you have any mail server migration stories to share?

Any experience with mail servers or appliances that were easier or more difficult that usual to migrate away from.

Ten years ago tonight I was on the road driving to a 3rd party mail hosting provider and picking up a hard drive full of migration data for our customers at the time that I would need move during an platform migration that night.

Maybe your story is from the user perspective? Did you ever have an email service provider that you wanted to leave but for some reason the process was unusually difficult?


IMAP Tools
Zimbra has a comprehensive set of tools that make migration easier than do many other mail servers.

A couple of years ago I had occasion to migrate 25,000 users from a Zimbra server. The requirement was to create user accounts on our server, copy their folders, messages, address books, and calendars and to do it overnight.

The Zimbra zmprov utility was used to export the user account information and build a list of the users to be migrated.

Normally an IMAP script would have been used to copy the e-mail messages but because we also needed to do calendars and address books I used the Zimbra zmmailbox utility to export everything (folders, messages, calendars, address books) to tgz files. The files were FTP'd to the new server where scripts loaded the e-mail (using IMAP), calendar, and addressbook data.

Because of the size of the migration --- and the need to do it in such a short timeframe --- I did a "pre-migration" of the e-mail messages during the prior week. Thus when the night of the actual migration arrived most of the e-mails had already been transferred and all that had to be done was to pick and copy messages that had arrived since the pre-migration.

Doing an incremental copy of messages was simplified by the fact that zmmailbox supports an "after:<date>" option. That greatly reduced the amount of data that had to be exported and copied on the final night.

All in all, I'd have to say I was greatly impressed by the breadth and quality of Zimbra's utilities.


IMAP Tools
Some notes on the throttling that Microsoft Office365 does on IMAP connections from Gilles Lamiral's IMAPsync mailing list.

This is highly technical data but it shows that you can see problems when moving a lot of IMAP data into Office365 (and Exchange for that matter) especially during a migration.

The throttling that [Office365] enforces on IMAP connections:

ImapMaxConcurrency : 20
ImapMaxBurst : 240000
ImapRechargeRate : 360000
ImapCutoffBalance : 600000

The figures (outside of the concurrency value) are measured in milliseconds and represent the amount of time over a 1 hour period. The max burst value represents the amount of time that can be spent before any throttling is done (microdelays), the recharge rate shows how much budget will be added over a 1 hour period (constant process), and the cutoff balance represents the amount of budget that can be used after which a backoff request (exception) is generated.

As far as the throttling bit, our Datacenter team confirmed from the logs that the account is being throttled. They indicated that the disconnects you were seeing were a result of authentication failures (because the account was throttled).

[Microsoft] recently added an optimization to not cause auth to fail if the account is throttled but all subsequent commands will fail with invalid state error due to throttling.

The throttling here is occurring because you are using the 3rd party IMAPSync tool that in essence is acting as an IMAP "client" to import the data. There isn't specifically a problem with that, but as I surmised early on, this does result in the User throttling coming into play.

The way throttling has been implemented in Exchange 2013 is that each user receives a MaxBurst value - this is the "budget", or amount of work they can do in a 1 hour period without being throttled. At the same time, as the budget is being used, we are "recharging" the budget (Recharge Rate). If you use up your MaxBurst value, we will begin inserting MicroDelays. Basically this means that we will begin slowing down our responses to commands. You won't know this is happening, as it is designed to not be intrusive to the end-user. It is only when you reach the CutoffBalance that we issue a backoff exception. At this point, you would see the error responses due to invalid state.


EQ Forum Admin
Staff member
Has your experience after a pre-migration been that either an IMAP Sync, or an IMAP Copy after Date X, is significantly faster than the other for the final sync of large volumes of email? Maybe a third option I didn't mention? It probably depends on the platforms involved. My preference has generally been to have access to the actual mailboxes & folders, rsync to keep the source and target platform storage in sync, and then a local mailbox format conversion during the migration window when needed. When the source platform storage is not accessible in that way the IMAP Tools come in very handy! I agree there is a lot more to an email migration than moving email. All of the extras, including passwords, quotas, and webmail data such as contacts & filters, not to mention any changes in webmail interface or anti-spam mechanisms, are all important to document and communicate. Email is an experience, and people don't like change.


IMAP Tools
No, but I've had customers who have done migrations to Exchange-based servers like Office365 so I am always interested in such info. Like Gmail Exchange throttles IMAP connections which can cause problems for migration tools.

(I'll post some info on Gmail throttling in a later reply).

Another issue you run into with Exchange is that it will terminate an IMAP connection after 10 errors. A migration tool has to count errors reported by Exchange and disconnect/reconnect before the 10th error (which my tools do).


EQ Forum Admin
Staff member
Are you a user getting your email migrated?

Here are some actions that users can take to help speedup and make sure the process goes smoothly:
  • Cleanup your Inbox and Folders
  • Download or delete large email attachments
  • Delete old emails that you no longer need
  • Carefully read any migration notifications with information about the process and settings changes
Last edited:


EQ Forum Admin
Staff member
Lets add some more tips to the list:

  • Test test test!
  • Try to break your migration process and throw some crazy test accounts at it before the real migration(s)
  • When possible divide a migration into several small batches instead of one big migration
  • Avoid overlapping email migrations during other scheduled projects or expected customer impacting events