POP3 migration to Microsoft 365: mail, PST files and IMAP

In a POP3 environment, the location of the email history determines the migration approach

Migrating from POP3 to Microsoft 365 begins by determining where the messages are actually located. POP3 is a download-based protocol, and its configuration may have resulted in some emails being stored exclusively on individual computers. The server might only hold an incomplete copy compared to what each employee sees in Outlook. Therefore, a server-side migration should not be approved without first reviewing the local data.

Consider a scenario where an employee keeps several years’ worth of email in a PST file, while another computer in the department stores more recent messages for the same address. Copying both sources without analysis could lead to duplicate information, while copying only one might result in the loss of historical data. The inventory must map each person, mailbox, computer, and file, and establish which source will be used for specific time periods or sets of folders.

While users can assist in locating content, the identification process requires technical verification. It must be confirmed that the files can be opened, their folder contents must be checked, and any personal information—or data outside the agreed-upon scope—must be identified. Before any action is taken, a protected copy of the source data must be secured, and the import procedure documented, ensuring that any potential issues do not necessitate a complete reconstruction of the inventory.

How to review email history without reducing the assessment to a mere item count

Acceptance criteria should incorporate time periods, folders, and examples that are recognizable to the user. Testing should cover older messages, sent items, relevant attachments, and the ability to search through conversations. While quantitative data provides a useful guide, it is insufficient on its own to determine whether two sources contain duplicate items or if a folder was archived outside the primary mailbox.

Following the import, the new access to Exchange Online must be configured, and it should be verified that new messages are being saved to the correct location. Maintaining multiple profiles without clear guidance on which one to use can result in information continuing to accumulate in an outdated location. The closure process must include instructions for use and a documented decision regarding the retention of local source files.

What POP3 is and why it complicates migration

POP3 —Post Office Protocol version 3 (POP3)— is a legacy protocol used to download email from a server to a client. For many years, it was a common solution for small businesses: each employee would configure their account in Outlook, Thunderbird, or another client and download messages to their computer. The issue is not necessarily that POP3 stops working; rather, the problem arises when we need to migrate all the data accumulated over the years to another platform..

The server may not contain the entire history.

Depending on the configuration, Outlook may download messages and subsequently delete them from the server. We might encounter the following:

This is why an account that occupies 700 MB on the hosting server might end up containing 15 GB of relevant information once all of the user’s PST files have been reviewed. POP3 also does not store calendar data. POP3 is an email protocol. It does not, by itself, provide synchronization for: calendars, contacts, tasks, delegations, or Outlook settings. These items may be stored on the local client and must be explicitly included in the assessment if we wish to preserve them.

POP3, IMAP, and Exchange Online: three distinct models

The migration does not consist of converting POP3 to Exchange. What we actually do is: retrieve the available data from various locations and upload it to a new Exchange Online mailbox. Once the project is complete, the user no longer relies on the POP3 model for email.

The real challenge: identifying the master source for each piece of data

Before selecting a tool, we need to answer one question for each user: Which is the most complete copy of their email? Case 1: The server is more complete than Outlook. This can happen if POP3 was configured to keep all messages on the server. If IMAP is also in use, the server may be the best source for the migration. Case 2: Outlook is more complete. Very common.

The server retains little history, while the user has a PST file containing years of email. Case 3: The server and Outlook contain different information. This is one of the more complex scenarios. There may be: recent messages on the server, historical data stored locally, items sent only from within Outlook, or additional local folders. Case 4: There are multiple computers. If the same mailbox has been configured via POP on multiple devices, there may be different messages on each machine.

We should not arbitrarily choose one and delete the rest. Case 5: Archive PST files exist. In addition to the PST file associated with the current account, there may be files created via: AutoArchive, manual exports, backups, or previous migrations.

Pre-migration inventory by user

The discovery phase should involve creating a simple record for each mailbox.

It is not necessary to manually inspect every email. The goal is not to read the contents of the mailboxes. We need to determine: which sources exist, the size of each, the date range covered, and whether there are any obvious discrepancies.

