IMAP to Microsoft 365: Small Business Migration Checklist

Moving business email from an IMAP server to Microsoft 365 is not only a mailbox-copying task. A reliable plan must identify what the IMAP migration can move, what needs separate handling, how users will sign in after the change, when mail flow will switch, and how the result will be checked.

For small businesses, the most important early decision is scope. Email messages stored on the IMAP server are one workstream. Calendars, contacts, local archives, business files, permissions, devices, applications, and security settings are separate workstreams that may require different tools and preparation.

This checklist explains the questions to answer before an IMAP-to-Microsoft 365 migration and complements ZeroShield IT's Microsoft 365 and Exchange Online service.

What Does an IMAP Migration Move?

IMAP is an email-access protocol. Microsoft's documented IMAP migration process copies supported email data from source mailboxes into target Exchange Online mailboxes. It does not, by itself, provide a complete transfer of every item associated with a user's account.

Treat the following areas separately during planning:

• Email messages and folders: These are the main data handled by an IMAP migration. Folder mapping, source-server behavior, credentials, message size, and other source limitations can affect what is copied.
• Calendars: Calendar data is not included in a standard IMAP email migration and needs a separate export, import, synchronization, or recreation plan where required.
• Contacts: Address-book and contact data also needs separate handling.
• Tasks, notes, and other client data: These may exist only in the old mail application or in a format outside the source IMAP mailbox.
• Local archives: PST files, local mail folders, exported archives, and messages stored only on a workstation may not exist on the IMAP server. They must be discovered and assessed separately.
• Files: Moving email does not move shared folders, desktop documents, or file-server data into OneDrive or SharePoint.
• Permissions and delegation: Shared-mailbox access, send-as permissions, folder delegation, aliases, and distribution requirements need to be documented and configured in the target environment.
• Security configuration: MFA, administrator roles, anti-spam settings, domain authentication, sign-in policies, and account-recovery arrangements are tenant-configuration tasks, not mailbox content.

A migration plan should therefore avoid the vague requirement “move everything.” It should list each data type, where it currently resides, whether it is required, and how it will be handled.

1. Inventory the Existing Email Environment

Start by documenting the source environment before creating migration batches or changing DNS.

Record:

• each active mailbox and its primary email address;
• aliases and forwarding rules;
• shared or generic addresses such as accounts@, sales@, or support@;
• mailbox sizes and any unusually large folders;
• the source IMAP server name, port, encryption requirements, and authentication method;
• who controls the business domain and public DNS;
• applications, scanners, websites, or devices that send email;
• users' desktop and mobile email applications;
• local PST files, local-only folders, calendars, and contacts;
• users who have access to another person's mailbox or folders;
• mail-retention or archive requirements that need separate review.

Also identify accounts that should not be migrated, such as former-user mailboxes that must be retained under a separate business decision or obsolete accounts that should be closed after their data has been reviewed.

2. Define the Migration Scope in Writing

For each user or mailbox, state what is included and what is outside the IMAP migration itself.

A practical scope table can include:

This prevents an email migration from being mistaken for a complete Microsoft 365 transformation.

3. Confirm Tenant, Domain, and Licensing Requirements

Before migration, confirm which Microsoft 365 tenant will own the users and domain. Domain ownership must be verified in Microsoft 365, and every user receiving an Exchange Online mailbox needs an appropriate subscription that includes that service.

Licensing should be reviewed against the required features rather than chosen only by product name. Desktop Office applications, Conditional Access, archiving, retention, compliance, and advanced security capabilities are not identical across all Microsoft 365 and Exchange Online plans.

The plan should confirm:

• the target tenant;
• the custom domain or domains being used;
• who has authority to update DNS;
• the required users and mailbox types;
• which subscription will be assigned to each licensed user;
• whether desktop Office application rights are required;
• whether security or compliance requirements depend on a particular license;
• who will manage subscriptions and future user changes.

Do not assume that buying a Microsoft 365 subscription automatically configures the tenant, migrates data, or applies every available security feature.

4. Prepare Accounts and Target Mailboxes

Microsoft's IMAP migration workflow requires the target users and mailboxes to exist before their source mailboxes are migrated.

Preparation normally includes:

• creating or synchronizing the required user identities;
• assigning the approved licenses;
• creating target mailboxes;
• confirming primary addresses and aliases;
• documenting shared-mailbox and delegation requirements;
• deciding how initial passwords or temporary access will be communicated;
• confirming administrator and emergency-access arrangements;
• verifying the business domain without switching production mail flow too early.

