Moving a few mailboxes is a weekend task. Moving 800 is a project. Many companies still run Postfix for mail delivery and Dovecot for IMAP storage, and they are now shifting to Microsoft 365 for bigger mailboxes, stronger security, and built-in malware protection. This guide explains what can go wrong, how to run the migration natively, and when a dedicated tool makes more sense.
Why Large IMAP Migrations Go Wrong
At scale, small problems multiply. These are the issues admins hit most often:
- Broken folder structure: Years of nested Dovecot folders can be flattened, renamed, or dropped.
- Crashing jobs: Very large mailboxes may cause a batch to fail partway through.
- Slow transfers: IMAP throttling, connection caps, and limited bandwidth stretch timelines.
- Authentication trouble: Legacy login methods, expired tokens, and mismatched credentials can block the connection before any data moves.
Picture a mid-sized company with 800 users across several departments. Postfix routes the mail, Dovecot serves it, and every mailbox has a different size and a deep folder tree. Here, preserving folders and keeping jobs stable matters more than raw speed, because one mapping mistake gets repeated hundreds of times.
Manual Migration: Step by Step
If your team is comfortable with IMAP and DNS, the native Exchange Online method works.
1. Prepare Microsoft 365. Create the tenant, verify your domain, add user accounts, and assign Exchange Online licenses. Confirm that mailbox storage limits fit each user’s needs.
2. Create the migration endpoint. In the Exchange admin center, open Migration, then Migration endpoints, and choose New. Enter your Dovecot server’s FQDN or IP and the port (993 for SSL, 143 for TLS). Set a sensible maximum for concurrent connections so Dovecot isn’t flooded, and test the connection before saving.
3. Build the CSV file. Every source mailbox must map to a destination mailbox. Use the exact headers EmailAddress, UserName, and Password, with no extra spaces. Check spelling and domains carefully, then split the list into batches of around 100 users instead of uploading one huge file.
4. Run a pilot. Migrate 10 to 20 users first. Native IMAP migration has no demo mode, so this is your only real test. Check that folders arrived intact, and fix any credential, mapping, or endpoint errors.
5. Start the bulk batches. Launch batches of roughly 100. Remember that Microsoft processes a limited number of mailboxes at once, so plan your schedule around that. Incremental syncs run periodically so new mail keeps flowing in during the migration.
6. Verify and cut over. Compare item and folder counts between source and destination, and test Outlook and mobile sign-in for a sample of users. Then update your MX record and allow 24 to 72 hours for DNS propagation. Once all mail routes to Microsoft 365, remove the migration batches to stop syncing.
Drawbacks of the Native Method
The built-in approach is free, but it has real costs at this scale:
- It consumes many hours of admin time.
- A single typo in the CSV can cause a mailbox to be skipped.
- Only a limited number of mailboxes sync simultaneously.
- Nested folders may be renamed or broken.
- Error messages are often vague, which makes troubleshooting slow.
- It demands solid knowledge of IMAP and DNS.
Best Practices Before You Begin
- Pilot first. A small test batch exposes mapping and folder problems before they affect everyone.
- Check the folder hierarchy early. Structural damage is painful to repair later.
- Use modern authentication. Outdated login methods are a leading cause of failed migrations.
- Back up every mailbox. Keep a copy of critical data before touching anything.
- Communicate with users. Tell them about the cutover date and any expected downtime.
Using a Dedicated Tool: Aryson IMAP Backup Tool
When manual work becomes too slow or error-prone, third-party software can help. The Aryson IMAP Backup Tool is a desktop application that supports Postfix, Dovecot, and other standard IMAP servers. It can import a CSV file to process all 800 accounts together, and it is designed to keep the folder hierarchy intact. Timing still depends on how much data you move.
Basic steps:
- Install and launch the tool.
- Choose the IMAP migration option and sign in with your Postfix/Dovecot credentials.
- Review the folders and files you want to move, then click Next.
- Pick Microsoft 365 as the destination and log in.
- Apply any filters or options you need, such as date range, duplicate removal, or attachment handling.
- Click Next to start, and monitor progress in the Active Tasks panel.
Useful features mentioned by the vendor:
- Date-range filters to migrate only selected periods
- Duplicate removal to cut redundant data
- Options to skip attachments or save them separately
- Export to formats such as PST, PDF, or JSON
- A free-up-server-space option for the source
- A demo version limited to 100 emails per folder, handy for testing
- Live chat support
Always run the demo on a few accounts first, just as you would with a native pilot.
Which Method Should You Choose?
| Factor | Native Migration | Dedicated Tool |
|---|---|---|
| Cost | Included with Microsoft 365 | Paid license |
| Setup effort | High (CSV, endpoint, DNS) | Moderate |
| Bulk handling | Batches of ~100, limited concurrency | CSV import for all accounts |
| Folder control | Can break nested folders | Built to preserve hierarchy |
| Filtering | Limited | Date range, duplicates, attachments |
If your team has the time and IMAP expertise, native migration is perfectly workable. If deadlines are tight or folder accuracy is critical, a specialized tool can reduce risk.
Final Thoughts
Migrating 800 Postfix/Dovecot mailboxes to Microsoft 365 is a planned project, not a quick job. Whichever route you pick, test on a small group, validate folder structures early, secure authentication, and keep backups. With that groundwork, the move can be smooth and your users barely notice the change.
