Welcome to Options for Migrating from Third-Party Messaging Systems. In this lesson, we’ll touch on the migration options that are available for organizations that use mail systems other than Microsoft Exchange. The three options I want to touch on in this lesson include IMAP Migrations, PST File Migrations, and Third-Party Options.

Let’s start with IMAP Migrations. If you are migrating to Exchange Online from an email system that relies on the Internet Mail Access Protocol, or IMAP email service, you can use an IMAP migration to migrate the contents of your user mailboxes to Microsoft 365. Examples of these types of email systems include services like Gmail and Yahoo Mail. Now, I should mention that IMAP migrations aren’t limited to only migrating from IMAP-enabled email services. As a matter of fact, you can, if you are so inclined, use IMAP migration to migrate from on-prem Exchange servers. To add onto that, if you run Exchange 2003 or older in your on-prem environment, an IMAP migration is your ONLY option.

IMAP migrations can be run from the Exchange admin center or via Exchange Online PowerShell. In either case, you need prepare for an IMAP migration by adding your users into Microsoft 365 and creating mailboxes for them in Exchange Online. This is because there must be a target mailbox setup for each user you plan to migrate. To perform the migration, you’ll need to create a CSV file of the user mailboxes that will be migrated – in much the same way you do so for a staged migration. We talked about that earlier.

It’s important to note that there are some significant caveats to consider when thinking about performing an IMAP migration. For example, an IMAP migration only copies email data to Microsoft 365. It doesn't migrate things like contacts, calendar items, or tasks – AND a maximum of 500,000 items can be migrated from a user’s mailbox when performing an IMAP migration. I should also point out that the largest email that can be migrated is 35 MB. This isn’t a problem for some orgs, but for others, it can be a significant issue.

You should also ensure that increase or remove any connection limits to the source email systems before performing an IMAP migration. For example, connection limits like client/server total connections, per-user connections, and IP address connections on either the server or the firewall are all pretty common connection limits that find their way into production environments. By removing these limitations or increasing them, you can speed up the IMAP migration.

As you might expect, in order to successfully migrate email, Microsoft 365 has to be able to connect to and communicate with your source email system. Microsoft uses a migration endpoint to accomplish this connection. This endpoint contains the settings that are used to create the connection. As I mentioned a few minutes ago, PST File Migration is another way to get from a 3rd-party email system to Exchange Online. 

To bulk-import PST files to Exchange Online mailboxes, you use the Import service in the Microsoft 365 compliance center. You can import PST files in two different ways. You can perform a network upload, or you can use drive shipping. When using the network upload method, you upload your source PST files over the network to a temporary Azure Storage location. Once your PST files are in Azure Storage, you can run the Microsoft 365 Import service to import that PST data into your Exchange Online mailboxes.

Drive shipping involves what it sounds like it involves. To use this method, you copy your source PST files to a BitLocker-encrypted hard drive, that you then physically ship to Microsoft. When they receive the drive, Microsoft uploads that data to a temporary Azure Storage location in the Microsoft cloud. Once you are notified that this data has been uploaded, you can then run the Microsoft 365 Import service to import the data into your Exchange Online mailboxes.

You might want to consider a PST migration if your organization has a large amount of mailbox data that you need to migrate to Microsoft 365. You might also want to think about a PST migration if your organization runs IMAP or POP3 servers and your users can export PST files. And then some organizations will use this migration method when they prefer not to overutilize their Internet connectivity during a migration.

Now lastly, I want to talk about third-party migrations. Consider this as a sort of catch-all for anything I haven’t yet mentioned.

If you are an organization with an existing email system that ISN’T something we’ve already talked about, you might want to think about a third-party migration solution. When I say third-party, I’m talking about a migration tool from a software vendor such as something like Skykick or BitTitan. These, of course, are just two examples, but there are many other tools and options available from other third parties. Such tools can be used to perform email migrations from platforms like IBM Lotus Notes and Novell GroupWise.

It’s important to note that if whatever third-party email system you are using only provides POP3 access to user mailboxes, the only migration option is to use a third-party migration tool or a PST migration.

So, to quickly recap. There are three key migration options that are available for organizations that use mail systems other than Microsoft Exchange. They include IMAP Migrations, PST File Migrations, and Third-Party Options like BitTitan and Skykick. Be sure to remember the differences between these options and when each can and should be used.