IMAP migration to Microsoft 365: a business guide

What an IMAP migration to Microsoft 365 resolves

An IMAP migration to Microsoft 365 transfers email that is available on the source server. Before choosing this method, it is essential to verify whether this encompasses all the content your organization requires. Contacts, calendars, rules, and data stored exclusively on local devices require a separate assessment. Otherwise, while users may find their messages in the new environment, they might still find that important information needed for their work is missing.

The inventory should document actual email addresses, source access credentials, data volume, and folder structures. It is also advisable to identify shared accounts and any applications that send email. An address used by multiple employees may require a different configuration than an individual mailbox; such decisions are part of the Exchange Online design process and are not addressed simply by copying messages.

A pilot migration involves testing a sample set that includes recent and older emails, as well as sent items and messages organized into folders. Attachments and any items flagged in the report as omitted or erroneous should be reviewed. Any discrepancies in message counts must be explained, as factors such as date filters, excluded folders, or unsupported content can affect the results. The report should enable you to identify the root cause and determine whether corrective action is necessary.

What to check when changing email reception

Copying data and switching the email service are distinct tasks. Before updating the domain service, you must ensure that recipients, alias addresses, and user access are all properly configured and ready. The plan must specify which environment receives new messages during each phase, and how email that arrives in the legacy system during the transition will be collected.

Following the switch, internal and external sending and receiving must be tested using representative recipients. Web forms, printers, and applications that rely on email should also be reviewed. If these systems continue to point to a legacy configuration, users might be able to work normally in Outlook, while certain business processes fail to send out notifications. These tests must be included as part of the project acceptance criteria.

What IMAP is and why it is used for email migration

IMAP Internet Message Access Protocol (IMAP) allows an email client to access messages stored on a server. Unlike the traditional POP3 model—where messages can be downloaded to a device and subsequently removed from the server—IMAP is designed to keep email data on the server and synchronize its status across clients. This makes it a relatively suitable protocol for retrieving messages during a migration.

Microsoft can connect to the source IMAP server, read the available folders, and copy the messages into the corresponding Exchange Online mailbox. However, IMAP is, at its core, simply an email protocol. It has no awareness of the full Exchange model. For instance, IMAP does not directly account for: Exchange calendars, “Full Access” or “Send As” permissions, rooms, resources, delegates, retention policies, or Microsoft 365 groups.

Consequently, using IMAP to migrate from a more feature-rich platform can significantly reduce the fidelity of the migration.

IMAP, POP3, and Exchange Online: key differences

When an IMAP migration makes sense

IMAP is especially useful when the source system provides primarily email and lacks an API or a more comprehensive migration method.

The question is not just, “Does it have IMAP?” We must also ask: What information do we need to preserve? If we only need to migrate email and folders, IMAP may suffice. If we also need to migrate calendars, contacts, rules, delegations, or resources, we should check if a more comprehensive migration path exists.

When IMAP should not be the first choice

Exchange Server. If the source is an Exchange Server to which we have sufficient access, we should generally evaluate migration paths specific to Exchange. Using IMAP would mean treating an Exchange mailbox as a simple email repository, resulting in the loss of the ability to transfer other elements. Google Workspace. Microsoft currently offers a specific migration procedure for Google Workspace that can handle: email, calendars and contacts and certain additional capabilities.

Therefore, an organization using Google Workspace should not automatically select IMAP just because Gmail also exposes that protocol. Another Microsoft 365 tenant. An Exchange Online → Exchange Online migration should be approached as a tenant-to-tenantmigration, not via IMAP. Microsoft provides a “Cross-Tenant Mailbox Migration” feature, and there are also specialized platforms available. PST files as the actual source. If the IMAP server only retains data from the last few months, but users have years of information stored in PST files, then IMAP may not be the appropriate source.

In such cases, a combination of procedures will be required.

What is migrated via IMAP

Microsoft’s native IMAP migration is designed to copy existing items found within a user’s mail folders.

