FortiMail to Exchange Online, part 1: assessment, sizing and the migration plan

When FortiMail runs in server mode it isn't just a spam filter: it is the mail server. It hosts the mailboxes, filters inbound mail and often relays mail for applications as well. This series follows a realistic project: about 500 FortiMail mailboxes holding roughly 4 TB move to Exchange Online, and 100 of those mailboxes belong to former employees whose mail must be kept without paying for licenses. In this first part I'll build the plan: what to inventory, how to size the data, how long the copy will take, which licenses fit and the order to do the work in.

The series and the end state#

The project splits into five workstreams, one per part:

The project is done when every active user works in an Exchange Online mailbox, the leavers' mail sits in Microsoft 365 where the right people can reach it, the MX record no longer points at the FortiMail mailbox server, no application relays through it any more, and the archive data has a documented home. Only then can the unit be rebuilt for another role or retired.

Step 1: Confirm what FortiMail is doing today#

Start with the operation mode, because it decides the whole design. Fortinet documents three modes. In gateway and transparent mode FortiMail filters mail for another server and doesn't host mailboxes. In server mode it is a standalone email server: users read their mail in its web interface or retrieve it with POP3 or IMAP. Everything in this series assumes server mode. If your unit runs in gateway mode, the mailboxes live on another server, and that server is your migration source.

Then list everything the unit does, because each item needs a new home in Microsoft 365 or a deliberate decision to drop it:

• Domains, users and aliases. In server mode you can export the user accounts from Domain & User › User › User with Export .CSV. That file becomes the backbone of your mapping sheet: FortiMail account, Microsoft 365 user, license or shared mailbox, migration wave.
• How users sign in. Local FortiMail passwords, or an authentication profile that checks passwords against a directory. This decides how the migration gets credentials (part 2).
• How users read mail. Webmail and IMAP users keep their mail on FortiMail. POP3 users often download it into a local data file and leave little on the server. Their history lives in PST files on their PCs, which IMAP migration can't see, so plan a PST import for them (part 5).
• Address books and calendars. Server mode keeps a global and per-domain address book under Domain & User › Address Book, which you can export as CSV or vCard, and users can keep their own contacts and calendars in webmail. IMAP migration moves none of these.
• Email archiving. Archive accounts and policies under Email Archiving, with their retention period and storage location (local disk, NAS or a remote FTP or SFTP server). Part 5 deals with them.
• Security and content features. Antispam and antivirus profiles, content and DLP rules, identity-based encryption, disclaimers, DKIM signing and quarantine reports. Part 4 maps each one to its replacement.
• Relay clients. Applications, scanners and printers that send through FortiMail because an access control rule lets them. They stop working on cutover day unless someone moves them.

Step 2: Measure every mailbox, not just the total#

4 TB across 500 mailboxes averages 8 GB, but the average hides the mailboxes that shape the design. What you need is the distribution, sorted into bands that match Exchange Online's limits:

Count items as well as gigabytes. IMAP migration copies at most 500,000 items per mailbox (newest first), skips messages larger than 35 MB and ignores folders with a forward slash (/) in their name, and Exchange Online holds at most 1 million items in one folder. A mailbox that breaks one of these rules needs attention before its wave, not after it.

The most reliable way to get the numbers is Microsoft's mailbox analysis for Google Workspace and IMAP sources. It reads each source mailbox through the same IMAP endpoint and CSV format you'll use for the migration, and reports item counts and sizes per folder. It runs in Exchange Online PowerShell only, and for IMAP sources the target Exchange Online mailboxes must already exist:

Connect-ExchangeOnline

