# <div style="text-align: center">What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365 </div>
References:
- [Microsoft 365 Docs](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes)
- [Tips for optimizing IMAP migrations](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/optimizing-imap-migrations)

#### I. Thinks to consider
Here are a few limitations to be aware of:
<ul>
<li>You can only migrate items in a user's inbox or other mail folders</li>
<li>You can migrate a maximum of 500,000 items from an user's mailbox (emails are migrated from newest to oldest).</li>
<li>The biggest email you can migrate is 35MB</li>
<li>If you limited the connections to your source email system, it's a good idea to incease them to improve migration performance. Common connection limits include client/server total connections, per-user connections, and IP address connections on either the server or the firewall.</li>
</ul>

#### II. Impact of migration to users
To migrate email, you need access to user mailboxes in your source email system. If you know the user passwords or can access their mailboxes by using administrator credentials, there won't be any impact to users until you shut down your source email system.

If you can't access user mailboxes, you'll have to reset the passwords. This lets you access the user mailboxes by using a new password that you know. If users don't know the new passwords, they won't be able to get to their old mailboxes during or after the email migration. You can distribute the new passwords after the migration if you want users to get to their old mailboxes.

#### III. These general steps apply whether you are migrating from Gmail or another IMAP system
<ol>
<li>First you have to create your users in Microsoft 365 or Office 365 and assign licenses to them. The mailboxes have to exist in Microsoft 365 or Office 365 to use IMAP migration.</li>
<li>Prepare your IMAP source email system and get the information you need to migrate. If you plan to migrate your domain to Microsoft 365 or Office 365, verify that you own your domain with your domain registrar.

Depending on which type of email service you are migrating from, you might need to configure some settings or simply record the name of your email server or service to use later. You also need to verify your domain in your domain registry system if you have a custom domain.</li>
<li>Communicate changes to users.

It's a good idea to let users know about the email migration and how it impacts them. Give users information about what tasks need to be done before, during, and after migration.</li>
<li>Set up admin credentials or get or reset user email passwords.

To perform the migration, you need an administrator account that has permissions, or the username and password to each mailbox.</li>
<li>If you are using the steps described in [Migrate Google Apps mailboxes to Microsoft 365 or Office 365](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrate-g-suite-mailboxes) or [Migrate other types of IMAP mailboxes to Microsoft 365 or Office 365](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrate-g-suite-mailboxes), you will create a list of mailboxes to migrate (CSV file). These migrations instructions start from the Exchange admin center, and you will need to create a CSV file that lists the email addresses, usernames, and passwords for the mailboxes you want to migrate.

You can also use the migrations page or setup instructions in the [Admin center preview to migrate from IMAP](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/imap-migration-in-the-admin-center) systems such as Gmail, Hotmail or Outlook. These steps are the best if you plan to migrate mail for only a few users (less than 50). If you are migrating mail for more users it is easier to use a CSV file to enter all the information for the accounts.</li>
<li>Connect Microsoft 365 or Office 365 to the source email system.

To migrate email successfully, Microsoft 365 or Office 365 needs to connect and communicate with the source email system. To do this, Microsoft 365 or Office 365 uses a migration endpoint, the settings that are used to create the connection.</li>
<li>Migrate mailboxes and then verify the migration.

To migrate mailboxes, you create a migration batch, and then start the migration. After the migration batch is run, verify that the email was migrated successfully.</li>
<li>Optimize email settings (optional).

There are some settings you can configure so that it doesn't take as long for email to start showing up in your new Microsoft 365 or Office 365 mailboxes. See [Tips for optimizing IMAP migrations](https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/optimizing-imap-migrations).</li>
<li>Begin routing email to Microsoft 365 or Office 365.

You need to change a DNS record called an MX record so that your email system can start routing mail to Office 365.
</li>
<li>Verify routing and then stop email synchronization.

After you verify that all email is being routed to Microsoft 365 or Office 365, you can delete the migration batch to stop the synchronization between your source email system and Microsoft 365 or Office 365.</li>
<li>Send a welcome letter to users.

Let your users know about Microsoft 365 or Office 365 and how to sign in to their new mailboxes.</li>
</ol>

#### IV. Ready to start?
To finish an email migration successfully, it's a good idea to be comfortable doing these tanks:
<ul>
<li>You create a list of mailboxes to migrate in Excel. You add your users' email addresses, usernames, and passwords to this file.</li>
<li>You use step-by-step wizards in Microsoft 365 or Office 365 to configure and start the migration process.</li>
<li>After the mail has been migrated, you change your organization's MX record to point to Microsoft 365 or Office 365 when the migration is complete. Your MX record is how other mail systems find the location of your email system. Changing your MX record allows other mail systems to begin to send email directly to the new mailboxes in Microsoft 365 or Office 365. To learn how to update your MX record, see Create DNS records at any DNS hosting providersee as well.</li>
</ul>

