Migrations are never an easy task for the System Administrator and for the users can be a little unproductive depending on the hiccups during the process or if it’s not done right. There are a number of ways to migrate your current Exchange 2010 to Office 365 and we are going to explore the native tool by Microsoft called the Microsoft Exchange Server Deployment Assistant.
Exchange 2010 is still supported in this application and the Exchange Deployment Assistant is by far the commonly used migration process bearing in mind that it’s suggested if you have a single-forest, single-domain environment and not a complex Active Directory system with any child domains or any other configurations.
There are three ways to migrate Exchange 2010 to Office 365 depending on your setup and downtime needs which are:
This method is a quite simple concept of migration where you are setting up a synchronization between your Exchange Server and Office 365. Once everything is seeded you decide on a date which preferable being during a weekend and you flip a switch and everyone is happily on Office 365. Better said than done. Of course, there are a number of configurations to be done, one of which is a clean and perfectly running Outlook Anywhere.
First things first, your Exchange 2010 setup needs to be upgraded to at least Service Pack 3 which although is not required, it’s highly recommended.
Note: It’s important that before you do the cutover migration, directory synchronization and unified messaging are disabled.
As said, this migration is heavily dependent on a perfectly running Outlook Anywhere. In the later Exchange Servers it is enabled by default, but on Exchange 2010 if you haven’t configured it yet, you need it now. To setup Outlook Anywhere you need to install an SSL certificate (not self-signed) and the RPC over HTTP component on the server hosting Exchange. This can be setup in expanding the Server Configuration/ Client Access and right click on your server in the Client Access area in the middle section.
This can be either tested at a later stage from your Office 365 portal or you can use tools like https://testconnectivity.microsoft.com
The next stop is setting up the required permissions for the user you will be using to migrate which as common practice you create a new user for. For this migration your would need to five the ApplicationImpersonation, View-Only Configuration (On both Exchange Server and Office 365), View-Only Recipients and User Management Administrator on Office 365.
The impersonation can be performed via the Exchange Management Shell using the below command.
New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:<Your migration user>
The next step is to create a mail-enabled security group in Office 365 as this is required during the migration process as the service will not be able to provision any migrated groups as security groups in Office 365 as these don’t exist.
Now, you need to verify your domain in Office 365. This will not make anything live, just a confirmation of ownership by adding either an MX or TXT record; or now Microsoft have introduced a feature using email verification where an email is sent to the owner of the domain.
Once the domain is verified the next thing is to create a migration endpoint which basically contains all the information to connect your Exchange 2010 to Office 365. Here is mostly where the big headaches start as if you have any issues or incompatibilities in your Exchange Server, firewall or connectivity… this will surely not work as you wish.
After the endpoint is created, we would need to create and start a migration batch. This batch will include all mailboxes to be migrated. At this point is where the migration happens and the data is transferred. To make sure that everything is migrated you will need to assign an Office 365 license to a user, log into the user and verify the data is in the mailbox. After all the data has transferred, it is time to make the switchover.
Once this is done, you need to clean up after your migration and this is done by pointing the MX record to Office 365 along with the other CNames, TXT records and SRV records. Of course, you would need the modify your current setup to stop pointing your DNS autodiscover and SCP to your Exchange 2010 setup. You can now safely remove the batch and decommission your servers. This can be quite tricky to setup and it requires a lot of work and time to make sure that the migration goes smoothly.
Sometimes this method is a refined staged migration where it enables both on-premise and Office 365 to co-exist at the same time. Thou this is only available on Exchange 2010 onwards. This is highly recommended when you have large data to migration where it would take a considerate amount of time to transfer the data. The hybrid method is mostly recommended when having more than 150 mailboxes.
As said, this method is not an intermediate stage as you cannot keep both sides or use it as a failover. The Hybrid method is a final deployment and for this you need to configure a dedication Hybrid Configuration Wizard (HCW) which involves a federation trust between both Exchange and Office 365, organisation relationship, MRS proxy and connectors. Going through the guide to set it up, we would need to document the whole process in a separate post.
If you have a lot of data to transfer, apart from the time to transfer there is a huge administration effort to set it up and to transfer the data.
This is method is kind of a manual migration. This process involves migrating to Office 365 with no data import at the first stage. When the records have been populated and propagated on the internet, we start exporting the mailboxes using the new-mailboxexportrequest to export each mailbox to PST which is a bit archaic. It’s slow and not reliable. On the other hand if you don’t have a lot of data to move this could be your way. After you export all mailboxes to PST, you would need to generate a SAS URL which is given from the import process, upload the PST files using AzCopy and then create a mapping file mapping your PST file to the mailbox as below.
Once done and your CSV file is validated your import will start in the users’ mailboxes. It’s important to note to add the user you are logging into the portal to the import/export role.
The above migration methods are a great way to migrate your setup depending on the volume and how you wish to migrate. Thou one thing strikes me, being the fact that all need a considerate administration effort. As an easy alternative, you can go for EDB to PST Converter which is a fast and reliable tool for migrating mailboxes to Office 365 with a ton of filters and options without any intervention of the administrator and fully automated. Basically all your need is to select the users, setup the credentials to export them.