Users should not receive uncoordinated sign-in instructions before the tenant, account, licensing, and cutover plan are ready.

5. Check Source Access and Migration Dependencies

An IMAP migration depends on Microsoft 365 being able to connect to the source server and authenticate to the selected mailboxes.

Before scheduling the main migration, confirm:

• the source server accepts the required encrypted IMAP connection;
• the necessary credentials or approved administrative access are available;
• source-side security controls will not unexpectedly block the migration connection;
• mailbox mappings are correct;
• the source service will remain available during the required synchronization period;
• source throttling, bandwidth, or provider restrictions have been considered;
• unsupported or failed items will be reviewed rather than assumed to have transferred.

Credentials used for migration should be handled through an agreed secure process. They should not be sent through ordinary contact forms or stored in the planning document.

6. Run a Pilot Before the Main Migration

A pilot helps test assumptions before the wider cutover. It does not guarantee that every mailbox will behave identically, but it can reveal problems with source connectivity, credentials, folders, message formats, permissions, or user instructions.

Choose a pilot mailbox that is representative of the environment without exposing unnecessary business risk. Depending on the business, useful pilot characteristics may include:

• several folders;
• older and recent messages;
• attachments;
• typical mailbox size;
• use on the same desktop or mobile applications as other staff;
• known calendar, contact, or local-archive requirements that need separate validation.

During the pilot, check:

• whether the migration endpoint connects successfully;
• whether expected email folders and sampled messages appear;
• whether recent and older messages can be opened;
• whether attachments in the sample can be accessed;
• whether the user can sign in through the intended method;
• whether desktop and mobile setup instructions are accurate;
• which items remain outside the IMAP migration;
• how long the tested work takes under the observed conditions, without treating that result as a universal promise.

Record pilot findings and update the checklist before starting the wider migration.

7. Plan DNS and Mail-Flow Cutover

The MX record tells external mail systems where to deliver new messages for the domain. Changing the MX record is therefore a mail-flow cutover, not a cosmetic DNS update.

Before the change:

• verify the Microsoft 365 domain;
• create the required target users and mailboxes;
• record the current DNS values;
• identify all required Microsoft 365 DNS records;
• confirm access to the authoritative DNS provider;
• review the existing MX time-to-live value and plan changes early enough to be useful;
• choose a cutover window with appropriate business communication and support availability;
• keep the source service active for the agreed synchronization and validation period.

DNS changes do not become visible everywhere at exactly the same time. Some senders may temporarily use cached routing information. The plan should account for this possibility and avoid promising an interruption-free or instantaneous switch.

8. Prepare Users for the Change

User communication should arrive before the cutover and explain only what users need to do.

Include:

• the planned date and expected window;
• whether users should continue using the old system until instructed;
• the new sign-in address;
• how initial credentials or temporary access will be delivered securely;
• how and when MFA registration will occur;
• which desktop and mobile applications are supported;
• what users should check after signing in;
• how to report a missing folder, message, permission, or device issue;
• where calendars, contacts, and local archives fit into the plan;
• who users should contact during normal support hours.

Avoid sending passwords, MFA codes, or recovery secrets in bulk email instructions.

9. Configure Identity and Security Deliberately

Microsoft 365 security configuration is related to the migration but is not performed by IMAP itself.

The target design should consider:

• MFA registration and enforcement approach;
• administrator-role assignments and separation of daily and privileged access where appropriate;
• emergency-access arrangements;
• disabling or blocking obsolete accounts;
• mailbox delegation and shared access;
• anti-spam and anti-malware settings available under the selected plan;
• SPF, DKIM, and DMARC planning for the business domain and legitimate third-party senders;
• suspicious sign-in and account-compromise procedures;
• whether Conditional Access is required and licensed;
• user guidance for reporting phishing or unexpected MFA prompts.

Microsoft documents security defaults as available to Microsoft 365 organizations, while Conditional Access requires appropriate Microsoft Entra licensing. The final configuration should therefore be based on the tenant's licenses and requirements rather than assuming every control is available under every plan.

Email-authentication planning should inventory every legitimate system that sends as the business domain, including Microsoft 365 and applicable websites, scanners, accounting systems, CRM platforms, or mailing services. SPF must account for valid sending sources, DKIM should use the exact values supplied for the tenant and domain, and DMARC should be introduced and monitored without inadvertently blocking legitimate senders that have not yet been aligned. Required records vary by domain, tenant, DNS provider, and third-party service, so example DNS values should not be copied as universal settings.