Not all folders have the same name. Depending on the server, we may encounter: Sent Sent Items INBOX.Sent Enviados Trash Deleted Items For this reason, the pilot should pay special attention when reviewing these specific folders.

What is not migrated via IMAP

This distinction should be explicitly stated in the project scope to prevent users from assuming that “migrating their email” means transferring every single configuration setting they see in Outlook.

Assessment: what to analyze before creating the first batch

An IMAP assessment does not have to be complicated, but it should address the questions that determine the conditions for the migration.

Measuring in gigabytes is not enough. A 20 GB mailbox with 30,000 messages may behave differently than an 8 GB mailbox containing 400,000 small items. In IMAP, the following factors matter: Volume, number of items, message size, number of folders, and the performance of the source server.

Analyzing the source IMAP server

Before creating the migration endpoint, we should check the server’s technical parameters.

Test the endpoint before migrating hundreds of users. One of the objectives of the pilot is to confirm that Microsoft 365 can consistently establish sessions and that the source server does not begin blocking connections as concurrency increases.

Credentials: a critical aspect of an IMAP migration

Microsoft must be able to authenticate against each source mailbox in order to copy its messages.

Native Microsoft CSV

The basic format currently contains:

EmailAddress,UserName,Password
usuario1@empresa.com,usuario1@empresa.com,ContraseñaOrigen
usuario2@empresa.com,usuario2@empresa.com,ContraseñaOrigen

EmailAddress Identifies the destination mailbox in Microsoft 365. UserName Identifies the account on the IMAP server. Password Contains the credential that allows the service to access the source mailbox. Is it necessary to know the passwords for all users? It depends on the server. Some systems allow the use of an administrative account with access to the mailboxes. Others require individual credentials. If the provider does not offer a compatible administrative mechanism and user credentials are not available, this issue must be resolved before the project begins.

The CSV contains sensitive information. Therefore: It should be stored only for as long as necessary, access to it must be restricted, and it should be securely deleted once it is no longer needed. Official reference: Microsoft – CSV files for IMAP migration batches.

IMAP folders: a minor detail that often causes issues

A migration process should review the folders before moving all the mailboxes. Special folders. In particular: Inbox, Sent, Drafts, Deleted, Junk, and Archive. Different names. Two servers may serve the same function while using different structures. Furthermore, some clients may have created personal folders that resemble system folders. Forward slash “/” in folder names. Microsoft’s optimization documentation specifically warns of issues with folders that contain a forward slash in their name. /.

It is advisable to identify these before the project begins and rename them where necessary. Do not migrate junk data unnecessarily. Before moving hundreds of gigabytes, consider excluding: Spam, Junk, Trash, Deleted Items, or historical folders that have no value, provided that company policy allows for it.

What happens if PST files exist, even when using IMAP?

The fact that an account is configured via IMAP does not guarantee that the entire history remains on the server. Users may have created: PST files, AutoArchive files, manual exports, or local Outlook folders. Example.

A migration based solely on IMAP would leave ten years’ worth of data out of the new mailbox. If PST files are included in the scope. We can evaluate: Importing via classic Outlook, the Microsoft Purview Import Service, or another tool. Avoiding overlaps. If a PST file also contains email that is still present on the IMAP server, we will need to determine which items come from which source to minimize duplicates.

Current limitations of Microsoft IMAP migration

Microsoft currently specifies two particularly important limits.

500,000 items. Microsoft processes email from newest to oldest. Therefore, a mailbox that exceeds this number of items requires analysis before using the standard IMAP migration method. 35 MB per message. This limit applies to the IMAP migration process; it should not be confused with the various transport limits that may apply in Exchange Online after the migration.

Items exceeding these limits must be identified and handled via a different method if they need to be preserved. Verify the limits just before starting the project. Cloud service figures are subject to change. Therefore, while this guide reflects the documentation current as of the date of its last update, the runbook should be re-verified before executing an actual migration. Official reference: Microsoft – IMAP migration limitations.

Performance, concurrency, and throttling

The speed of an IMAP migration cannot be predicted based solely on internet bandwidth. At least four factors come into play.

