PLATFORM

IMAP Mailbox Migration

MigrationFox connects to any IMAP-capable mail server — cPanel hosts, Zimbra, FastMail, Dovecot, legacy university servers, abandoned consumer accounts — and migrates the mailbox content into Microsoft 365 (Exchange Online) or Gmail. The destination side uses Microsoft Graph or the Gmail API; the IMAP side is read-only.

Why IMAP

IMAP is the universal mail-source escape hatch. When the source server has no Graph API, no EWS, no documented bulk-export path, and the only way to get the mail out is the protocol the email client already uses to read it — that’s IMAP. Common scenarios:

• cPanel / Plesk shared-hosting mailboxes consolidating into a real M365 tenant
• Zimbra collaboration suite migrating to Exchange Online
• FastMail / Yandex / Mail.ru personal mailboxes joining a corporate account
• Acquired company on a no-longer-supported on-prem mail server (older Postfix/Dovecot, Sendmail, IMail) where vendor-specific tooling no longer exists
• End-of-life consumer providers (BT Mail, AOL, Yahoo Mail) where the user wants their archive preserved

What Gets Migrated

• Folder hierarchy — the full IMAP folder tree is recreated on the destination, including nested subfolders
• Every message — complete RFC 822 source including headers, body parts, and attachments
• Read / unread state — \Seen flag on each message is preserved as the destination’s read state
• Flagged messages — the \Flagged IMAP flag maps to Outlook’s follow-up flag
• Original send / receive dates — preserved on the destination so mailbox sort order is unchanged
• Attachments — gated on the ENABLE_IMAP_ATTACHMENTS flag during staged rollout. Cap: 25 MB per attachment and 25 MB total per message, matching the Gmail/EWS pattern

Auth

IMAP authentication is username + password (with TLS / STARTTLS on the default secure port). MigrationFox stores the password AES-256 encrypted at rest with per-credential salts and the same key-rotation lifecycle as the OAuth providers — the password is never logged or returned via the API.

If the source server requires an app-specific password (Gmail, FastMail, iCloud, Yandex), generate one in the provider’s security settings and use that instead of the account password. Modern providers no longer accept account passwords for IMAP at all.

What Doesn’t Migrate

Being honest about what IMAP can’t carry, because the protocol simply doesn’t expose it:

• Calendar items, contacts, tasks — IMAP only carries mail. Other PIM data needs a different protocol (EWS, CalDAV, CardDAV)
• Server-side rules — defined on the source server, not visible to IMAP clients
• Out-of-office / vacation responder — server-side config, not in IMAP
• Sender attribution beyond the From: header — IMAP messages are already authored; nothing to remap

For Exchange-to-Exchange migrations where you need calendar and contacts, use the EWS connector on the source side instead.

Destinations

IMAP-as-source pairs with these destinations:

• Microsoft 365 — Exchange Online via Microsoft Graph (delegated OAuth or service-account with mailbox impersonation)
• Gmail — via the Gmail API (delegated OAuth or service-account with domain-wide delegation for Google Workspace tenants)

Pricing

IMAP migrations are billed at CA$0.50 per GB of message data transferred, the same rate as every other mail platform. Your account starts with 2 GB free — small archive migrations finish end-to-end inside the free tier.