With the popularity of Office 365 constantly growing, there are few administrators who did not at least consider moving from their on-premises Exchange Server to Microsoft’s Cloud. As moving mailboxes is never an easy task, there are quite a few consequences which you have to take into consideration before jumping into the new environment. If you want to minimize or avoid problems during the process, you need to plan your migration carefully. This article presents types of Exchange to Office migrations and gives you a sample migration checklist you can later refer to.
First of all, you have to remember that Office 365 has some storage limits which have to be taken into consideration. All mailboxes types, including public folders and shared mailboxes, can store up to 50 GB of data. If in your organizations there are public folders or mailboxes which exceed this size, you might want to archive some content.
Secondly, moving to Office 365 requires the source and target environment to be thoroughly prepared before the migration proper can be started.
There is a number of native options available for those who wish to move from their on-premises Exchange to the Online version:
*Does not apply to Exchange 2007 and older versions.
Cutover Migration from Exchange to Office 365
In this scenario, mailboxes are moved based on a “cut and paste” model and transitioned without changes into the cloud.
A cutover migration is a process which must be completed in one go. Microsoft emphasizes that, although this method enables to migrate up to 2000 mailboxes, it is recommended not to exceed 150. This way, admins can ensure better stability and reduce the risk of many undesired errors.
Step-by-step cutover migration guide:
This checklist shows how to perform a cutover migration. However, it can be used in a Staged Migration scenario if you modify it slightly. You can see the differences in the Staged Migration section.
- Update your source system and download all service packs.
- Enable Outlook Anywhere, to allow for remote connection to the on-premises Exchange Server when the proper migration starts.
- Make sure that the administrator’s account you will use for migrating has full access to all mailboxes. You can see how to do it in this article.
- Add an SSL certificate with Outlook Anywhere and Autodiscover services included.
- Optional: Test if you can connect to your Exchange organization using Outlook Anywhere. You can find instructions on how to do that in Test and Verify Autodiscover on Docs.
- Disable Unified Messaging before the migration and turn it on only after the migration is complete.
- Create Security Groups on Office 365: If you want to migrate security groups, you have to remember that email migration service can migrate them only if you create them before the migration
- Create Migration Endpoint – A Migration Endpoint is a container for settings and users’ credentials. The data included in it is necessary to access both the source and the target server; it stores settings defining the maximum number of mailboxes to be migrated simultaneously, and a maximum number of concurrent incremental syncs. Note that a single Endpoint can handle up to 100 concurrent mailbox migrations, including syncs.
- Create the migration batch, containing every single mailbox which is going to be transferred, and choose whether to start the batch instantaneously, or manually later.
- After the data transfer is finished and the TTL (Time-to-live) passes, the DNS MX record needs to be changed, so that mail is now routed to Office 365 mailboxes (the time for this change to apply varies; it may take up to 24-48 hours)
- Ensure that data in the migration batch has been synced at least once since emails began to be routed directly to Exchange Online mailboxes. When ready, delete the migration batch.
- Last but not least, licenses must be assigned to the migrated accounts. To prevent users’ accounts from being disabled, it has to be done within 30 days.
As for post-migration tasks, an Autodiscover record has to be created in DNS. It is necessary for users to connect easily to respective Office 365 mailboxes. More on creating DNS records in Office 365 here.
At this stage, it might be a good idea to verify if the Autodiscover service is working. To learn how to do it quickly, check this article.
For more information on the cutover migration process, consult this Microsoft Docs article.
Staged Migration from Exchange to Office 365
Available for legacy Exchange Server versions, e.g. 2007. Although it enables directory synchronization and moving batches gradually over time, it is not recommended to keep the long-term connection between the source and the target server.
This type of migration is similar to the cutover method, except that in a staged migration, mailboxes are moved in multiple batches.
The single batch limit is the same as in the previous migration scenario: 2000 (but it is recommended to limit batches to 150 users). This option is meant for those who have more than 150 mailboxes to move.
The process itself is also very similar to the one above, except for these additional steps:
It requires directory synchronization, which can be achieved using Microsoft Azure Active Directory Connect (available for download on this Microsoft site)
A list of mailboxes needs to be prepared in a CSV file. It can be easily created using the export option in Exchange Control Panel, after applying filters, so that only users’ SMTP email addresses are listed. The file also needs to include a password for the new Office 365 account and True or False value, depending on whether users should have to change their passwords on the first login, or not. Headers for the CSV file (located in the first line of the document) should look like this.
Each consecutive row represents one user.
- The CSV file comes in handy while creating migration batches, as lists included in those files can be easily imported.
- After migrating each batch, it is crucial to convert on-premises mailboxes to mail-enabled users. This way, the migrated part of your company is redirected to Office 365 mailbox and can access emails sent to them.
- Batches can be run one by one, or concurrently. All mailboxes need to be migrated before decommissioning the source Exchange Server.
For more information on the staged migration process, consult this Microsoft Docs article.
This is an option available for Exchange 2010/2013/2016. It provides a mixed environment, in which a central management of both Office 365 and on-premises Exchange users is possible. Hybrid migration requires Active Directory synchronization between source and the target server, which allows mailboxes to be recreated in the cloud, along with users’ credentials.
It serves as either an intermediate step for those who wish to move completely into the cloud, or as a custom environment, for administrators who don’t want to lose the configuration options that on-premises Exchange offers, but at the same time want to reduce the local structure (except for the last hybrid deployment option).
Hybrid deployment is done natively with the help of Hybrid Configuration Wizard. This Microsoft’s tool enables administrators to perform three different types of hybrid deployment:
This is the most complex option to configure. It can either act as a custom environment for those who do not wish to move the entire organization to the cloud, or as a fully functional environment for larger companies who will take a lot of time to migrate. It is the only hybrid type which offers advanced features like:
- Free/Busy and calendar sharing between on-premises Exchange and Exchange online
- Mailbox management through on-premises Exchange Admin Center
- Unified global address list throughout the whole organization
This hybrid option is analogical to staged migration available for legacy Exchange Server versions. It lacks the advanced functionalities of a full hybrid but requires less configuration. According to Microsoft, this option is dedicated to small and medium organizations who wish to change platforms seamlessly as quickly as possible.
Minimal Hybrid can be changed into Full Hybrid through the Hybrid Configuration Wizard. Doing so will require performing additional configuration steps and will unlock all benefits restricted to the first Hybrid type.
Express Migration from Exchange to Office 365
This most recently added option is a subtype of the minimal hybrid and is a fresh alternative to a cutover migration. Instead of keeping the synchronization throughout the migration process, it gives an option to perform a one-time synchronization. During this synchronization, mailboxes are recreated in the cloud, along with users’ credentials and Outlook profiles. It is a definite advantage over the cutover migration, in which the process lacks automatization.
It is worth noticing, that express migration enables mail flow to continue throughout the whole migration process. What is more, according to Microsoft, there is no downtime for users. Although the one-time synchronization is not supposed to be repeated and Hybrid Configuration Wizard does not allow this, it can be achieved manually with AAD Sync.
Although the express migration is highly simplified and is recommended as the quickest way to shift to the cloud for small and medium organizations, there are some limitations and drawbacks:
- Only one migration endpoint is supported.
- The migration is performed one batch at a time.
- Users in Office 365 have to be licensed prior to the migration.
- By default, if there are new users created during the migration process, or a user changes password manually, those elements are not synced with the Exchange Online. That can cause some unexpected problems.
Those limitations make express migration an option for small companies only, as migrating a larger company by one endpoint and in one batch only would take too much time.
For more information on the hybrid deployment process, consult this Microsoft Docs article.
Office 365 Import Service
The last natively available option for on-premises Exchange mailbox data migration is exporting items from the source server to PST format and then uploading it to the target server, using the in-built Office 365 Import Service.
Note that in the case of databases of 10 TB and more, Microsoft advises shipping hard drives containing PST files to them instead of importing over the network, as the process will be quicker this way.
The bottom line is, PST files export is limited to 10 GB of data per file. However, many users report problems and errors during migration of large PST files.
Native limitations of Exchange to Office 365 migration
Although all native options for Exchange to Office 365 migration differ from each other, there are some limitations they share:
- Microsoft recommends using PowerShell scripts on most migration steps creating a barrier for those who are not PowerShell experts and making the transition far from being automatic.
- No filtering: native solutions do not offer an option to choose data which is to be copied – everything is migrated without exceptions.
- No scheduling: migration requires a lot of effort from the administrator, all processes have to be started manually.
- Downtime: in the cutover scenario, service downtime is unavoidable.
Luckily, there are solutions which enable administrators to overcome Exchange limitations. CodeTwo Office 365 Migration offers functions like:
- Pre-configuration wizard, along with step by step walkthrough and checklist: Which makes it easy to configure and keep track of what still has to be done before the actual migration.
- Choosing item types: migrating only the most recent objects or only selected types of folders is finally possible.
- Handy scheduler enables you to plan ahead and automatize the process so that the migration only occurs during set time ranges.
- No downtime: All data is copied and saved on the target server; no files are modified, cut, or deleted.
- Delta scanning: Before the final move, it is possible to scan the source mailbox and migrate only those objects which were added during the migration process.
For more information on the product, visit Test and Verify Autodiscover.