What to examine on the current mail server

Even if users work via POP3, the provider may also offer IMAP. Basic data.

Webmail as a quick check. A simple way to understand what the server retains is to log in via webmail. If webmail only shows messages from 2025, but Outlook contains emails dating back to 2014, we know immediately that a migration based solely on IMAP will be insufficient.

How to locate and categorize PST files

A Outlook Data File (.pst) may contain emails, contacts, calendar entries, tasks, and other Outlook items. In POP environments, there may be multiple files per user. Do not assume that there is only one PST file. You may encounter names such as: correo.pst archivo.pst archive2019.pst backup-outlook.pst usuario-antiguo.pst What to record.

Do not move the original PST files until their contents are identified. During the assessment, it is advisable to keep a secure copy and avoid ad-hoc reorganizations. The goal is to be able to revert to the original source if any issues are detected during the upload process.

What can actually be migrated

The four common scenarios for POP3 migration

Scenario A: The server retains the email. The user works via POP3, but the provider also offers IMAP, and the email history remains on the server. This is the simplest scenario. We can use: an IMAP migration to Exchange Online, while handling calendars, contacts, or other local data separately, as needed. Scenario B: The server is essentially empty. Messages were historically downloaded to Outlook.

In this case, an IMAP migration would be of little value. We primarily need to work with: PST files → Exchange Online. Scenario C: Server and PST files. This is arguably the most common scenario. For example:

If we import everything without accounting for potential overlap, we may end up with duplicates. We will explain how to address this later. Scenario D: Selective migration. Not all companies want to import fifteen years’ worth of email into the primary mailbox. We can choose to:

IMAP migration to Microsoft 365

Microsoft provides a native migration method for IMAP-compatible systems. This procedure can be performed via the Exchange Admin Center or Exchange Online PowerShell. What it migrates. IMAP migration is designed to move: email messages and folders. It does not migrate: contacts, calendars, or tasks.

General workflow

Official reference: Microsoft – IMAP mailbox migration to Microsoft 365.

Current limitations of Microsoft IMAP migration

As of the date this guide was updated, Microsoft documents two particularly important limits.

Messages are processed from newest to oldest. This is relevant when a mailbox exceeds the maximum item count. We should not discover this only after the cutover. Message larger than 35 MB. If a message exceeds Microsoft’s IMAP migration limit, it should not be assumed that it will automatically appear in Exchange Online. A different transfer method may be required for that content.

The source server may also impose limitations on the migration. While Microsoft may allow a certain level of concurrency, the hosting provider might impose limits on: simultaneous connections, sessions per user, connections per IP address, or throttling. For this reason, performance should be measured through a pilot phase. Archiving policies during migration. Microsoft recommends ensuring that archiving or MRM (Messaging Records Management) policies do not interfere while an IMAP migration is being validated, as items that are moved automatically may appear to be missing during the comparison process.

In environments with legal or compliance requirements, any policy modifications must be reviewed beforehand and must never be used to circumvent data retention obligations. Official reference: Microsoft – IMAP migration limitations.

Incremental IMAP synchronization

A significant advantage of Microsoft’s native procedure is that it is not strictly necessary to perform a single, one-time copy on the day of the cutover. Initial Sync. Existing content is migrated first. Incremental Sync. While the migration batch remains active, Microsoft’s current documentation indicates an incremental synchronization approximately every 24 hours. New messages arriving on the source server can be copied during these subsequent passes.

This enables a pre-migration phase. In this case, the plan includes: Wednesday—begin migration; Thursday–Friday—review progress; weekend—update MX records; subsequent days—maintain the migration batch temporarily, verify the flow, and finalize synchronization. MX records and synchronization are distinct concepts. Updating the MX records determines where new email is delivered.The IMAP batch is responsible for copying existing content or any changes detected at the source..

Therefore, the strategy must coordinate both elements. Official reference: Microsoft – IMAP migration with Exchange Online PowerShell.

