IMAP to Microsoft 365 migration

IMAP email migration to Microsoft 365.

We transfer messages from IMAP mailboxes to Exchange Online. We plan the transfer and domain change and identify data that needs separate handling, so that the project distinguishes the email available through IMAP from contacts, calendars or local information requiring another method.

Request IMAP migration Explore the migration process
Laptop being used at a workstation

We inventory mailboxes and check access to the IMAP server before preparing migration. We define which email can be transferred; calendars, contacts and other data need separate assessment and procedures. These limitations are established before the migration scope and the checks for the destination are agreed.

An IMAP migration primarily transfers email messages stored on the source server. This includes the inbox and other email folders available through IMAP. The source needs to be reviewed to establish which folders and messages are accessible and which information may exist elsewhere, outside the scope of a standard IMAP transfer.

This limitation should be clear from the outset. Unlike migration from Exchange or Google Workspace, IMAP migration does not normally include calendars, contacts, tasks, rules, signatures, client settings, autocomplete entries or advanced permissions natively. If these items matter to the business, we assess them separately and define an additional approach, making the work and any limitations explicit before migration begins.

The usual destination is Exchange Online, the business email service included in Microsoft 365. After migration, users can work through Outlook, Outlook on the web, mobile devices and applications compatible with Microsoft 365. The project prepares these accounts and access arrangements so that users can begin working with their transferred email after the change.

  • Email messages: messages stored in the inbox and other mailbox folders available through the source IMAP server.
  • Email folders: the folder structure available on the IMAP server, according to the capabilities of the selected migration method.
  • Attachments: files contained within the email messages transferred from the source mailbox to the destination.
  • User accounts: destination mailboxes prepared in Microsoft 365 for the users included in the migration scope.
  • Email domain: review of DNS, MX, SPF, DKIM, DMARC and Autodiscover where these changes are required by the project.
  • Non-IMAP items: contacts, calendars, rules and signatures are assessed separately where the organisation needs to retain them.

IMAP migration can suit a business using a straightforward email system without complex shared calendar dependencies or advanced features, where the aim is to move mailboxes to Microsoft 365 for improved administration, security and user experience. We review the source and required data first to confirm whether IMAP covers the information that needs to move.

It is common for businesses using hosted email, older provider accounts, their own IMAP servers, corporate webmail or services accessed through clients such as Outlook, Thunderbird, Apple Mail or mobile applications connected by IMAP. These environments need review to establish what remains on the server and which settings or local data require separate handling.

It can also be an appropriate option when leaving an older provider and centralising email in Exchange Online. Before selecting the method, however, we review whether IMAP is sufficient or whether a more complete migration strategy is needed. This avoids assuming that every item visible in an email client can be transferred through the same protocol.

The first critical point is source server access. IMAP mailbox migration requires the server, port, authentication method, username, password or available credentials to be identified, and IMAP access to be enabled for the accounts involved. We check these requirements before transfer so that connectivity and authentication issues can be addressed during preparation.

The second critical point is data volume. Large mailboxes, folders with many messages, slow connections, provider limits or oversized messages can affect migration times. We therefore review sizes, mailbox count and possible restrictions before starting. These details help define the transfer plan and identify items that may need attention or a different approach.

The third critical point is the final email change. During migration, the domain usually continues delivering email to the source system. Once transfer has been validated, DNS changes are planned so that new email reaches Microsoft 365. This stage needs careful coordination to avoid messages being overlooked and to make clear which environment users should access after the transition.

Implementation is organised into the following phases. The activities, dependencies and checks for each stage are defined within the scope agreed for the project and the environment involved.

  1. Assessment: review of the current provider, IMAP server, mailboxes, folders, domain and DNS configuration used by the organisation.
  2. Inventory: users, access credentials, mailbox sizes, message counts and the information that needs to be retained during the transfer.
  3. Migration plan: strategy, batches, schedule, change window and criteria used to validate the migration and destination email service.
  4. Preparing Microsoft 365: users, licences, the domain, Exchange Online and the basic configuration required before mailboxes can receive transferred email.
  5. Pilot migration: migration of selected accounts to validate access, transfer times and the result before the wider migration is carried out.
  6. Main migration: transfer of email and folders from the IMAP source to the Exchange Online mailboxes prepared in Microsoft 365.
  7. Final cutover: updates to DNS and mail flow so that new email is delivered to the mailboxes in Microsoft 365.
  8. Validation: checks on messages, folders, sending, receiving and user access after the transfer and email change have been completed.
  9. Ongoing support: help with Outlook, mobile devices, user questions and the final adjustments required in the new email environment.

Before starting, it is important to confirm which mailboxes will migrate, which users remain active, which data matters, which IMAP server is used, whether access credentials are available, whether the provider imposes limits and whether information outside email must be retained. These points establish the transfer scope and any additional procedures needed beyond IMAP.

Users also need to understand what will happen during the change. They should know when to start using Outlook or Outlook on the web, whether devices need reconfiguration, what will happen to the old webmail service and whom to contact about messages still pending or questions after migration. The instructions should reflect the sequence agreed for the project.