# Uses the IMAP endpoint and CSV format from part 2
New-MigrationBatch -Analyze -Name "FML-Analysis-01" -SourceEndpoint "FortiMail-IMAP" -AutoStart `
    -CSVData ([System.IO.File]::ReadAllBytes("C:\Migration\analysis-01.csv"))

# Estimated item count and size (bytes) per mailbox
Get-MigrationUser -BatchId "FML-Analysis-01" | Format-Table Identity, Status, Estimate*

# Folder by folder for one mailbox
$stats = Get-MailboxAnalysisRequestStatistics "amal.hassan@contoso.com" -IncludeAnalysisResult -IncludeFolderDetails
$stats.MailboxAnalysisResult.AnalysisResultDataRows | Format-Table FolderPath, ItemCount, ItemSize

Folders over 100 GB are flagged as warnings in the results. Copy the totals into the mapping sheet and add two columns: the size band and the planned license or mailbox type.

Step 3: Estimate how long the copy takes#

IMAP migration is a pull: Exchange Online connects to FortiMail's IMAP service and copies the mail. Three things set the pace: how fast FortiMail can serve IMAP (its disks, CPU and session limits), your internet uplink, and Microsoft's migration service, which copies 20 mailboxes at a time by default and up to 100 if you raise the endpoint's concurrency.

The uplink sets the ceiling. Assuming the migration can use about 70% of it:

Real migrations rarely reach that ceiling, because the IMAP server is usually the bottleneck. Microsoft publishes duration estimates for generic IMAP onboarding per mailbox, based on earlier customer migrations: a mailbox up to 10 GB typically finishes in a day; 10 to 50 GB in one to two days; 50 to 100 GB in one day at the median but up to eight days at the 90th percentile; 100 to 200 GB in three to 29 days. Above 200 GB isn't supported.

So measure your own rate in the pilot (part 2) and plan with it. If the pilot sustains 25 GB per hour across the endpoint, 4 TB needs about 160 hours: 6.7 days of continuous copying, or about 13 days if you only copy 12 hours a night. At 10 GB per hour it's 400 hours, roughly 17 days nonstop. That sounds long, but it doesn't have to fit into a weekend. An IMAP batch keeps synchronizing every 24 hours until you remove it, so the bulk copy runs in the background for weeks while people keep working on FortiMail, and the cutover only has to bring over the last day's mail.

Step 4: Choose licenses for the active users#

Mailbox and archive sizes come from the license. These are the values on Microsoft's Exchange Online limits page, including the 2026 increase for the Business suites; check the current page before you buy:

Three practical points for 400 users:

• Microsoft 365 Business plans are limited to 300 users per plan, so 400 people usually means an Enterprise plan or a mix, for example Business plans for most users and Exchange Online Plan 2 or E3 for the rest.
• Anyone whose mailbox is between 50 and 100 GB needs a 100 GB license. Exchange Online Plan 1 users who need a large archive can add Exchange Online Archiving.
• After licenses are assigned, check the quota Exchange actually applies with Get-Mailbox amal.hassan@contoso.com | Format-List ProhibitSendReceiveQuota before that user's wave starts.

The 100 leavers don't need licenses at all if their mailboxes fit in 50 GB. Part 3 covers the rules and the exceptions.

Step 5: Pick a method for each kind of data#

Third-party migration tools are a reasonable alternative when you want contacts, calendars or date filters in one pass, and Microsoft's migration performance page lists several vendors. The native tools cover everything in this series at no extra cost.

Step 6: Put the work in the right order#

1. Tenant ready. Add and verify the domain, create the users (synchronized with Microsoft Entra Connect if you have Active Directory, cloud-only otherwise) and assign licenses. The target mailboxes must exist before any IMAP batch can run.
2. Leaver mailboxes. Create the shared mailboxes for former employees (part 3).
3. DNS. Lower the MX record's TTL to 3,600 seconds well before cutover, as Microsoft recommends, and confirm who can change DNS at short notice.
4. FortiMail ready for IMAP. Certificate, firewall rule for Exchange Online, connection limits and credentials (part 2).
5. Analysis and pilot. Size the mailboxes, then run a pilot of five to ten mailboxes that includes one of the largest, and record the GB per hour.
6. Waves. Pre-sync everyone in waves while users stay on FortiMail.
7. Cutover. MX, Autodiscover, SPF and DKIM, then the clients (parts 2 and 4).
8. Final syncs. Keep the batches running for at least 72 hours after the MX change, then remove them.
9. Archives. PST imports and the FortiMail archive decision (part 5).
10. Decommissioning. Retire or rebuild FortiMail after the rollback window and the archive decision.

Risks to settle before the pilot#

• No administrator login for IMAP. Microsoft can migrate with one administrator account only when the IMAP server supports it. Its CSV guidance shows formats for servers such as Exchange, Dovecot and Mirapoint, and FortiMail isn't among them. Unless Fortinet documents delegated IMAP access for your firmware, plan for per-user credentials.
• Directory passwords. If FortiMail checks passwords against Active Directory, the migration password is the user's directory password, and also their Microsoft 365 password if you synchronize password hashes to Microsoft Entra ID.
• Changing FortiMail's mode. Fortinet warns that changing the operation mode resets most of the configuration to factory defaults. Don't switch the production unit to gateway mode until its mailboxes and archives are out and backed up (part 4).
• Retention requirements. Ask legal and HR how long leavers' mail and the archive must be kept, and who may search them. The answers decide parts 3 and 5.
• Oversized items and awkward folders. Messages over 35 MB and folders with a forward slash in the name need manual handling.
• Relay clients. Every application that relays through FortiMail needs a new path before cutover (part 4).

Verify the plan#

Before the pilot starts, you should have these in hand:

• A mapping sheet: every FortiMail account with its Microsoft 365 address, license or shared mailbox, size band and wave.
• Analysis results for every mailbox, with the exceptions listed: active mailboxes over 100 GB, leaver mailboxes over 45 GB, mailboxes over 500,000 items and folders that won't migrate.
• A license plan that covers every active mailbox's size.
• The MX TTL lowered, and the DNS owners briefed.
• A communication plan for users and a rollback plan: the MX record goes back to FortiMail while the batches still run.

After the pilot, add one more number: the measured GB per hour. With it, the wave plan becomes arithmetic rather than hope.

References#

• What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365 (Microsoft Learn)
• Microsoft 365 and Office 365 email migration performance and best practices (Microsoft Learn)
• Choosing the operation mode (FortiMail 7.6.5 Administration Guide, Fortinet)