Importing PST files using Microsoft Purview

When messages are no longer on the server, the IMAP method is no longer sufficient. If the data exists in PST files, we can use the Microsoft 365 import service via Microsoft Purview.. There are two official methods. Microsoft currently documents the following:

Network Upload is generally the most practical approach. For an enterprise-level POP3 migration where PST files have been centralized, we would typically evaluate Network Upload before considering a manual, user-by-user upload process. A separate Azure subscription is not required. Microsoft provides the necessary temporary storage as part of the import procedure. Permissions. Microsoft recommends applying the principle of least privilege.

The current procedure uses roles such as: Mailbox Import Export and Mail Recipients in Exchange Online, or equivalent administrative permissions as required by the procedure. Official reference: Microsoft – Import PST files to Microsoft 365.

How PST imports via Network Upload work

This process offers greater control than manually copying the file within Outlook. 1. Obtain the SAS URL and AzCopy. The information required to access the temporary storage is obtained via Microsoft Purview. The SAS URL contains access credentials and must be protected like any other administrative secret. 2. Upload PST. Microsoft requires the use of the version of AzCopy specified in its procedure for a supported upload.

Microsoft explicitly states that Azure Storage Explorer should not be used as a substitute for this process when performing the documented PST upload. 3. Create the CSV mapping. We must specify which file corresponds to which mailbox.

4. Create the import job. The job is currently created via: Microsoft Purview → Data Lifecycle Management → Microsoft 365 → Import. 5. Analyze PST files. Microsoft analyzes the data before importing it. 6. Apply filters, if desired. We can choose not to import all the content. Microsoft allows for the application of specific filters based on: age and message types. 7. Import. The job processes the PST files and imports them into the mailboxes defined in the mapping.

8. Review results. We must check: status, skipped items, corruption, destination mailbox, and expected volume. Official reference: Microsoft – Use network upload to import PST files.

PST file size and performance

An import of 200 GB distributed across 20 users does not behave the same way as a single 200 GB PST file. Microsoft recommends PST files of approximately 20 GB or less. Microsoft’s current troubleshooting documentation advises against using excessively large PST files. If a PST file exceeds approximately 20 GB, Microsoft notes that processing may slow down and recommends considering splitting the file.

Typical performance. Microsoft currently cites a typical rate of approximately 24 GB per day for importing a PST file into a mailbox. This is not an SLA. The service operates on shared infrastructure, and actual performance may vary. Multiple PST files to the same mailbox. If you import several files simultaneously into the same mailbox, you should not simply multiply that rate linearly. Microsoft processes imports to the same destination in a way that means they can affect one another.

Imports to different mailboxes. Parallelization is generally more effective when the PST files have different destinations. Plan using a pilot phase. You should not say: “We have 500 GB, so it will take exactly X hours.” It is advisable to perform an initial, representative data load and use the results to refine the schedule.

How to avoid duplicates when combining IMAP and PST data

This is one of the most critical aspects of a POP3 migration. Example. Consider the following scenario:

If both are migrated in their entirety, data from the years 2023–2026 might appear in both sources. Purview includes its own built-in duplicate detection mechanism. Microsoft documentation states that the PST service uses information— SourceEntryId —to identify duplicates during the import process. However, this should not be interpreted as a universal guarantee of deduplication across data arriving via different mechanisms. A message previously copied via IMAP and the same message contained within a PST file may have reached the destination through technically distinct paths.

Planning the overlap period. There are several possible strategies.

Do not aim for “zero duplicates” through aggressive deletion. In a real-world migration, it is preferable to tolerate a few controlled exceptions rather than deleting valid email based on unreliable deduplication. Criteria must be defined before the cutover. Official reference: Microsoft – PST Import FAQ.

Importing PST files via Outlook

For a small number of users and reasonable data volumes, Outlook can also be used to move information from a PST file to an Exchange Online mailbox. Classic Outlook. Microsoft provides the following procedure: File → Open & Export → Import/Export → Outlook Data File (.pst). The content can be imported into a Microsoft 365 mailbox. When it may suit.

