IMAP to Microsoft 365 migration
MSAdvance migrates mailboxes from IMAP-compatible servers and providers to Exchange Online, with upfront discovery, pilot testing, controlled migration batches, inbound mail cutover and post-migration validation.
Email to Exchange Online with a scope defined before data moves
An IMAP to Microsoft 365 migration copies content from mail folders on an IMAP-compatible source system into mailboxes that already exist in Exchange Online. The project is not simply about “copying email”: identities, licensing, source access, DNS, users and validation criteria also need to be prepared.
Zimbra, Dovecot, Courier, cPanel, IONOS, hosting providers, ISPs or another platform that exposes IMAP/IMAPS and allows mailbox access.
CUTOVER
Users, mailboxes, domain and security prepared to receive mail and operate through Outlook with modern authentication.
IMAP is a useful migration path, but it is not always the right one
Choosing IMAP simply because “the mailbox supports IMAP” can leave important information behind. Before designing the project, we confirm whether a source-specific migration path can preserve more data or reduce post-migration work.
Hosting and standard email
Dovecot, Courier, cPanel, IONOS, Zimbra and other providers where the primary objective is moving messages and mail folders to Exchange Online.
Legacy platforms
Environments without a modern migration connector or API, but with stable IMAP access that is sufficient to extract email content.
Email plus additional data
IMAP can be used for email and combined with CSV/ICS exports, PSTs or other mechanisms when contacts or calendars are also in scope.
When another route is better
Google Workspace, Exchange Server and Microsoft 365 have dedicated migration methods that usually provide broader coverage than treating them as generic IMAP sources.
Use a dedicated migration service when...
- The source is Google Workspace and Calendar, Contacts, Drive or Shared Drives are also in scope.
- The source is Exchange Server and you need to preserve the broader mailbox model or provide coexistence.
- The source is another Microsoft 365 tenant: use a tenant-to-tenant migration.
- Most historical mail exists locally through POP/PST: review our POP to Microsoft 365 migration approach.
What we validate before accepting IMAP
- IMAP or IMAPS availability, hostname, port and TLS.
- Credential model: administrative mailbox access or per-user credentials.
- Concurrency and throttling allowed by the source server.
- Mailbox size, item count and messages that may exceed the selected migration path limits.
- Special folders, encoding, folder naming and real behavior in a pilot.
The limit is in the IMAP protocol: email yes, a complete mailbox no
To avoid incorrect expectations, we separate what normally travels through IMAP from what requires export, recreation or a source-specific tool. Exact behavior is validated against the source server and the selected migration method.
Messages accessible through IMAP are copied from mail folders. Attachments travel as part of the message as long as they remain within the limits of the selected method.
Compatible folder structure is recreated. Special names, deep hierarchies and source-specific mappings are reviewed during the pilot.
Preservation of flags and certain metadata depends on the source platform and migration tool. We validate this with pilot mailboxes before scaling out.
Microsoft does not migrate contacts through IMAP. They can be handled through CSV, vCard or another export process when supported by the source.
They are not part of IMAP. Calendars may require ICS or another method; tasks depend on the source platform.
They do not move as part of an IMAP migration. They are documented and recreated when included in the agreed scope.
IMAP does not transport the permission model. Exchange Online objects and delegation are designed and configured in the destination.
A PST that exists only on a workstation is not stored on the IMAP server. It must be located and handled through a separate import process.
What Microsoft provides natively for IMAP migrations
Exchange Online provides a native IMAP migration path through the Exchange admin center and PowerShell. It can be useful, but its requirements and limits must be part of the migration design.
Destination mailbox required first
An IMAP migration does not create the Microsoft 365 mailbox. The user and Exchange Online mailbox must already exist and be licensed before email can be migrated.
Official IMAP migration guidanceEmail and mail folders only
Microsoft states that IMAP migration moves items from the inbox and other mail folders. Contacts, calendar items and tasks are outside this migration path.
Mailbox migration optionsNative limits
Microsoft documents a maximum of 500,000 items per mailbox and a 35 MB maximum individual message size for its native IMAP migration path.
Limits and troubleshootingEndpoint and credentials
Exchange Online must connect to the source system through an IMAP endpoint. Access may require per-user credentials or an administrative account supported by the source server.
Set up the IMAP connectionBatches and CSV
For larger migrations, Microsoft allows users to be organized into migration batches using CSV files. The documented format supports up to 50,000 rows and a file size of up to 10 MB.
CSV files for IMAP migrationsIncremental synchronization
The native route can continue incremental synchronization while the migration batch remains active; Microsoft documents a 24-hour synchronization interval for this process.
IMAP migration with PowerShellHow we apply this: we do not present the native path as a universal solution. If message size, item count, authentication, reporting requirements or the source platform indicate another method is more appropriate, we document that alternative before the pilot.
Microsoft native, BitTitan, Cloudiway and automation: the tool follows the scenario
An IMAP migration should not be overloaded with platforms that add no value. We select the method based on source compatibility, authentication model, data volume, pre-stage requirements, reporting and exception handling.
EAC + Exchange Online
Native route for standard IMAP mailboxes when its limits and access model fit the project.
- IMAP endpoint and migration batches.
- CSV for bulk migration.
- PowerShell for automation and control.
MigrationWiz
A common alternative for heterogeneous IMAP sources, with mailbox-based projects, trial migration and pre-stage/full passes depending on configuration.
- Pre-migration testing of mailbox structure.
- Per-user status and error control.
- Not a real-time bidirectional synchronization service.
IMAP Migration
Useful when a specialized platform is needed to migrate mail from IMAP servers and support different credential models.
- IMAP to Microsoft 365 connector.
- Centralized and self-service options depending on scenario.
- Batch configuration and execution.
Automation and validation
We use PowerShell where it adds repeatability to provisioning, endpoints, batches, reporting or destination-tenant checks.
- Exchange Online PowerShell.
- Inventory and validation.
- Documented, repeatable processes.
Eight phases to move from an IMAP server to Exchange Online with control
Actual duration depends on mailbox count, data volume, source performance, connection limits and the cutover window. The plan is sized from assessment and pilot data rather than a generic timeline.
Inventory
Mailboxes, GB, message count, domains, folders, server, credentials and data that does not exist in IMAP.
Technical route
Microsoft native, BitTitan, Cloudiway or another approach; batches, dependencies, window and acceptance criteria.
Destination prepared
Users, licenses, mailboxes, verified domain, roles, security and endpoint ready for testing.
Representative test
We validate folder structure, authentication, throughput, problematic messages and the Outlook experience.
Initial load
We synchronize the bulk of the email before cutover when the selected tool and scenario support it.
Batches and exceptions
Mailbox-level monitoring, retries, errors, non-migratable messages and reconciliation before cutover.
Inbound mail
Coordinated MX and related DNS changes, send/receive validation and a final migration pass according to the selected method.
Stabilization
User access, profiles, mobile devices, incidents, final reporting and closure of remaining items.
The critical part is not only moving messages: it is going live correctly
A mailbox with copied email is not the same as a completed service. Cutover must coordinate identity, authentication, mail flow and security controls so the destination is operational.
Identity and access
- Create or validate users in Microsoft Entra ID.
- Assign the licensing required for Exchange Online mailboxes to exist.
- Apply MFA and access policies at the right point so they do not block migration activity.
- Limit administrative roles and applications to the access required by the agreed scope.
- Remove temporary project access when the migration is complete, when applicable.
Domain, DNS and deliverability
- Verify the domain in Microsoft 365 in advance.
- Plan TTL and MX changes to direct inbound email to the destination.
- Review SPF to include sending systems that remain authorized.
- Enable and validate DKIM in Microsoft 365 when appropriate.
- Review DMARC so the infrastructure change does not create authentication failures.
- Test outbound, inbound, reply and external mail after cutover.
What users may notice when moving from IMAP to Microsoft 365
The goal is to minimize disruption, but some changes are unavoidable when leaving an IMAP provider and adopting Exchange Online. We account for them in communications and go-live support.
Users begin authenticating with their Microsoft 365 identity and may need to register MFA according to tenant policy.
Depending on the client and previous configuration, a new Outlook profile may be required, or the old IMAP account may need to be removed before signing in again.
Devices may require the legacy IMAP account to be removed and the Microsoft 365 account added, or a new sign-in through Outlook for iOS/Android.
They are not part of IMAP content. Server-side rules and signatures must be recreated or deployed through another method if they are in scope.
If they exist in the source system, they are migrated only when an additional supported process has been defined. They must not be assumed to move simply because IMAP email is being migrated.
MX is changed in a coordinated window. DNS propagation and the behavior of external systems can create a transitional period that must be monitored and validated.
Microsoft specialists who also understand source-system limitations
In IMAP projects, many issues appear late: credentials that do not allow bulk access, throttling, inconsistent folders, oversized messages, local-only data or expectations of moving calendars through a protocol that does not include them. Our job is to identify those issues before cutover and turn them into project decisions.
What the customer receives beyond migrated mailboxes
The project should leave a clear record of what was moved, what was outside IMAP scope, what exceptions were found and the service state after cutover.
Inventory and scope
Mailboxes, volumes, domains, source systems, exclusions and additional items.
Technical plan
Method, batches, endpoint, windows, dependencies and responsibilities.
Pilot and validation
Test results for structure, data, authentication and throughput.
Cutover plan
DNS, final passes, mail-flow verification and user communications.
Batch tracking
Mailbox status, incidents, retries and relevant exceptions.
Acceptance checklist
Tests for access, sending, receiving and agreed content.
Hypercare
Stabilization support linked to the cutover during the agreed period.
Closure
Outstanding items, exceptions, temporary access and post-project recommendations.
How the cost of an IMAP to Microsoft 365 migration is calculated
Pricing depends on mailbox count, data volume, source-server accessibility, authentication model, required tooling, DNS work and additional data outside IMAP. We publish a “from” reference for standard scenarios and confirm the final budget after reviewing the source.
Standard mailbox migration
€10From / mailbox · excl. VAT
- Email and folders accessible through IMAP.
- Preparation and execution within a standard scope.
- Batch validation and coordinated cutover.
What can change the budget
- Large data volumes or very high item counts.
- Messages or folders exceeding the selected migration method limits.
- Per-user credentials or complex authentication.
- Contacts, calendars, PSTs, rules or tasks outside IMAP.
- DNS, temporary coexistence or special mail-flow requirements.
- Microsoft 365 licensing and third-party migration tools, quoted separately when applicable.
What we need to size your IMAP migration
With this information we can distinguish a standard migration from a project that requires additional tooling, treatment of non-IMAP data or a more complex cutover window.
What we validate before directing inbound mail to Exchange Online
Cutover is not approved simply because “synchronization has completed”. We verify the conditions required to change MX and support users without improvisation.
Common questions about IMAP to Microsoft 365 migration
Direct answers about scope, limitations, timing, DNS, tools and the end-user experience.
What is an IMAP to Microsoft 365 migration?
It is the process of copying email messages and mail folders from an IMAP-compatible server to Exchange Online mailboxes. Destination users and mailboxes must exist in Microsoft 365 before migration. IMAP does not represent every feature of a modern mailbox, so calendars, contacts, tasks, rules and permissions are handled separately.
What data migrates through IMAP, and what does not?
Email available in IMAP folders can be migrated. Microsoft explicitly states that its native IMAP migration does not move contacts, calendar items or tasks. Rules, signatures, delegation and client settings are also outside the IMAP protocol.
Does Microsoft 365 have a native IMAP migration tool?
Yes. Exchange Online supports IMAP migration endpoints and migration batches through the Exchange admin center and PowerShell. We evaluate the native route alongside specialized tools when the scenario requires them.
What are the limits of Microsoft’s native IMAP migration?
Microsoft currently documents a maximum of 500,000 items per mailbox and a maximum message size of 35 MB for this route. These are limits of the native Microsoft migration path; third-party tools may behave differently and must be assessed separately.
Can contacts and calendars be migrated?
Not through native IMAP. If the source supports export, they can be included as separate work using formats such as CSV, vCard or ICS, or through a source-specific migration path. The method is confirmed during assessment.
Can you migrate from Zimbra, cPanel, IONOS, Dovecot or Courier?
Yes, provided the service exposes IMAP/IMAPS and we can authenticate to the mailboxes. Before finalizing scope and budget, we verify host, port, TLS, credentials, connection limits and folder behavior.
How long does an IMAP migration take?
There is no universal duration. Timing depends on mailbox count, total GB, message count, source-server performance, throttling, available concurrency and error rate. A pilot provides a better throughput estimate before the cutover window is committed.
Will there be email downtime?
The project is designed to minimize impact through pre-loading, migration batches and a coordinated MX change. We do not promise “zero downtime”: DNS propagation, source-provider behavior and client configuration can create a transitional period that must be included in the plan.
What happens to new messages while migration is running?
While MX still points to the source, new mail continues arriving there. With Microsoft native migration, incremental synchronization runs periodically while the batch remains active; with other tools, additional passes are scheduled according to their behavior. Cutover defines when new mail begins arriving in Microsoft 365.
Do MX, SPF, DKIM and DMARC need to change?
They normally need to be reviewed. MX directs inbound mail to Exchange Online; SPF must represent authorized senders; DKIM is enabled for Microsoft 365 where appropriate; and DMARC should align with the new sending architecture. Not every DNS record has to change at exactly the same time.
Will users need a new Outlook profile?
It may be required, especially when a workstation was configured with a traditional IMAP account. In other cases, removing the old account and adding Microsoft 365 or simply signing in again may be sufficient. The approach depends on the mail client, operating system and device-management model.
Why not always use IMAP to migrate Gmail or Exchange?
Because IMAP exposes email only. Google Workspace and Exchange have dedicated migration paths that can preserve more types of data and configuration. Using IMAP in those environments can simplify email transport, but it can also narrow the functional scope of the migration.
Useful information for choosing the right route to Microsoft 365
IMAP is only one migration path. If your source platform has a dedicated migration method or more workloads than email are in scope, these pages can help define the project more accurately.
Microsoft 365 Migration
Overview of source platforms, workloads, methodology and migration options into Microsoft 365.
View serviceGoogle to Microsoft 365
For Gmail, Calendar, Contacts, Drive and Shared Drives when IMAP is too limited.
View Google migrationExchange to Microsoft 365
A dedicated path for Exchange Server when complete mailboxes, identity and coexistence matter.
View Exchange migrationPOP to Microsoft 365
For environments where historical email exists mainly in local mail clients or PST files.
View POP migrationMicrosoft 365 tenant migration
For moving Exchange Online and other workloads between two Microsoft 365 tenants.
View tenant-to-tenantMicrosoft 365 migration case study
A published MSAdvance example showing how a structured Microsoft 365 migration project is planned and executed.
View case studyAbout MSAdvance
Our team, experience, delivery approach and Microsoft Cloud specialization.
About MSAdvanceReview a project
Send us mailbox count, volume, provider, domains and target date so we can define the next step.
Contact usTell us what email platform you use today and we will explain what can be migrated and how
For an initial assessment we need the number of mailboxes, approximate data volume, IMAP provider or server, domains involved and target date. If calendars, contacts, PST files or local data are also involved, include them so they can be scoped correctly.