10. Execute and Validate the Cutover

At the agreed stage of the migration:

1. Review the migration-batch status and investigate reported errors.
2. Confirm the required target mailboxes are ready.
3. Apply the planned DNS and mail-flow changes.
4. Verify inbound and outbound delivery using controlled tests.
5. Confirm internal and external messages reach the intended mailboxes.
6. Check aliases, shared addresses, and required permissions.
7. Confirm users can sign in and complete MFA registration where configured.
8. Reconfigure agreed desktop and mobile applications.
9. Continue the planned source synchronization and monitoring period.
10. Record unresolved items instead of declaring the migration complete prematurely.

Validation should sample both new mail flow and migrated historical content. A “completed” batch status is useful evidence, but business validation is still required.

In Microsoft's documented IMAP migration-batch workflow, Microsoft advises waiting at least 72 hours after changing the MX record before stopping synchronization. Before deleting the migration batch, verify that new mail is routing to Microsoft 365, users are working from the target mailboxes, and the source and target have completed the expected synchronization. Deleting the batch stops further synchronization. This 72-hour guidance applies to Microsoft's documented IMAP migration-batch workflow; it is not a guaranteed total migration duration or a universal rule for every migration tool.

11. Perform Post-Migration Checks

After cutover, verify the environment from both administrator and user perspectives.

Mail and access

• Send and receive internal and external test messages.
• Check sampled migrated folders, messages, dates, and attachments.
• Confirm aliases and shared-address behavior.
• Test delegated access where it was part of the approved scope.
• Confirm required desktop and mobile applications reconnect correctly.

Data outside IMAP

• Complete agreed calendar and contact imports.
• Review local PST files or local-only folders identified during discovery.
• Confirm whether any old archives remain intentionally outside Microsoft 365.
• Validate separately migrated OneDrive or SharePoint files and permissions.

Identity and security

• Confirm MFA registration for the intended users.
• Review administrator roles and recovery arrangements.
• Confirm leavers and obsolete accounts are handled as agreed.
• Check the applicable mail-protection and domain-authentication settings.
• Document how suspicious sign-ins and user-reported security events will be handled.

Operations

• Keep a record of failed or excluded items.
• Confirm ownership for future user, license, mailbox, and permission changes.
• Document the source-system retirement decision and timing.
• Do not close the source service until the agreed synchronization, validation, and retention checks are complete.

Completing the migration does not decide how long business email must be retained, which recovery scenarios must be supported, or whether the tenant's configured retention and recovery options meet the business's backup requirements. Exchange retention policies and Microsoft 365 Backup are separate configurations that should be reviewed against licensing, legal and business retention needs, and agreed recovery objectives.

A Real Microsoft 365 Migration Example

ZeroShield IT has published an anonymized Microsoft 365 migration for a shipping agency. The business moved from a legacy IMAP email environment to Microsoft 365.

The documented project included mailbox migration, OneDrive configuration and permissions, Microsoft Entra ID, MFA, Exchange security policies, and monitoring. The case study demonstrates why mailbox data, file permissions, identity, and security should be treated as connected but distinct parts of the project.

Microsoft 365 and Azure Are Different

This checklist covers Microsoft 365 email, identity, and collaboration services. Moving servers, virtual machines, databases, applications, or virtual networks is an Azure infrastructure project with a separate scope, even when a business uses both platforms.

Final Planning Checklist

Before approving cutover, confirm that the business has:

• an inventory of users, addresses, aliases, shared mailboxes, and source dependencies;
• a written definition of what IMAP will and will not migrate;
• a separate decision for calendars, contacts, local archives, files, and permissions;
• an approved tenant and licensing plan;
• prepared target users and mailboxes;
• verified source access and migration connectivity;
• completed and reviewed a representative pilot;
• documented DNS values and cutover steps;
• sent clear user instructions;
• planned MFA and applicable security configuration;
• defined migration and mail-flow validation checks;
• assigned ownership for post-migration issues and source-system retirement.

Further Reading

• Microsoft's IMAP migration workflow and synchronization guidance
• Add a custom domain to Microsoft 365
• Email authentication in Microsoft 365: SPF, DKIM, and DMARC
• Exchange retention policies and Microsoft 365 Backup overview

Discuss Your Microsoft 365 Migration

If your business is planning a move from an IMAP email service, contact ZeroShield IT to discuss the source environment, data scope, users, licensing requirements, and cutover considerations.