A PST file can contain more than just email. Classic Outlook can import: email, contacts, and calendar items contained in a PST file—within the scope of its supported capabilities. However, certain properties and settings are not exported or imported. Microsoft notes, for example, that folder properties, specific configurations, rules, and lists of blocked senders should not be expected to be transferred via a PST file. Official reference: Microsoft – Import email, contacts, and calendar from a PST file.

PST files and the “new” Outlook in 2026

This point has changed; it is best to avoid outdated information. The new Outlook can now open PST files. Microsoft currently allows: Opening PST files, reading and searching for emails, and moving messages between a PST file and a mailbox via drag-and-drop. However, this is not yet equivalent to the support provided in the classic version of Outlook. As of the latest update to this guide, Microsoft indicates that a full, bulk import from a PST file into a mailbox is not yet available in the new Outlook.

Calendars and contacts within a PST file. Microsoft also indicates that calendar items and contacts stored in a PST file are not currently available in the new Outlook in the same way.

For an enterprise migration, we should not rely on the user’s local client. If there are dozens of PST files, using the Purview procedure or another centralized tool provides a much more manageable approach than opening them manually, one by one. Official reference: Microsoft – PST support in Outlook.

What happens to contacts

POP3 and IMAP do not migrate contacts as part of the email data. Possible locations. Contacts may be located in: PST files, Outlook, CSV files, a mobile device address book, or another platform. PST. If they are stored within a PST file, the classic version of Outlook can import them into the corresponding mailbox. CSV files. Depending on the source, CSV import procedures can also be used. Corporate contacts versus personal contacts.

We should not confuse: personal Outlook contacts with users and contacts in the Microsoft 365 corporate directory.

What happens to calendars

Calendar data is also not included with POP3 or IMAP. It may be contained within a PST file. If Outlook stored appointments and meetings in a PST file, they can be included in an import using the classic version of Outlook. Do not assume that all meetings will continue to behave in the same way. A historical calendar may contain: recurring meetings, external attendees, past events, and appointments without a valid organizer.

It is advisable to pay particular attention to the future calendar. New calendar. Once in Exchange Online, users will have a calendar synchronized with their new mailbox and will be able to use Microsoft 365 features—such as availability (free/busy), meeting invitations, and shared calendars—depending on the configuration.

Rules, signatures, and Auto-Complete

These are items that users typically consider part of “their email,” but technically, they require a different approach.

Do not let minor details become blockers. The priority for the cutover should be: Incoming email, outgoing email, historical data, essential calendar entries, and necessary contacts. Individual preferences can be addressed later, as appropriate.

Sent items: one of the most frequently overlooked elements POP3

In many POP environments, the “Sent Items” folder exists only within Outlook; the server may not hold a copy. Why it matters. For certain departments, sent messages can be even more important than the inbox. For example: Sales, administration, legal, purchasing, or management. What to validate.

Generic accounts and shared mailboxes

In POP environments, it is common to find accounts such as: info@empresa.com administracion@empresa.com ventas@empresa.com with a password shared among several people. Microsoft 365 allows for an improved design. Where appropriate, we can create a Shared Mailbox and grant access to individual users. This way, each person can authenticate using their own identity instead of sharing a generic password. Licensing.

Microsoft currently states that a shared mailbox can function without its own dedicated license, up to certain capacity limits. Without a dedicated license, the current standard limit is 50 GB. Exceeding this size, or utilizing specific features such as archiving, litigation hold, or other advanced capabilities, may require additional licenses. Users who access the mailbox do require an Exchange license. Individuals accessing a shared mailbox must be properly licensed for Exchange Online.

Official reference: Microsoft – Shared mailboxes.

What license does a user need after migration?

The technical objective is to create an Exchange Online mailbox, but the final licensing depends on the user’s specific needs.

Mailbox size. Current limits documented by Microsoft include, for example:

