Bulk Migrate Microsoft 365 to TrekMail

Microsoft 365 (formerly Office 365) and consumer Outlook.com both speak IMAP, and TrekMail's bulk importer handles them well. This guide covers the Microsoft-specific details — App Passwords for MFA-enabled accounts, the M365 IMAP host, folder-name remapping for Outlook conventions, and shared-mailbox quirks. The general bulk flow (CSV format, preview, monitoring) is the same as cPanel bulk migration — this article focuses on what's different about M365.

Prerequisites

• Migration tool feature: Starter plan and above (Nano accounts can't run bulk migrations).
• Every destination mailbox must already exist on TrekMail before launch — see Bulk Mailbox Creation.
• For each source account, you'll need a valid IMAP password. If MFA is on (most modern M365 tenants enforce it), that means an App Password per user.

App Passwords — when you need them and how to get them

Microsoft 365 disabled "Basic Authentication" (username + plain password over IMAP) for most tenants in 2022. The replacement for IMAP access is App Passwords: a 16-character one-time string generated by the user, used in place of their regular password for IMAP/SMTP/POP3.

You need an App Password when:

• The account has MFA enabled (very common — most enterprise M365 tenants enforce MFA).
• Your tenant has Modern Authentication required for IMAP.

You don't need one when:

• The account is on a consumer Outlook.com account with no MFA (rare these days).
• The tenant admin has explicitly enabled Basic Authentication for IMAP (also rare; it's a security risk).

How each user generates their App Password

1. Sign in at account.microsoft.com/security.
2. Additional security options → App passwords (or Security settings → App passwords depending on tenant policy).
3. Click Create a new app password.
4. Give it a label (e.g. "TrekMail migration") and copy the generated 16-character string. You see it only once — if lost, generate a new one.

If the App Passwords option doesn't appear, the tenant admin has disabled it. Two paths:

• Ask the admin to enable App Passwords for users who need IMAP migration. In Microsoft Entra (formerly Azure AD), this is under Authentication methods → Policies → Authentication methods migration.
• Use mailbox-level IMAP delegation (admin grants you access to mailboxes via Set-MailboxPermission, then you use your own admin App Password to migrate). Requires PowerShell access; outside the scope of this article.

If you're the M365 admin and want to enable Basic Auth temporarily for the migration window, this is supported but discouraged for security reasons; see Microsoft's docs.

The CSV

Since all M365 accounts use the same IMAP host, the simple 3-column format works:

source_email,source_password,destination_email
alice@company.onmicrosoft.com,app-pw-1,alice@yourdomain.com
bob@company.onmicrosoft.com,app-pw-2,bob@yourdomain.com
carol@company.com,app-pw-3,carol@yourdomain.com

The source_password is the App Password generated by each user (not the regular login password). Each row is a separate user — no admin password works to migrate everyone; M365 wants per-user authentication for IMAP.

If your accounts use a custom domain (e.g. alice@company.com where company.com is your verified M365 domain), use that — not the *.onmicrosoft.com form. Both work, but using the user-facing address is cleaner.

Server details (filled in automatically)

When you select Outlook as the provider in the bulk-import form, the IMAP server details prefill:

You don't need to override these — they're the same for every M365 tenant worldwide.

If you're on consumer Outlook.com (not enterprise M365), the same host (outlook.office365.com) also works. We've alternatively listed imap-mail.outlook.com as a fallback host known to work for consumer accounts.

Step-by-step

1. Open Import → Bulk Import tab in TrekMail.
2. Provider — pick Outlook.
3. The server details prefill. Don't change them.
4. Folder strategy — for M365 the All folders option preserves the typical Outlook folder set (Sent Items, Deleted Items, Drafts, Junk Email, Archive, custom folders). The Standard folders only option skips Junk Email and Deleted Items — cleaner for archival migrations.
5. Import since (optional) — skip mail older than this date.
6. Skip duplicates — checked by default. Useful if you've previously run a partial import.
7. Batch name — label this batch ("Q1 migration", "Sales team", etc.).
8. Upload CSV or paste it into the text area.
9. Click Preview & Validate.
10. Review valid/invalid rows. Fix the CSV if any rows fail validation, then re-upload.
11. Start Migration. Toast: "Bulk migration started — N accounts queued."

Folder-name remapping

Outlook uses different folder names than the IMAP standard:

The remapping is automatic — you don't need to specify anything. Custom folders (like "Clients/Acme Corp") keep their hierarchy intact, including the slash separator if Outlook used one.

What to expect performance-wise

M365 allows generous IMAP concurrency compared to Gmail — typically you can run 50+ concurrent connections without rate-limiting. A typical migration runs at 200-1000 messages per minute per mailbox, depending on the source mailbox's size and the mix of message sizes (small text emails are fast; mailboxes with many large attachments take longer).

Expect:

• Small mailbox (1-5 GB) — minutes.
• Medium (5-25 GB) — 1-3 hours.
• Large (25-100 GB) — overnight.
• Very large (100+ GB) — multi-day.

For multi-day migrations, your DNS strategy matters. See "Recommended cutover plan" below.

Common bulk-mode problems

"Authentication failed" on every row

You're using regular login passwords instead of App Passwords, and MFA is enabled. Have each user generate an App Password (see top of this article), update the CSV, and Retry failed.

"Authentication failed" on some rows but not all

• The failed rows have wrong App Passwords. Verify each user copied their App Password correctly (no trailing spaces, full 16 characters).
• Some users may not have App Password access enabled by tenant policy. Coordinate with the admin.

"Connection failed" or "Timeout"

If many rows fail with connection errors but a few succeed, your tenant may be rate-limiting our IPs. Microsoft's IMAP service has fairly generous quotas but bulk migrations can occasionally trigger them. Try:

• Running the batch in smaller chunks (50-100 rows at a time instead of 500+).
• Spreading the migration across days.
• Contacting Microsoft support if the issue persists.

Shared mailboxes don't migrate via the bulk flow

Shared mailboxes in M365 (the kind multiple users access via Send-As permissions) require special handling because they don't have a direct user identity for IMAP login. To migrate them:

1. Generate an App Password under a user account that has Full Access permission on the shared mailbox.

2. In the migration CSV, list:

   • source_email = the shared mailbox address.
   • source_password = the App Password of the user with Full Access.
   • destination_email = where it should go on TrekMail.

3. If that fails, you may need to use a migration-specific user identity in M365. PowerShell:

   Add-MailboxPermission -Identity "shared@company.com" -User "migrator@company.com" -AccessRights FullAccess
   

   Then use migrator@company.com + its App Password but specify the shared mailbox as the source email. M365's IMAP supports this delegation pattern.

If that's still not working, migrate shared mailboxes individually using the single-mailbox import flow — sometimes the bulk flow doesn't surface the right error and the single-flow does.

Migration completes but resource mailboxes (rooms, equipment) didn't transfer fully

M365 resource mailboxes (conference rooms, equipment) hold mostly calendar data, not regular email. IMAP-based migration captures the email but not the calendar entries. If you need the resource bookings, you'll need a CSV export from the M365 admin center or a calendar-specific migration tool — not in scope for TrekMail.

Recommended cutover plan for M365 migrations

1. Day -7: Create all destination mailboxes on TrekMail.
2. Day -3: Reduce M365 mailbox TTL to 300 seconds at your DNS provider, in preparation for the MX swap.
3. Day 0 (Friday afternoon): Run the bulk migration. It runs overnight.
4. Day 1 (Saturday): Verify import completed without errors. Check sample mailboxes against the M365 source.
5. Day 1-2: Update MX records to point at TrekMail. Inbound mail now arrives at TrekMail.
6. Day 2-3: Run a delta migration — re-run the same bulk batch (with Skip duplicates ON) to capture any mail that arrived at M365 between the initial import and DNS cutover.
7. Day 7-14: Keep M365 mailboxes accessible for the team to verify nothing was missed. Optionally, set forwarding from M365 to TrekMail as a final safety net.
8. Day 14+: Cancel M365 licences.