#### V. Tips for optimizing IMAP migrations
Here are some tips for optimizing an IMAP migration:
<ol>
<li><strong>Increase the connection limits to your IMAP server:</strong> Many firewalls and email servers have per-user limits, per-IP address limits, and overall connection limits. Before you migrate mailboxes, make sure that your firewall and IMAP server are configured to allow a large, or maximum, number of connections for the following settings:</li>
<ul>
<li>The total number of connections to the IMAP server.</li>
<li>The number of connections by a particular user. This is important if you use an administrator account in the comma-separated value (CSV) migration file because all connections to the IMAP server are made by this user account.</li>
<li>The number of connections from a single IP address. This limit is typically enforced by the firewall or the email server.

If your IMAP server is running Microsoft Exchange Server 2010 or Exchange 2007, the default settings for connection limits are low. Be sure to increase these limits before you migrate email. By default, Exchange 2003 doesn't limit the number of connections.</li>
</ul>
<li><strong>Change the DNS Time-to-Live (TTL) setting on your MX record:</strong> Before you start migrating mailboxes, change the Domain Name System (DNS) TTL setting on your current MX record to a shorter interval, such as 3,600 seconds (one hour). Then, when you change the MX record to point to your Microsoft 365 or Office 365 email organization after all mailboxes are migrated, the updated MX record should propagate more quickly because of the shortened TTL interval.</li>
<li><strong>Run one or more test migration batches:</strong> Run a few small IMAP migration batches before you migrate larger numbers of users. In a test migration, you can do the following:</li>
<ul>
<li>Verify the format of the CSV file.</li>
<li>Test the migration endpoint used to connect to the IMAP server.</li>
<li>Verify that you can successfully migrate email by using administrator credentials, if applicable.</li>
<li>Determine the optimal number of simultaneous connections to the IMAP server that minimize the impact on your internet bandwidth.</li>
<li>Verify that folders you exclude aren't migrated to Microsoft 365 or Office 365 mailboxes.</li>
<li>Determine how long it takes to migrate a batch of users.</li>
<li>Use CSV files with the same number of rows and run the batches at similar times during the day. Then compare the total running time for each test batch. This comparison will help you estimate how long it will take to migrate all your mailboxes, how large each migration batch should be, and how many simultaneous connections to the IMAP server you should use to balance migration speed and internet bandwidth.</li>
</ul>
<li><strong>Use administrator credentials in the CSV file to migrate email:</strong> This method is the least disruptive and inconvenient for users, and it will help minimize synchronization errors caused when users change the password on their on-premises account. It also saves you from having to obtain or change user passwords. If you use this method, be sure to verify that the administrator account you use has the necessary permissions to access the mailboxes you're migrating.</li>
<ul>
<li><strong>NOTE</strong> If you decide to use user credentials in the CSV file, consider globally changing users' passwords, and then preventing users from changing their password on their on-premises account before you migrate their mailboxes. If users change their password before their mailbox is migrated to the cloud-based mailbox, the migration will fail. If they change their password after the mailbox is migrated, new email sent to their mailbox on the IMAP server won't be migrated to their Microsoft 365 or Office 365 mailbox.</li>
</ul>
<li><strong>Don't delete mailboxes or change their SMTP addresses during migration:</strong> The migration system will report an error when it can't find a mailbox that's been migrated. Be sure to complete the migration and delete the migration batch before you delete or change the SMTP address of a Microsoft 365, Office 365, or on-premises mailbox that's been migrated.</li>
<li><strong>Communicate with your users:</strong> Let users know ahead of time that you'll be migrating the content of their on-premises mailboxes to your Microsoft 365 or Office 365 organization. Consider the following:</li>
<ul>
<li>Tell users that email messages larger than 35 MB won't be migrated. Ask users to save very large messages and attachments to their local computer or to a removable USB drive.</li>
<li>Ask users to delete old or unnecessary email messages from their on-premises mailboxes before migration. This helps reduce the amount of data that has to be migrated and can help reduce the overall migration time. Or you can clean up their mailboxes yourself.</li>
<li>Suggest that users back up their Inboxes.</li>
<li>Tell users which folders won't be migrated, if applicable.</li>
<li>Folders with a forward slash ( / ) in the folder name aren't migrated. If users want to migrate folders that contain forward slashes in their names, they have to rename the folders or replace the forward slashes with a different character, such as an underscore character ( _ ) or a dash ( - ).</li>
</ul>
</ol>