Limits and plans should be re-verified at the time the project is contracted. Official reference: Microsoft – Exchange Online Limits.

Domain and DNS: new email must land in Exchange Online

Data migration and the redirection of email flow are two distinct activities. It is possible to have a large portion of the historical data already loaded into Microsoft 365 while continuing to receive email via the previous provider until the cutover window. Records we typically review.

Verifying the domain does not change the email. We can add and verify the domain in Microsoft 365 before the cutover. Inbound mail delivery is not redirected until we modify the MX record.

MX record: the redirection point for incoming email

When we update the MX record, new senders begin delivering mail to Microsoft 365 as the DNS change propagates. Do not change it before preparing the mailboxes. Before the MX change, we must have validated: users, licenses, the domain, Exchange Online, mail flow, and sending/receiving capabilities. Historical data is not moved by the MX change. This is important. The MX record only controls new mail.

Existing messages remain where they were until we migrate them via IMAP, PST, or another procedure. Previous provider. We should not cancel the previous provider immediately after the switch. First, we must confirm that: all new mail is arriving in Microsoft 365 and there are no remaining dependencies. Official reference: Microsoft – Connect your domain by adding DNS records.

SPF: do not create two records

SPF is especially important during a transition because multiple sending sources may temporarily coexist. A fundamental rule. Microsoft states that a domain must have a single SPF record. If the domain already has one, we should not add a second, independent record for Microsoft 365. During the coexistence phase. We may need to temporarily authorize: Microsoft 365, a previous provider, a CRM, an ERP, or a marketing platform if they all continue to legitimately send email using the domain.

After the project: We should clean up sources that no longer exist. Keeping unnecessary, legacy providers in the SPF record expands the authorized sending surface. There is also a limit on DNS lookups. An SPF record cannot grow indefinitely through the addition of include:statements. The design must respect the standard’s limitations and the actual sources in use. Official reference: Microsoft – External DNS records for Microsoft 365.

DKIM: preparing for the new provider’s signature

When Exchange Online becomes the sending platform, we recommend configuring DKIM for the domain. Microsoft uses CNAME records. The specific values ​​must be obtained from your Microsoft 365 tenant. You should not blindly copy records from another tenant or from an example found on the Internet. During the transition: Google, a previous hosting provider, or other platforms may continue to have their own DKIM selectors.

There is no conceptual issue with a domain having different selectors for different services. Validate afterwards. Once DKIM is enabled, we should send test messages and verify that the headers correctly reflect the expected signature and authentication. Official reference: Microsoft – Configure DKIM.

DMARC: do not tighten policies blindly during the cutover

DMARC uses SPF and DKIM results in conjunction with domain alignment. Three main policies.

A migration changes the sending sources. If we implement it directly p=reject without having inventoried: CRMs, web forms, ERPs, printers, accounting software, and marketing platforms, we may negatively impact legitimate messages. A safer approach. Typically, it is advisable to: inventory → configure SPF/DKIM → monitor → remediate → tighten. Official reference: Microsoft – Configure DMARC.

Autodiscover and Outlook configuration

Exchange Online uses Autodiscover to help Outlook clients correctly locate the service. After a platform migration. A computer that had been configured for years using: POP3 and a manual SMTP server must be updated to connect as a Microsoft 365 / Exchange Online mailbox. Outlook profile. Depending on the environment, it may be better to create a new profile rather than reusing a legacy POP configuration that includes multiple PST files and outdated settings.

This is different from cloud migration. Creating and migrating mailboxes in Microsoft 365 does not automatically require individual intervention on each user’s device. It is advisable to clearly define which tasks the local IT team will handle and what instructions users will need following the cutover.

Applications, printers, and systems that send email

One of the most common risks is overlooking non-human entities that send email.

Do not automatically copy over old usernames and passwords. Microsoft 365 offers various methods for sending email from devices and applications. The appropriate method will depend on: authentication, volume, origin, the need to send internally or externally, and application compatibility. Basic Authentication. A new migration should not be designed based on legacy authentication if a suitable modern mechanism is available. Create an inventory before the MX record change.

