I haven't had excuse to use imapsync for awhile. I remember using it fondly in the past. I definitely hadn't looked at the site in years.

I see that there's a free (for up to 3GB, pay for more) migration service offered there now, too: https://imapsync.lamiral.info/X/

That's a pretty cool way to support the project.

imapsync is slower than mbsync[1] (both in startup and per message) and doesn't support bidirectional sync[2]. It however handles message identity better than mbsync and supports using different authorization and authentication. For administering our mailserver, I first used imapsync and then patched mbsync to support the Auth header. I still use imapsync to sync the flags afterwards. I think both have high-level race conditions, so maybe take the server offline during a sync.

    [1] https://isync.sourceforge.net/
    [2] https://imapsync.lamiral.info/FAQ.d/FAQ.Two_Ways_Sync.txt

Yep, and no ISO 27001 or SOC II, nor is the location of the country of operation disclosed, let alone any name associated with it.

I remember about 20 years ago writing a relatively simple tool in perl with IMAP::Client to migrate a Universities staff mail from Courier (I think) to Communigate Pro, and then another one to migrate from Communigate Pro to Microsoft Exchange a few years later.

I was at the beginning of my career. It was pretty easy. Went almost flawlessly, moving thousands of peoples email.

Where is the "painful" part? It's just moving blobs of text around.

There's also no names listed of anyone associated with the project, nor they mention the country where they are located, so you don't even know which sets of laws applies.

I also had that issue when setting up a server. I decided to disable the enforcement for the initial sync and then enable it.

Email only has two really mandatory headers: Date and From. There were emails without a Date header, you can't make that shit up. Naturally MUAs also can't deal with this, e.g. Thunderbird shows the timestamp of the first sync.

Perhaps not much, but last year I was looking at using IMAP as an export/import path for a relative's old Eudora mails to some much-more-recent client. I insisted on it, after I found out it could no longer make a secure connection to their e-mail server.

That said, I was saved/pleased by Eudora2Unix [0], one of those projects that represents a very long slow burn of successive people with a similar niche struggle. You might think Thunderbird would have an import tool for that, but it's been so many years it didn't survive...

[0] https://github.com/jonabbey/eudora2unix

I'm working on one this week, from a cPanel-hosted email to Google Workspace. There are probably still quite a number this category will still be happening.

Then there's all the people who want to exit Big Tech or US-based companies right now.

I was an early employee at MigrationWiz (BitTitan), always cool to see recognition of the co in the wild.

Geeman, the founding CEO would have definitely sent a C&D immediately, but BitTitan was acquired by a PE firm and I don't find it hard to imagine nobody cares anymore. [0][1][2]

[0] https://www.reddit.com/r/msp/comments/1mnelca/migrationwiz_w...

[1] https://www.reddit.com/r/msp/comments/1qnwkwl/do_not_use_bit...

[2] https://www.reddit.com/r/sysadmin/comments/1qswdub/bittitan_...

I wonder if it includes workarounds for Google IMAP bugs etc. Some years ago I migrated over 10 years worth of emails from Google to Fastmail and I ran into a lot of issues with Google's buggy IMAP implementation. Things like a random 1 in every 1000 email failing to delete so I would have random emails still remaning. I found out it was a known issue which Google pretty much decided they WONTFIX. I later found Fastmail had its own migration tool that (I presume) has workarounds for various bugs in other providers IMAP implentation making it easier than using e.g. Thunderbird to do it. If I could go back in time and use a tool like this that has a way to work around Google's bugs that would have saved a lot of my time.

Thunderbird only supports moving from one mailbox to another, it doesn't support syncing whole namespaces. It also doesn't support syncing with namespace rewriting or syncing flags, timestamps or access rights. It does not allow using different authorization and authentication and is unsuitable for large syncs as you can't resume anything or have a progress bar. It is also pretty slow, because it does one mail at a time and is just not designed for this.

Note that I used the proper IMAP terms. A mailbox is what the layman probably calls a folder or directory, a namespace is what the laymen probably would call a mailbox or account.

You could use Thunderbird, but it’s slow for large mailboxes and multiple accounts. Being cloud-based, Migrate Wizard moves email faster, tracks progress, retries on errors, and supports incremental syncs - all without running a client locally.

Thunderbird stops the whole process on first failure. You won't even know from the log file which email is at fault.