After migration, email should be operational in Exchange Online. We review whether users can sign in, send and receive messages, see migrated folders, configure Outlook, access email from mobile devices and work in the new Microsoft 365 environment. These checks assess the result against the mailboxes and access arrangements included in the agreed project scope.

We agree the scope, responsibilities and priorities with your team. We document the work and the checks carried out. Any additional requirement is assessed before it is incorporated into the project or the support service, so that the implications for the agreed work are understood.

We answer common questions about moving email from IMAP servers to Microsoft 365. We also include links to official documentation for further technical detail, helping distinguish the messages and folders supported by IMAP from other information that requires separate assessment and handling during a migration project.

It is the process of transferring email messages from an IMAP-compatible server into Exchange Online mailboxes in Microsoft 365. The transfer primarily covers the email available through the source IMAP server, with other data and user configuration assessed separately as part of the project scope.

Microsoft provides an official guide to migrating other types of IMAP mailbox to Microsoft 365.

An IMAP migration primarily transfers email messages located in the inbox and other mailbox email folders. It does not reproduce all of an email client’s information or settings, so the source needs review to establish which messages are available and which additional items the organisation needs to retain separately.

Microsoft states that IMAP migrations do not migrate contacts, calendar items or tasks. See the official guide on what you should know before migrating IMAP mailboxes.

Not natively through IMAP. The protocol is designed for email and its folders, rather than calendars, contacts or tasks. These items need separate review where the business wants to retain them, including where they are currently stored and which methods the source and destination support for transferring them.

If contacts or calendars need to be retained, we assess options such as export, import, manual migration, PST/CSV files or another method, according to the source provider and business requirements. Any additional work is defined separately from the IMAP message transfer.

Yes. Where the provider supports IMAP access, we can assess migration of email accounts hosted in cPanel, Plesk, webmail, traditional hosting or an organisation’s own IMAP servers to Exchange Online. The assessment establishes which data is accessible and the requirements that need to be met before transfer can start.

Before starting, we check the server, port, authentication, credentials, mailbox sizes, message counts and any provider restrictions that could affect access, transfer speed or the information that can be moved.

IMAP provides access to email stored on a server and synchronises message folders. POP3 usually downloads messages to a client and may not retain the complete structure on the server. Exchange Online is Microsoft 365’s business email service, with mailboxes, calendars, contacts, advanced administration and closer Outlook integration. These differences affect which information is available for migration and the method needed to transfer it.

If your current email uses POP3, we review the situation because the messages may require a different approach from standard IMAP migration, particularly where data has been downloaded to users’ devices.

Timing depends on mailbox count, account sizes, message volumes, source server speed, provider limits, available connection and environment complexity. These factors need to be reviewed together before estimating preparation, transfer, the final mail flow change and the checks required to validate email in the destination environment.

After the initial assessment, we can estimate the work by phase. For environments with many users, we recommend pilot testing, migration in batches and validation before the final change to Microsoft 365.

We plan migration to reduce interruptions. Much of the email can usually be copied before the final change, while mail flow remains on the current system until DNS records are updated. The transfer and cutover sequence needs to account for new messages and the checks required before users begin working in the destination.

The most sensitive stage is often the MX record change and final configuration of users, Outlook and devices. These activities are coordinated with the timing agreed for the transition.

To deliver email to Microsoft 365, DNS records such as MX, SPF, DKIM, DMARC and Autodiscover normally need updating, according to the environment. The required records and their timing are reviewed as part of the migration plan, alongside the transfer of messages and validation of the new email service.

Microsoft’s IMAP migration documentation explains that, after migration is completed, the MX record is pointed to Microsoft 365 so that email is delivered to the new mailboxes. This step needs coordination with the planned change window and user access arrangements.

IMAP migration requires access to the source mailboxes. Depending on the provider, this may involve available or reset passwords, administrative credentials, a migration file or coordination with the client’s technical team. The appropriate method is established before transfer so that access requirements are understood and can be prepared through the agreed project process.

Before the project starts, we explain exactly which access arrangements are needed and how to prepare them, taking account of the source provider and the method selected for migration.

After the change, users usually need to configure their Microsoft 365 account in Outlook, Outlook on the web, mobile devices or compatible applications. In some cases, removing the old account and adding the new one is appropriate. The steps depend on the clients and access arrangements used by the organisation.

We can assist users during this stage to reduce incidents and check that email works correctly in the new environment, including the access arrangements and clients covered by the support scope.

It depends on the source provider’s limits, mailbox volume, message count and Microsoft 365’s restrictions for IMAP migrations. These details need review before scope and timing are agreed, so that any unsupported or problematic items can be identified and their treatment discussed before the transfer begins.

Before migration, we review sizes, folders, older messages, possible errors and retention requirements to define the most appropriate strategy for the information and platforms involved in the project.

Yes. After migration, we can help with validation, Outlook configuration, mobile devices, incident resolution, DNS reviews, user questions and Microsoft 365 administration recommendations. The work is defined around the email service moved and the support arrangements agreed for the period after the transfer and change have been completed.

We can also help review shared mailboxes, aliases, security, domain authentication and good operating practices for the new environment, according to the requirements and scope agreed with the organisation.

Tell us about the current platform, the number of users or resources involved and your priorities. We will review the context to define the next steps and the scope of the proposal for your organisation.

Contact Kloudeal