imapsync vs BitTitan: Open-Source CLI or Enterprise SaaS

You have a migration to run and two candidate tools on the shortlist. imapsync is the Perl CLI that has been moving IMAP messages since 2005. BitTitan MigrationWiz is the SaaS that sales engineers reach for when the project plan has "PMO" written on it. Both work. They are not the same product and they do not fit the same job. This breakdown gives you the operational differences so you can pick before the project kicks off, not three weeks in.

The short version#

imapsync is a single binary you point at two mailboxes. It iterates UIDs on the source, copies messages to the destination, and writes a log. There is no UI, no dashboard, no per-user job queue, and no support contract unless you buy one privately from the author.

BitTitan MigrationWiz is a multi-tenant SaaS. You buy licenses per mailbox, upload a CSV of users, provision endpoints for source and destination, and run waves from a web console. There is a UI, a dashboard, a job queue, an SLA, and a support team in three regions.

The decision usually comes down to four questions: how many mailboxes, how much fidelity matters, who pays for the time, and who carries the pager when it breaks.

Cost model#

imapsync's licensing is the most-misread part of the tool. The source code on GitHub is GPL-v2 and free. The author also sells precompiled, signed Windows and macOS binaries with email support, and that paid product is what most people google. If you compile from source or install the package shipped by Debian, Ubuntu, Alpine, or Arch, you pay nothing.

BitTitan sells per-mailbox licenses. The published rate card hovers around $12 per User Migration Bundle for mailbox migrations, with volume discounts at 500 and 2,000 seats and add-ons for personal archive, document, and shared-mailbox workloads. A 1,000-mailbox migration lands between $10,000 and $15,000 in license cost alone, before partner labour.

The deceptive number is engineer time. imapsync looks free until you tally the hours building the orchestration around it. For 50 mailboxes one engineer can ship the whole thing in a weekend. For 500 you write a wrapper, a state store, a retry loop, and a status page, and you spend a real week on it. For 5,000 you stop pretending it is free.

Feature matrix#

Protocols and APIs#

imapsync speaks IMAP. That is the entire scope. It uses Mail::IMAPClient under the hood and supports IMAP4rev1, ID, IDLE, CONDSTORE, SASL PLAIN, SASL LOGIN, XOAUTH2, and STARTTLS. If your source and destination both expose a working IMAP server, you can copy mail. If one side is Microsoft 365 and you have not enabled Authenticated SMTP and IMAP for the user, the source will reject the login with AUTHENTICATIONFAILED and you will spend an hour figuring out it is tenant policy, not your code.

BitTitan reaches past IMAP wherever it can. For Microsoft 365 destinations it uses Microsoft Graph and EWS Impersonation, which is faster than IMAP append and preserves more metadata. For Google Workspace it uses the Gmail API and Vault where available. For IMAP-only endpoints it falls back to IMAP, the same RFC underneath, with its own throttling and retry layer on top. That protocol coverage is the main reason mixed-cloud migrations end up on MigrationWiz.

If your migration is IMAP-to-IMAP on commodity hosts, the API advantage evaporates and the comparison is mostly cost and orchestration.

Performance and concurrency#

A single imapsync process copies messages serially, one folder at a time, with a per-folder fetch-and-append loop. Real-world throughput is 0.5 to 2 GB per hour per mailbox depending on the average message size, RTT, and how aggressively the destination throttles APPEND. For 90 percent of mailboxes that is a 30 to 120 minute migration.

You scale it by running many imapsync processes in parallel. GNU parallel, xargs -P, a shell for-loop with backgrounded processes, an Ansible playbook, a Python wrapper, whatever your team is comfortable with. The hard part is not the parallelism, it is the state store: knowing which mailboxes finished, which failed, which need a delta pass, and which need a human to look at the log.

BitTitan ships that orchestration. You add users in waves, the service runs them concurrently against the per-tenant throttle ceiling, and you watch the dashboard. It does not move faster per mailbox than a well-tuned imapsync command. It moves faster across the whole project because you are not handwriting the runbook.

Fidelity: what survives the copy#

For IMAP-only migrations both tools preserve the basics: message bodies, attachments, threading via References and In-Reply-To, internal date with --syncinternaldates, and flags including \Seen, \Flagged, \Answered, \Draft, and \Deleted. Custom keywords (IMAP user flags) usually survive on imapsync but depend on destination support.

Folder hierarchies are where the two diverge. imapsync gives you --regextrans2 to rewrite folder names on the fly, which is critical when you go from a server using mUTF-7 to one using UTF-8, or when you need to flatten INBOX/Sent into Sent. BitTitan has a mapping UI for the same job. The CLI option is more flexible, the UI is easier to hand to a junior engineer.