Depending on the design, these applications should be tested either before or immediately after the cutover.

Leveraging the transition to improve email security

Moving to Exchange Online allows for the implementation of a more modern identity and protection strategy; however, security depends on the specific configuration and licensing. MFA. Users should have an appropriate authentication mechanism in place, while administrators should be subject to particularly stringent security protections. Conditional Access. If the license includes Microsoft Entra ID P1, we can design more granular access policies. Defender for Office 365.

The available capabilities depend on the purchased plan. SPF, DKIM and DMARC. These must be part of the domain transition and should not be considered optional tasks to be addressed “later.” Administrators. It is best to avoid using an administrative account as a standard user mailbox when roles can be separated.

Recommended phases for a POP3 to Microsoft 365 migration

Phase 1: Discovery. We review: users, provider, POP3, IMAP, webmail, PST, Outlook, calendars, contacts, domain, DNS, and applications. Phase 2: User classification. Not everyone will follow the same method.

Phase 3: Microsoft 365 design. We define: users, licenses, shared mailboxes, domain, security, and the delivery method for applications. Phase 4. Tenant preparation. We configure the environment necessary to receive data and email. Phase 5. PST centralization. When the project includes local historical data, we collect and categorize the necessary PST files. Phase 6. Pilot. We select representative users. Phase 7. Pre-migration. We perform IMAP and/or PST uploads prior to the cutover, whenever possible.

Phase 8. Initial load validation. We check for errors and verify data volumes. Phase 9. Cutover. We update MX records and other necessary configurations. Phase 10. Final synchronization. If the IMAP method is still active, we allow it to process any pending changes before shutting it down. Phase 11. Functional validation. We review email and other included items. Phase 12. Decommissioning the source. Only after confirming that no dependencies remain.

How to select users for the pilot

A pilot should not consist solely of the simplest mailbox.

What the pilot should provide us. Speed, errors, actual size, folder behavior, duplicates, and necessary manual tasks.

Cutover: moving production to Exchange Online

The cutover must be documented.

Do not cancel the hosting service that same night. It is advisable to keep it active for a controlled period until the following are confirmed: New email, historical data, applications, and any potential exceptions.

How to validate the migration

A POP migration requires more validation than simply checking the status of a job. Identity validation.

Mail flow validation.

Validation of historical data. Verify via sampling: Old messages, recent messages, Inbox, Sent items, subfolders, and attachments. PST validation. Review: Mapping, volume, skipped items, corrupted items, and destination (Primary/Archive). Contacts and calendars. Validate only if they were within the scope. DNS. Check: MX, SPF, DKIM, and DMARC. Applications. Confirm: ERP, CRM, web, scanners, and alert systems are included.

What changes for the user when moving from POP3 to Exchange Online

The change is more significant than it appears.

Not all training needs to take place on the first day. It is essential that the user knows: how to log in, where their email is located, where to find their historical data, and how to request internal assistance if they encounter any outstanding or missing information.

How long does a POP3 to Microsoft 365 migration take?

It cannot be calculated based solely on the number of mailboxes.

A company with 10 users can be complex. Ten users with: two computers each, five PST files per person, and ten years of historical data may require more work than 50 clean IMAP mailboxes that are fully stored on a server.

What determines the cost of a POP3 migration?

The most significant difference: IMAP vs. true POP

If the entire history can be retrieved via IMAP, the project is usually much more predictable. If we need to search for information on local computers and within PST files, the workload increases because the data is decentralized.

Common mistakes when migrating from POP3 to Microsoft 365

Checklist before migrating from POP3 to Microsoft 365

Frequently asked questions about migrating from POP3 to Microsoft 365

Can all historical email be migrated directly from POP3?

It should not be assumed that the server contains everything the user accesses. Download settings may have resulted in messages being stored only on one or more individual devices. Before defining the migration method, the server, email profiles, and local files must be reviewed to identify the sources that encompass the required historical data.

