In a rehearsal cutover, imapsync told us to run it once more with --delete2. We did, and it deleted three emails that had reached the new server after the MX change, along with 30 it was right to remove. Its summary did not say which were which.
That is where an email migration loses mail: at the cutover, and quietly in the copy. CloudSpinx moves mailboxes for organizations in Kenya off cPanel hosting, Zimbra servers past their end of life and old Exchange onto Microsoft 365 or Google Workspace through our business email and migration practice, and the rehearsal was built to look like one of those moves: imapsync 2.314 copying between two Dovecot 2.4.2 servers, the new one carrying Exchange Online's folder names, 1,980 messages in seven folders, and users carrying on with their mail between passes the way they do during a real move.
What an email delta sync copies, and what it leaves behind
Whatever is new on the old server, and nothing users undid. The first pass took 35.8 seconds and copied 1,975 messages, 155.6 MiB. Then, on the old server, we added 50 new messages, filed 20 into a client folder, deleted 10, marked 30 as read, flagged 5, renamed a 120-message project folder and created another with 5 messages in it. The second pass took 4.7 seconds and copied 195 messages, 19.2 MiB. A third, with nothing changed, took 1.1 seconds and copied none. Both servers sat on one machine, so your times will be longer. The proportion is the point: seed days ahead and the pass on cutover night is small.
- right
- extra on the new server
- missing
A total that matches, or beats, the old server proves nothing: the inbox was 25 over while 5 of its messages were missing.
New mail arrived, and every read and flag change came across, because imapsync updates flags on messages it copied earlier unless told not to. Nothing users took away was taken away on the new server. The 20 filed messages landed in the client folder and stayed in the inbox too. The 10 deleted ones were still there. The renamed folder arrived as a second folder beside the first, 240 messages where the user had 120. Its strict-sync line counted only the 10 deleted messages, and made a suggestion:
The sync is not strict, there are 10 among 2030 identified messages in host2 that are not on host1. Use --delete2 and sync again to delete them and have a strict sync.Users complain about duplicates. Nobody complains about the five messages that never arrived, because nobody notices them. They carried neither a Message-ID nor a Received header, the two headers imapsync matches messages on by default, so it set each one aside. Its summary does mention them, with a suggestion to add --addheader, then closes the run with Detected 0 errors, and a script that checks only the error count moves on. One of them was a 1.1 MB message with a PDF attached.
Host1: INBOX/1 size 1099025 ignored (no wanted headers so we ignore this message. To solve this: use --addheader)Mail that came in over SMTP carries a Received line, because RFC 5321 requires the receiving server to add one. The messages at risk are the ones an application or an import wrote straight into a folder without a Message-ID. Rerun with --addheader, the same inbox came across whole, 1,224 of 1,224.
Totals would not have caught it. After the second pass the new server held 2,170 messages against the old server's 2,025, so a check that only asks whether anything is short passes, with five messages missing. Count per folder and chase every difference, in both directions.
One flag decided whether users could find their sent mail. Without --automap, the old Sent folder arrived as a folder called Sent beside an empty Sent Items, and Trash beside an empty Deleted Items, which are the names Exchange Online gives those folders. With it, imapsync matched the folders by role and put Sent into Sent Items and Trash into Deleted Items. A user who opens Sent Items and finds it empty reports their sent mail lost.
The --delete2 trap after the MX change
Once the MX record changes, both servers take mail for a while, because senders keep using the old record until it expires in their cache. We reproduced that by writing 4 messages into the old server, standing in for senders still holding the old record, and 3 into the new one. The default pass after the switch did the right thing: it copied the 4 late messages and left the 3 new ones alone.
Then it repeated its advice, now counting 13 messages on the new server that were not on the old one. Those 13 were the 10 deleted messages and the 3 new ones. Taking the advice, the --delete2 pass removed 33 messages from the new server: the 20 filed duplicates, the 10 deleted, and the 3 new emails, which existed only on the new server.
- kept
- removed, as intended
- removed, lost
imapsync matches each folder to the old server, so anything that reached the new server after the switch counts as surplus.
Mirror mode belongs before the MX change and never after it. Until the switch the old server holds the whole mailbox, and as long as nothing but the copy has reached the new mailboxes yet, making the new one match it is safe. After the switch it does not, and any pass that deletes to match it deletes mail. So the order is: seed days ahead with --automap and --addheader, keep both on every pass, run the mirror pass while the old server is still the only one receiving, change the MX record, and from then on run only passes that add. The stale project folder survived even the mirror pass, by the way. Removing folders takes a separate flag.
If you are partway through a move and imapsync is offering to make the two sides match, run it with --dry first, which prints what it would do without doing it, and send that output to us on WhatsApp at +254 713 403 044. We will tell you whether to run it.
How long to keep the old server receiving after an email migration
At least 72 hours after the MX change, by Microsoft's own IMAP migration steps, and longer is better. Microsoft recommends cutting the MX record's TTL to 3,600 seconds or less before the migration starts, and tells you to wait at least 72 hours after the change before deleting the migration batch, because the email systems of your customers and partners can take that long to recognize the new record. Its batch synchronizes once a day. Delete it, and "email that is sent to mailboxes on your source email system isn't copied".
That window is how a business loses mail it never knew it had. Cancel the old hosting account the morning after the switch, or wipe the old server, and whatever late senders delivered there since the last pass goes with it. Even a batch deleted on schedule can leave mail behind: a message that reaches the old server after the batch's last daily run is still sitting there when the batch goes. Look before you switch the old server off.
We leave the old platform live and receiving for two weeks after every cutover we run. While it is still there, any gap is another pass rather than a loss.
What an IMAP migration to Microsoft 365 never moves
Contacts, calendars and tasks. Microsoft's IMAP migration overview says it moves items in the inbox and other mail folders only. It also stops at 500,000 items per mailbox, taken newest first, and leaves behind any message over 35 MB. On a cPanel or Zimbra mailbox the address book and the calendar need a route of their own.
The same page warns about its own checking. Retention or archive policies that delete or move messages during the move make the tool flag those items as missing, which Microsoft calls "perceived data loss rather than actual data loss", and it asks you to switch those policies off first. A report full of false alarms hides a real one.
Who can run this alone
Plenty of people. Microsoft's guide says its admin-center wizard is the best route when you are moving fewer than 50 users. A ten-person office leaving a cPanel host, with no shared calendars, should use it, drop the MX record's TTL before the migration starts and keep paying for the old account for a month. If the destination is not settled yet, the two suites now list the same three prices, so storage, desktop Office and what your clients run decide it. Publish SPF and DKIM for the new platform before the MX record moves, so mail from it authenticates from the first message, and if you send more than 5,000 messages a day to Outlook.com addresses, Outlook refuses mail that fails. And if the mail has to stay in Kenya, neither suite has a region here, so the destination is a mail server you own.
Past that size, or with calendars and shared mailboxes in play, the cutover is the part worth paying for. Send the platform you are leaving, the number of mailboxes, the largest mailbox sizes, whether contacts and calendars live on that server, and the suite you are moving to, through the migration scoping form or on WhatsApp at +254 713 403 044. We send back the cutover plan for your mailboxes, how many passes, the day the MX record moves and how long the old server stays up, with one figure for the move. The plan is free and commits you to nothing, and if you go ahead, we handle the move with you.