Do not increase concurrency without taking measurements. More connections do not necessarily mean a faster migration. In fact, the opposite may occur if the source server begins to: reject connections, apply throttling, or degrade service for users. A pilot phase helps identify the optimal balance. Microsoft recommends using test batches to determine: actual duration, the appropriate number of connections, and the optimal size for migration waves.

There is no guaranteed speed. Migration services are subject to throttling mechanisms and availability constraints. If a mailbox progresses more slowly over a certain period, it does not automatically indicate a failure. Official references:

• Microsoft – Optimize IMAP migrations
• Microsoft – Migration performance and best practices

Requirements in Microsoft 365

IMAP migration copies data into existing mailboxes.

Verifying a domain does not affect email flow. You can add a domain to Microsoft 365 using the appropriate TXT record and prepare all mailboxes without yet modifying the MX record. This allows much of the work to be completed before the cutover.

Microsoft 365 licenses for Exchange Online

The user requires a license that provisions an Exchange Online mailbox.

Target mailbox size Microsoft currently documents, among others:

The destination mailbox must have sufficient space. If we want to move a 70 GB source to a license where the primary mailbox supports 50 GB, we must first determine: a different license, Online Archive, cleanup, or an alternative design. Official reference: Microsoft – Exchange Online Limits.

IMAP migration via the Exchange Admin Center

Migration can currently be managed from Exchange Admin Center. General path. Within the Exchange Admin Center: Migration → Add migration batch → Migrate to Exchange Online → IMAP migration. The wizard requests:

Do not roll out to the entire company in the first batch. Although it is technically possible to load thousands of rows into a CSV, it is more manageable to divide the project into waves. This makes it easier to: control errors, analyze performance, communicate with users, and adjust concurrency. Official reference: Microsoft – Migrate other IMAP mailboxes.

Preparing the CSV file correctly

The native IMAP CSV uses three mandatory columns.

EmailAddress,UserName,Password
maria@empresa.com,maria@empresa.com,PasswordOrigen1
carlos@empresa.com,carlos@empresa.com,PasswordOrigen2

Meaning.

The source and destination email addresses do not have to be identical. The CSV allows the login used for the IMAP server to differ from the identity of the new mailbox. This is useful during domain reorganizations. CSV limit. Current Microsoft documentation supports up to 50,000 rows and a file size of 10 MB for a CSV file used in an IMAP migration batch.

Nevertheless, Microsoft recommends splitting large migrations into multiple batches. UTF-8. If there are special characters in the identifiers, the CSV file should be saved using the appropriate Unicode/UTF-8 encoding.

Migration endpoint: the connection between Microsoft 365 and the source

The migration endpoint defines how Microsoft 365 will connect to the IMAP server. It includes: server, port, security, and concurrency parameters.

Example

New-MigrationEndpoint `
    -IMAP `
    -Name "IMAP-Hosting" `
    -RemoteServer "imap.empresa.com" `
    -Port 993 `
    -Security Ssl

Concurrency. Settings such as the following can also be configured: MaxConcurrentMigrations and MaxConcurrentIncrementalSyncs. Do not use arbitrary values. The appropriate configuration should be determined based on the pilot phase and the limits specified by the email provider. Official reference: Microsoft – New-MigrationEndpoint.

Migration batch: organizing the migration in waves

Once the endpoint is available, you can create one or more batches.

PowerShell Example

$CsvFile = "C:\Temp\IMAP-Wave01.csv"

New-MigrationBatch `
    -Name "IMAP-Wave01" `
    -SourceEndpoint "IMAP-Hosting" `
    -CSVData ([System.IO.File]::ReadAllBytes($CsvFile)) `
    -AutoStart

Check the status

Get-MigrationBatch -Identity "IMAP-Wave01" |
    Format-List Identity,Status,TotalCount,SyncedCount

Why divide into waves?

Incremental synchronizations: the major operational advantage of IMAP

After the initial synchronization, IMAP batches that remain active can continue copying new messages detected on the source server. Current frequency. Microsoft currently documents an incremental synchronization approximately every 24 hours. This allows for pre-migration. We can begin copying mailboxes several days before the final cutover.

This is not real-time replication. The approximately daily synchronization means that IMAP should not be considered a real-time coexistence platform. The cutover still requires a defined window and a clear procedure. When to stop it. Once you have confirmed that new email is arriving in Microsoft 365 and that you no longer need to retrieve changes from the source, you can delete the batch.

Official reference: Microsoft – IMAP migration with PowerShell.

Excluding or including folders

It is not always necessary to migrate absolutely everything contained on the server. Exchange Online allows for the use of inclusion and exclusion parameters in specific IMAP batches.

Example

$CsvFile = "C:\Temp\IMAP-Wave01.csv"

New-MigrationBatch `
    -Name "IMAP-Wave01" `
    -SourceEndpoint "IMAP-Hosting" `
    -CSVData ([System.IO.File]::ReadAllBytes($CsvFile)) `
    -ExcludeFolders "Trash/*","Spam/*" `
    -AutoStart