Does a PST file automatically include everything that needs to be migrated?

This is a source that requires review: it may contain only specific time periods, folders, or items from an account. Its content must be verified—ensuring it can be opened—and its relationship to other copies must be assessed. This review makes it possible to determine what should be imported, helping to prevent both the loss of historical data and unnecessary duplication.

How can duplicates be avoided when consolidating multiple sources?

The information contained in each source is documented, and a strategy is defined prior to the import. If there are overlapping copies, the chosen method is tested to see how it handles them, and a sample is validated in the destination environment. It is not advisable to assume that all duplicates will be resolved automatically, nor should files be merged without knowing their origin.

What should be provided to the user after the migration?

You must know which profile to use, where to locate the historical data, and how to ensure that new messages are saved correctly moving forward. The process also covers any remaining discrepancies and the handling of the original source files. Final sign-off includes testing the sending, receiving, and searching of emails, as well as the handling of attachments—along with verification that the user is no longer working within the previous environment.

Final recommendations: regarding POP3 Migration begins by locating the data, not by copying it.

A Migrating from POP3 to Microsoft 365 This may seem straightforward because POP3 is a basic protocol. In reality, that very simplicity can make the project more labor-intensive. Over the years, messages may have been downloaded to individual computers, deleted from the server, scattered across various PST files, or stored alongside sent items, contacts, and calendar entries that never existed on the original hosting platform.

Therefore, the first step should not be configuring a migration tool. Instead, you must determine: what is still stored on the server, what each user has in their Outlook, which PST files exist, and what information the company actually needs to retain. If the provider retains historical data and supports IMAP, Microsoft offers a native migration path to Exchange Online. This allows for the transfer of messages and folders, supports incremental synchronization, and enables a large portion of the data to be moved before the MX record is updated.

However, there are limitations to be aware of: it does not migrate contacts, calendars, or tasks; there is a documented maximum number of items per mailbox; and messages exceeding the supported size limit require a different approach. When email resides locally, PST files become the primary source. For enterprise-level projects, Microsoft Purview allows you to upload PST files using AzCopy and map them to specific mailboxes. This process provides reporting, filtering, and a centralized way to manage multiple files—though factors such as PST file size and ingestion speed must be accounted for during the planning phase.

When IMAP and PST files contain overlapping time periods, you must explicitly plan which information should be drawn from each source. Do not assume that any combination of tools will automatically remove all duplicates. Then comes the cutover. The domain must be prepared in Microsoft 365, mailboxes must be created and licensed, and Exchange Online must be validated before updating the MX records. SPF must be maintained as a single, correctly constructed record; DKIM must be configured for the new service; and DMARC should be implemented in a controlled manner after verifying all legitimate sending sources.

You should also create an inventory of ERP systems, CRM platforms, web forms, scanners, and any other applications that use email. These are easily overlooked and can become the primary source of issues following an otherwise successful transition. The migration is complete when new email is correctly flowing in and out of Exchange Online, the agreed-upon historical data is accessible, any relevant local data has been migrated, all applications are functioning, and the previous provider can be decommissioned without relying on any information that might still reside solely within that legacy system..

Recommended official documentation

IMAP migration.

• Microsoft – What you need to know about migrating IMAP mailboxes
• Microsoft – Migrate other types of IMAP mailboxes
• Microsoft – Perform an IMAP migration with PowerShell
• Microsoft – Manage migration batches in Exchange Online

PST import.

• Microsoft – Learn about importing PST files
• Microsoft – Network Upload for PST files
• Microsoft – PST Import FAQ
• Microsoft – Troubleshoot PST Import

Outlook and PST.

• Microsoft – Import email, contacts, and calendar from a PST file
• Microsoft – Open and search for items in a PST file

Exchange Online.

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

Domain and DNS.

• Microsoft – Connect your domain by adding DNS records
• Microsoft – External DNS records for Microsoft 365

SPF, DKIM and DMARC.

• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC