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]
It doesn’t explicitly state anything about the email contents in the privacy policy page. People generally trust their email providers to not snoop in their emails. I wonder why anyone should trust a cloud based service (such as this).
Email migration is genuinely painful and I am sure there's a real market here, so I am not trying to discourage you. But why should I trust a third party with my IMAP credentials?
"Credentials encrypted in memory only and deleted immediately after migration".
I have no way to audit/verify this claim. You're essentially asking users to hand over the keys to their entire email history on faith.
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.
I am in the process of migrating from GMail and Proton using imapsync, since Proton's built-in tool imported some 95% of emails only.
Turns out Proton is super picky about RFC compliance and will reject anything that doesn't met the criteria, which sucks because GMail does exactly the opposite and will take almost anything you throw at it.
So I have so far written about 7 different regexes to fix some specific mailer issues to make them RFC compliant, with plenty more to go. And even then it still somewhat sucks because I am, effectively, modifying the emails to a state they were not received/sent in.
10 comments
[ 4.3 ms ] story [ 37.4 ms ] threadIt supports large mailboxes, preserves full data integrity, requires no setup, and works with any IMAP-compatible email service.
I also can't imagine there is much demand for IMAP only email migration services these days.
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_...
https://imapsync.lamiral.info
This is the way projects used to be, and surprisingly excellent ones still are.
The amount of knowledge built into this is incredible:
https://imapsync.lamiral.info/S/news.shtml
// imapsync did 14M to 21M mailboxes transfers per month in 2024, or 0.22% of ALL email traffic
"Credentials encrypted in memory only and deleted immediately after migration".
I have no way to audit/verify this claim. You're essentially asking users to hand over the keys to their entire email history on faith.
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.
Turns out Proton is super picky about RFC compliance and will reject anything that doesn't met the criteria, which sucks because GMail does exactly the opposite and will take almost anything you throw at it.
So I have so far written about 7 different regexes to fix some specific mailer issues to make them RFC compliant, with plenty more to go. And even then it still somewhat sucks because I am, effectively, modifying the emails to a state they were not received/sent in.