Scenarios where exclusions might make sense. Junk, Spam, Trash, temporary folders, or clearly obsolete repositories. Do not apply general exclusions without verifying the actual folder names. A folder named Archive might be dispensable on one server but contain critical information on another. For this reason, the person conducting the pilot must review the actual folder tree. Official reference: Microsoft – New-MigrationBatch.

Useful Exchange Online PowerShell commands during migration

When managing a migration, it makes more sense to use Exchange-specific cmdlets rather than simply checking licenses.

Connecting

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline

Viewing endpoints

Get-MigrationEndpoint |
    Format-Table Identity,EndpointType,RemoteServer

Viewing batches

Get-MigrationBatch |
    Format-Table Identity,Status,TotalCount,SyncedCount

View users in a batch

Get-MigrationUser -BatchId "IMAP-Wave01" |
    Format-Table Identity,Status

Review a user with issues

Get-MigrationUserStatistics `
    -Identity "usuario@empresa.com" `
    -IncludeReport |
    Format-List Status,Error,SkippedItemCount,Report

Review skipped items

Get-MigrationUserStatistics `
    -Identity "usuario@empresa.com" `
    -IncludeSkippedItems |
    Select-Object -ExpandProperty SkippedItems |
    Format-List DateReceived,Subject

Delete the batch when synchronization is no longer needed

Remove-MigrationBatch -Identity "IMAP-Wave01"

These examples are for guidance only. Before executing them, you should verify permissions, names, the batch status, and potential operational consequences.

Monitoring: “Synced” does not mean everything is perfect

The Exchange Admin Center displays various batch statuses.

What to check, beyond the status. Errors, skipped items, last sync, volume, and user-defined checks. A batch can be slow without being broken. Microsoft explains that migration has a lower priority than certain critical Exchange Online functions, such as mail flow and connectivity. Therefore, periods of slowdown may be considered normal behavior. Do not base your diagnosis solely on the percentage.

When a user’s migration appears to be stalled, it is advisable to obtain: Get-MigrationUserStatistics, IncludeReport. Official reference: Microsoft – Troubleshoot IMAP mailbox migration.

Contacts: planning for them outside of IMAP

Personal contacts are not included in an IMAP migration. Where they might be located.

Not all contacts necessarily need to be migrated. There may be thousands of obsolete or duplicate contacts. If the address book has business value, it warrants a separate review.

Calendars: likely the most visible difference for the user

A user might assume that their calendar is part of “the email account,” but IMAP does not recognize it as such. What needs to be identified. Personal calendar, future events, recurring events, shared calendars, room calendars, and local calendars. Options. Depending on the source: PST, ICS, provider export, specialized tool, or manual recreation. Future events first. When it is not possible to migrate everything with complete fidelity, the priority is usually to ensure the user does not lose future meetings and appointments.

Sent Items: review before the pilot phase

