Migrate Fastmail to Office 365: IMAP Cutover for Admins

A Fastmail-to-Office-365 cutover is the kind of project that looks straightforward on paper and gets tangled the moment you have more than one user. Both endpoints speak clean IMAP, both use app passwords, and Fastmail rarely throttles. What gets you is the operational scale: per-mailbox quota planning, parallel jobs, MX cutover sequencing, and verification that's defensible to a project sponsor who wants to know exactly what got moved. This walkthrough is written for admins doing one to a few dozen users at once.

What you're actually moving#

A Fastmail-to-Office-365 migration moves three things:

• Mailbox contents — all folders, all messages, all attachments — from Fastmail to the corresponding Office 365 mailbox.
• The MX records for the domain (if you're moving a custom domain that's currently pointed at Fastmail).
• The user-facing identity — credentials, mobile-app configuration, signatures — to the new system.

Only the first is automatable end-to-end. The second is a DNS operation you do yourself once you're ready to cut over. The third is comms and per-user setup. Mailbox Taxi handles #1 reliably; the rest is project management.

Before you start#

For an admin migration, prep matters more than execution. Build the inventory first.

For each Fastmail user being migrated:

• Username and current Fastmail address.
• Mailbox size in GB.
• Number of folders and approximate folder depth.
• Any custom domains hosted on Fastmail that this user sends from.
• Sieve scripts or rules that are business-critical and will need recreating.

For each Office 365 destination:

• UPN (User Principal Name) on the destination tenant.
• License assigned (Business Basic/Standard/Premium, Exchange Online Plan 1 or 2).
• Current mailbox quota.
• Whether MFA is enabled (required for app-password generation).
• Whether IMAP is enabled on the mailbox (it usually is, but tenant-wide policies sometimes disable it).

This inventory is what makes the cutover predictable. Without it, you'll be diagnosing one-off failures during the window instead of executing.

Step-by-step migration#

1. Inventory the Fastmail mailboxes

   Sign in to each Fastmail account that's being migrated, or use Fastmail's admin tooling if you have a Fastmail Business subscription that gives you central visibility. Record the mailbox size from Settings → Account → Storage and note the number of folders and any nested structure. If users send from custom domains, list those too.

   For larger fleets, ask each user to fill out a short form with their Fastmail address, approximate mailbox size, and any folders or filters they consider essential. This catches surprises before the migration.

2. Provision the Office 365 destinations

   In the M365 admin center, confirm every target user has:

   • An Exchange Online license. Business Basic, Standard, Premium, or any Exchange Online Plan 1 / Plan 2 will work.
   • A provisioned mailbox (visible in Exchange admin center → Recipients → Mailboxes).
   • Mailbox quota at least 1.1x the size of the Fastmail mailbox being migrated.
   • IMAP enabled. Active users → user → Mail → Manage email apps, confirm IMAP is checked.
   • MFA enabled — required for generating app passwords.

   If you're moving multiple users with mailboxes pushing 50 GB, Exchange Online Plan 2 is the cleaner path. For wider context on the Office 365 receiving side, the Office 365 migration guide covers the broader admin landscape.

3. Generate app passwords on both sides

   For each Fastmail user, sign in to Fastmail and go to Settings → Privacy & Security → App passwords. Create a new one, name it "M365 migration", grant IMAP & POP access only, and record the password. Repeat for every user.

   For each Office 365 destination, sign in as the destination user at myaccount.microsoft.com → Security → Additional security verification → App passwords. Create one, name it "Fastmail import", and record it.

   If app-password generation isn't available on the M365 side, MFA isn't enabled for that user, or your tenant has disabled app passwords at the tenant level. An admin needs to fix that before the migration can proceed. The app password glossary entry explains the auth model if you need to brief stakeholders.

4. Configure the migration job in Mailbox Taxi

   For each user, create a migration job. Source: Fastmail. Host imap.fastmail.com, port 993, SSL/TLS. Username: full Fastmail address. Password: Fastmail app password. Test.

   Destination: Office 365. Host outlook.office365.com, port 993, SSL/TLS. Username: full UPN. Password: M365 app password. Test.

   For multi-user batches, save these as templates in Mailbox Taxi so you can spin up new jobs quickly.

5. Map Fastmail folders to Office 365 folders

   Mailbox Taxi proposes a folder map for each mailbox. Standard system folders map cleanly. Custom folders come across as custom folders under the root.

   Things to adjust for each user:

   • Deeply nested folders (4+ levels) may be worth flattening for usability in Outlook.
   • Spam and Trash should usually be excluded.
   • The Archive folder maps to Archive on the destination, which is what most users expect.
   • Notes (if used in Fastmail) is rarely worth migrating.
6. Run a pilot migration on one user

   Pick one user with a representative mailbox — a moderate-sized one with a typical mix of folders and a manageable number of attachments. Run the full migration end to end for that user.

   When it's done, sit with the user (or do it yourself if you're migrating your own mailbox) and verify:

   • All expected folders are present in Outlook on the web.
   • Message counts per folder match Fastmail.
   • A sample of 30+ messages renders correctly — subject, date, sender, attachments, HTML.
   • Any sieve-based filtering they relied on is either rebuilt as Outlook rules or documented as something they'll do without going forward.

   If anything is broken or surprising, fix it now. The pilot is your template; what works here will work on the rest.

7. Run remaining migrations in parallel batches

   For the remaining users, run 4–6 simultaneous migration jobs. Each job uses its own pair of IMAP connections, so 6 simultaneous user migrations means roughly 24 active IMAP connections — well within what a typical workstation can handle but enough to saturate a home broadband uplink.

   Monitor for Too many simultaneous connections errors on the M365 side. If you see them, lower per-job concurrency from 4 to 2 connections.

   Expect 60–90 minutes per gigabyte per user, in parallel. A batch of six 5 GB mailboxes runs in about 5–7 hours of wall-clock time on a decent workstation.

8. Verify each migrated mailbox

   Mailbox Taxi shows per-folder counts side by side after each job. Confirm they match. For the user-facing verification, spot-check 20+ messages per mailbox. For a fleet of 20+ users, sample 5 users at random and verify them in depth rather than checking every mailbox shallowly.

   Document what got migrated, what got excluded (Spam, Trash, anything else), and what couldn't be migrated (sieve scripts, masked emails). That document is what you hand to the project sponsor.

9. Cut over MX records and decommission Fastmail

   Once all mailboxes are migrated and verified, schedule the MX cutover. Plan for it during a low-traffic window — late evening or weekend. Set up forwarding from each Fastmail mailbox to the corresponding M365 mailbox before flipping MX, so any mail that arrives at Fastmail during the DNS-propagation window still ends up in M365.

   Flip MX records to point to the M365 tenant. Wait for DNS to propagate (typically 1–4 hours, occasionally up to 24). Verify mail flow by sending a test message to each migrated user from an external account.

   Keep Fastmail accounts active with forwarding enabled for at least 30 days as a safety net. After 30 days of clean operation, decommission the Fastmail subscriptions.

Gotchas specific to Fastmail → Office 365#

A few that show up reliably on this exact pair.

Defender for Office 365 quarantine#

If your tenant runs Defender for Office 365, expect a fraction of migrated messages — especially anything from the Spam folder, but occasionally legitimate mail too — to be quarantined on first ingest. Review the quarantine after each migration and release anything that shouldn't be there.

Send-as for custom domains#

Custom domains hosted on Fastmail need to be added as accepted domains in the M365 tenant before users can send from those addresses. This is a DNS and admin-center task separate from the mailbox migration.

Calendar invites re-trigger#

Migrated old calendar invites occasionally get re-interpreted by Outlook as new invites. Users see meeting notifications for events from years ago. It's harmless but startling. Warn users in your comms.

Tenant-wide IMAP policy#

Some tenants disable IMAP at the org level for security reasons. If so, you need an admin to either temporarily enable it for migration users or add an exception. Without IMAP enabled on the destination mailbox, no IMAP-based migration tool can write to it.

Real errors you'll see and what they mean#

• AUTHENTICATIONFAILED on source — Fastmail account password used instead of app password.
• AUTHENTICATIONFAILED on destination — M365 account password used instead of app password, or app passwords disabled at the tenant level.
• Too many simultaneous connections — M365 throttle. Lower concurrency.
• Quota exceeded — destination mailbox is full. Increase quota and resume.
• Message too large for destination — single message exceeds the 150 MB M365 limit. Skip and handle manually.
• STARTTLS handshake failed — host or port misconfigured. Both ends use SSL/TLS on port 993.
• Folder UTF-7 conversion error — a Fastmail folder has non-ASCII characters Exchange won't accept. Rename on Fastmail.

Communicating the change#

Multi-user cutovers need clear comms. A workable template:

• 2 weeks out — announce the migration, dates, what users should and shouldn't do beforehand.
• 1 week out — send a how-to for setting up Outlook desktop and the Outlook mobile app on the new account.
• 24 hours out — final reminder; encourage users to send themselves test mails so they have known references for verifying their migrated mailbox.
• During the cutover window — keep a status page or Slack channel updated.
• Day after — send a verification checklist: "Confirm you can see your Inbox, your Sent items, your old folders, and that you can send a new email."
• 1 week after — collect any issues and address them before decommissioning Fastmail.

Post-migration checklist#

• Folder counts match on every migrated mailbox.
• Random spot-check of 30+ messages per mailbox confirms fidelity.
• Send-as for custom domains added in M365.
• Sieve-based filtering documented and rebuilt where business-critical.
• Aliases added as proxy addresses on M365 user objects.
• MX records cut over and DNS verified.
• Forwarding from Fastmail to M365 active during the transition window.
• Mobile apps reconfigured for affected users.
• Fastmail accounts kept alive with forwarding for 30 days as a fallback.
• Decommission plan documented with a date.