Calendars, contacts, tasks, distribution-group memberships, shared mailbox permissions, room resource bookings, archive mailboxes, and journaling are all out of scope for imapsync. BitTitan handles them through workload-specific licenses on Exchange-class destinations. If your migration is "everything in the tenant," imapsync is not the right tool no matter how cheap it looks.

Authentication#

OAuth2 is the painful one. Gmail and Microsoft 365 both prefer or require OAuth2 for IMAP these days, and the setup is non-trivial.

imapsync accepts --oauthaccesstoken1 and --oauthaccesstoken2. You generate the token yourself, refresh it yourself, and pass it on each invocation. There are helper scripts in the imapsync source tree but the credential lifecycle is your problem. For one-off migrations you can use app passwords on Gmail (if your domain still allows them) and basic-auth fallback on M365 (if your tenant still allows it), but assume both are going away.

BitTitan handles OAuth via consented endpoints. You click through an admin consent flow once per tenant, the service stores the refresh tokens, and per-user impersonation is handled with admin credentials plus EWS Impersonation or Graph application permissions. For an admin who has never set up an OAuth flow, this is a meaningful time saving.

For a deeper walkthrough of the IMAP path itself, see the step-by-step IMAP migration guide.

Reporting and audit#

If the migration ends up in a compliance review, you will be asked four questions: which mailboxes were migrated, when, by whom, and were any messages skipped or truncated.

imapsync writes one log file per invocation. Verbose mode includes per-message UID, size, flags, and any errors. You collect them into a directory, grep for WARNING and ERROR, and write your own summary. Some teams ship the logs into Splunk or Loki and build a dashboard. That works, but it is work.

BitTitan exposes per-user reports inside the console, downloadable as CSV, with error categories like "ItemSizeExceeded" or "FolderPathTooLong" already classified. For a regulated industry that is the difference between a clean audit and a long conversation with the auditor.

If reporting is on your checklist alongside other factors, the shortlist of 2026 migration tools covers how each vendor handles audit trails.

Support and recovery#

When imapsync hits something weird, you are reading Perl. The community forum is active, the author answers paid-binary customers by email, and Stack Overflow has a decade of answers. Mean time to resolution depends on how comfortable you are with --debug, --debugimap1, and --debugcontent.

BitTitan has 24x7 support, a portal, a partner channel, and named CSMs above certain seat counts. When a migration stalls at 2am you can open a ticket. They have seen most failure modes before and will tell you the root cause in the response.

For one-engineer shops, imapsync's "you own it" model is honest. For 24x7 MSPs running ten migrations at once across timezones, BitTitan's support model is what justifies the price.

When imapsync wins#

Pick imapsync when:

• The migration is under 100 mailboxes and one engineer owns it end to end.
• Both source and destination are IMAP-native (cPanel, generic hosting, Zimbra, Dovecot, Courier).
• You need fine-grained folder rewriting, regex-based filtering, or message-level exclusion rules.
• The budget cannot stretch to per-mailbox licensing.
• You are happy reading Perl when something breaks.

If imapsync is on your shortlist, the imapsync head-to-head with Mailbox Taxi covers the desktop-tool alternative.

When BitTitan wins#

Pick BitTitan MigrationWiz when:

• The migration involves Microsoft 365 or Google Workspace and you want API-level fidelity, not just IMAP.
• Mailbox count is above 500 or the project crosses multiple waves and weekends.
• The buyer asked for "a dashboard" or "reporting" by name.
• You need calendars, contacts, archives, or shared-mailbox permissions to migrate alongside mail.
• An auditor will look at the project after it ends.

The Mailbox Taxi vs BitTitan comparison covers the desktop alternative if you want BitTitan-like fidelity without per-mailbox licensing.

Where Mailbox Taxi fits#

Both tools have known gaps. imapsync demands CLI fluency and DIY orchestration. BitTitan demands per-mailbox spend even for small jobs. Mailbox Taxi is the desktop-first option that sits between them: runs locally on Windows, macOS, and Linux, talks IMAP to all major providers including Gmail and Microsoft 365 with OAuth2 built in, gives you a per-mailbox progress view without a SaaS console, and does not charge per seat. It is in waitlist phase right now.

Decision checklist#

Answer these before you buy or compile anything:

1. How many mailboxes? Under 100, over 500, or somewhere in between?
2. What protocols on each side? IMAP-only, M365, Workspace, or mixed?
3. Calendars and contacts in scope, or mail only?
4. Who runs it, and what is their hourly rate?
5. Does anyone need a dashboard, or is a log file enough?
6. Is there an audit at the end?
7. What is the cutover window, and what is the rollback plan?

Score each tool against those seven, not against a feature list pulled from a vendor page.

FAQ#