Sent messages are typically part of the IMAP structure, provided the folder is correctly stored on the server—though this should not be assumed. Common issues. The email client might store sent messages in: a local folder, a PST file, or an IMAP folder with a different name. Quick check. Comparing the “Sent” folder in webmail with the one in Outlook allows for a quick determination of whether any local content exists.

Generic accounts and shared mailboxes

IMAP hosting providers often use full accounts for addresses such as: info@empresa.com ventas@empresa.com administracion@empresa.com with the password shared among several people. Exchange Online offers a different model. We can consider creating a Shared Mailbox and granting: Full Access, Send As, or Send on Behalf permissions depending on the requirements. Advantage. Each user employs their own identity, rather than sharing a generic password.

50 GB without a dedicated license. Microsoft currently allows a shared mailbox—without its own dedicated license—to hold up to 50 GB, subject to applicable terms. Exceeding this capacity, or utilizing features such as archiving, litigation hold, or other advanced functions, requires the appropriate licensing. Official reference: Microsoft – About shared mailboxes.

Google Workspace: do not limit it to just an IMAP migration

While Google Workspace exposes Gmail via IMAP, this does not necessarily mean that IMAP is the best migration path for a company moving away from Google. Microsoft offers a dedicated migration process. The Google Workspace-specific migration path can handle: email, calendars and contacts and Microsoft has continued to expand its specialized tools for this source environment.

In what cases might IMAP still be relevant?

In very specific scenarios or as a technical alternative; however, it should be weighed against the Google Workspace-specific migration path before making a decision. Official reference: Microsoft – Automated Google Workspace migration.

Domain and DNS: preparing for the cutover

An email migration involves two distinct workflows: migration of historical data and redirection of new email. IMAP batches handle the former, while DNS determines the latter. Key records.

MX records: when to change them

The MX record should be updated once Exchange Online is ready to serve as the production system. Before the change. We should verify: users, licenses, aliases, Exchange Online, batches, mail flow, and critical applications. The MX record does not copy data. Changing the MX record does not move any historical messages; it simply tells sending servers where to deliver new email. Do not cancel the existing hosting immediately.

For a controlled period, it may be advisable to maintain access to the previous system for: incremental synchronizations, validations, and exceptions. Official reference: Microsoft – Connect a domain using DNS records.

SPF during an IMAP migration

The SPF record must account for all systems that are still legitimately sending email on behalf of your domain. A single SPF record. You should not publish one SPF record for Microsoft and a separate one for your hosting provider. There must be a single record that correctly combines all the necessary sources. During the coexistence phase. It may be necessary to temporarily authorize: Microsoft 365, a legacy IMAP provider, CRM, ERP, web services, or a marketing platform.

After. Once a legacy service is decommissioned, you should remove its corresponding source from your SPF record. Official reference: Microsoft – Configure SPF.

DKIM for Microsoft 365

Microsoft recommends using DKIM in conjunction with SPF and DMARC to secure authentication for custom domains. Two CNAME records per domain. Microsoft uses two DKIM selectors. The specific values ​​must be retrieved from your tenant. Important as of 2025. Microsoft has introduced a new DKIM CNAME format for new custom domains. For this reason, it is even more critical not to copy static examples found online..

Obtain the correct values.

You can use the Microsoft Defender portal or Exchange Online PowerShell.

Get-DkimSigningConfig `
    -Identity "empresa.com" |
    Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Official reference: Microsoft – Configure DKIM.

DMARC: managing the transition without blocking legitimate email

DMARC uses SPF/DKIM authentication and alignment with the sender’s visible domain.

Migration is a poor time to discover forgotten senders. Before tightening DMARC, we must identify: ERP, CRM, newsletters, web, ticketing systems, SaaS applications, and any other sender. Reasonable sequence. inventory → authenticate → observe → correct → tighten. Official reference: Microsoft – Configure DMARC.

Autodiscover and Outlook

After the cutover, the user stops connecting to the previous IMAP server and begins working with Exchange Online. The old profile may contain: IMAP server, SMTP server, ports, authentication, PST files, and historical configuration. New profile. In some cases, it may be preferable to create a clean Outlook profile. The decision depends on: Outlook version, profile status, existing PST files, and deployment procedure.

Cloud migration and endpoint configuration are distinct scopes. Mailbox migration can be handled centrally, whereas individual device configuration must be explicitly defined on an as-needed basis.

Applications, websites, and printers that send email

A company almost never consists solely of users sending emails.

These dependencies are not migrated via IMAP. We must determine how they will send emails after the change. Do not reuse old configurations without first analyzing them. The Microsoft 365 SMTP server, port, authentication, and security settings may differ. Furthermore, Microsoft is continuously evolving its authentication methods, so it is important to use the appropriate option for each type of application.

Native Microsoft tools vs. specialized third-party tools

The native tool is perfectly suitable for many projects, though not necessarily for all of them.

What to compare. Cost, authentication, limits, deltas, filters, reporting, mapping, throttling, support, and fidelity. BitTitan. MigrationWiz currently provides a specific guide for IMAP → Microsoft 365. The vendor also explains that their platform is a migration tool, not a live synchronization solution; therefore, it is essential to understand exactly how project passes function. CodeTwo. CodeTwo Office 365 Migration currently supports IMAP servers as a source, allowing for the configuration of connections, throttling, and migration jobs.

The tool does not resolve the inherent limitations of the IMAP protocol. If the source only exposes email via IMAP, a third-party platform cannot automatically “invent” calendars that are not available through that interface. This is why analyzing the source environment is more important than the specific product brand. References:

• BitTitan – IMAP to Microsoft 365 Migration Guide
• CodeTwo – Migration from an IMAP source

Recommended phases for an IMAP migration to Microsoft 365

What the pilot phase should look like

A good pilot should uncover issues before the entire company encounters them.

The pilot phase should provide us with metrics. By the end, we should know: Approximate GB/hour, messages/hour, supported concurrency, typical errors, and manual tasks.

Cutover: moving production to Exchange Online

Once the majority of the content has been synchronized, it is time to switch the mail flow.

TTL. Reducing the TTL for specific records beforehand can help shorten the DNS transition, although it never makes propagation instantaneous.

Migration doesn’t end when the batch status is “Synced”

1. Quantitative validation. Review: Users, volume, folders, items, and errors. 2. Functional validation.

3. Historical data. Check samples of: recent messages, older messages, Inbox, Sent, personal folders, and attachments. 4. Skipped items. Review the skipped items and determine whether: they are acceptable, can be recovered via another method, or should be documented as an exception. 5. DNS. Check: MX, SPF, DKIM, and DMARC. 6. Applications. Validate systems that use email.

What changes for users

For someone accustomed to an IMAP mailbox, the visible change can be significant.

Minimum necessary communication

The user should know: when the change will take place, how to log in, what happens with Outlook, whether any action is required on their part, and where to seek assistance.

How long an IMAP migration takes

There is no standard duration per mailbox.

Example. Two companies might both have 50 users. The first has 50 mailboxes of 3 GB each on a fast server. The second has 50 mailboxes of 25 GB each, hundreds of thousands of messages, and a hosting environment that allows only a limited number of connections. These are not equivalent projects. The best estimate comes from a pilot. By testing a few representative mailboxes, we can better calculate: batch sizes, concurrency, dates, and a buffer for remediation.

Common errors during an IMAP migration to Microsoft 365

Checklist before migrating via IMAP to Microsoft 365

Frequently asked questions about IMAP to Microsoft 365 migration

Does IMAP migrate contacts and calendars to Microsoft 365?

The IMAP method focuses on server-side email. Contacts and calendars must be inventoried and migrated using a procedure compatible with their location and format. It is advisable to confirm this scope before beginning, as a test that only checks messages might overlook information the user has stored in another application or on their local device.

What happens to email stored exclusively on a computer?

Such data cannot be assumed to be included in a copy taken from an IMAP server. First, you must locate where it is stored, verify its format, and agree on a transfer procedure. The user should be involved in reviewing historical folders to distinguish between items already on the server and those that exist only in a local copy.

Can the copying process begin before the domain is switched?

Depending on the tool and the design used, the preparation phase can separate the initial transfer from the actual switchover of email reception. It must be clearly defined which environment remains the active workspace and how subsequent messages will be collected. The switchover should only take place once the destination environment is ready and testing is complete—not simply because an initial copy has finished.

How are messages that failed to copy reviewed?

You should use the generated reports and error identifiers to pinpoint the cause, the affected folder, and the user involved. There may be content that falls outside the scope, source-side restrictions, or items that require a different handling approach. Any discrepancies should be documented and validated with the person in charge; simply repeating the entire migration process without a proper diagnosis may result in duplicates without actually resolving the underlying issue.

Final recommendations: IMAP works very well when you know exactly what you are migrating

A IMAP migration to Microsoft 365 This can be a simple and effective way to move email from hosting providers and compatible servers to Exchange Online. However, its simplicity hinges on a correct understanding of the scope. IMAP allows for the copying of messages and folders; it should not be presented as a complete migration of every feature or capability that a user associates with their email account.

Contacts, calendars, tasks, rules, signatures, delegations, and local settings require an independent strategy. Before beginning, we must also understand the source server. Credentials, connection limits, folder names, and throttling can have a greater impact on the migration timeline than the bandwidth contracted by the organization. Microsoft’s native tool allows for work to be organized via endpoints and batches, enabling initial data loads prior to the cutover, as well as incremental synchronizations—occurring approximately every 24 hours—while the batch remains active.

This significantly reduces the volume of data remaining to be migrated during the final cutover window. We must also be aware of current limitations: Microsoft specifies a maximum of 500,000 items per mailbox and a maximum message size of 35 MB for IMAP migrations. These parameters, along with the number of folders and the behavior of the source server, should be evaluated during the assessment phase.

Furthermore, there are scenarios where IMAP should not be the primary choice. Google Workspace, for instance, has a dedicated path provided by Microsoft that can migrate email, calendar, and contact data. Exchange Server includes its own native mechanisms that offer higher fidelity. Additionally, a migration between Microsoft 365 tenants should be handled as a cross-tenant project. If IMAP is selected, the procedure should follow a clear sequence: discovery → tenant preparation → endpoint setup → pilot → pre-migration → error remediation → cutover → incremental synchronization → validation → decommissioning of the source environment.

The MX record change should only take place once Exchange Online is fully prepared. SPF records must account for all legitimate sources, DKIM must be configured using the tenant’s actual values, and DMARC policies should be evolved in a controlled manner following the verification of authentication. Finally, a project should not be considered complete simply because the dashboard indicates Synced. The migration is complete when users can successfully send and receive emails via Exchange Online, historical data is accessible, any exceptions are documented, applications continue to send mail, and the previous provider can be decommissioned without any ongoing dependency..

Recommended official documentation

IMAP migration.

• Microsoft – What you need to know about migrating IMAP mailboxes
• Microsoft – Migrate other types of IMAP mailboxes
• Microsoft – CSV files for IMAP migration batches
• Microsoft – Optimize IMAP migrations
• Microsoft – Troubleshoot IMAP migration

Migration batches and PowerShell.

• Microsoft – Manage migration batches in Exchange Online
• Microsoft – IMAP migration with Exchange Online PowerShell
• Microsoft – New-MigrationEndpoint
• Microsoft – New-MigrationBatch
• Microsoft – Get-MigrationUserStatistics

Performance.

• Microsoft – Microsoft 365 migration performance and best practices

Exchange Online.

• Microsoft – Ways to migrate email to Microsoft 365
• Microsoft – Exchange Online Limits
• Microsoft – Shared Mailboxes

Google Workspace.

• Microsoft – Automated Google Workspace Migration
• Microsoft – Migrate Google Workspace email, contacts, and calendar

DNS and email authentication.

• Microsoft – Connect your domain by adding DNS records
• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC