How is the migration from Exchange 2010 to Office 365 any different than other scenarios? First, before Exchange 2010, there was no way to create a Hybrid environment with Office 365. What is more, Exchange 2010 is one of the most popular source servers. That is because for companies which have more recent server versions, it would be a shame to leave to the cloud just yet, relatively soon after deploying a new Exchange release, and when the support is still available. Finally, there are some additional steps you need to take when you migrate from Exchange 2010 to Office 365.
This article presents a short Exchange 2010 to Office 365 migration guide, to show you how to plan this journey. And how to make it easier.
Native Exchange 2010 to Office 365 migration
Exchange 2010 is the oldest Microsoft-created mailbox server to handle the hybrid environment. That is good news. Hybrid migrations enable you to merge the on-premises and the cloud Exchange into one environment. However, with the Exchange 2010 life coming to an end, it might be a better idea to look for alternative migration plans. To help you get to the cloud, you can use a dedicated tool – Office 365 mail migration adivisor. The advisor is a tool which asks you questions and generates an Exchange to Office 365 migration plan. It includes most of the popular migration scenarios. Bear in mind that this tool is meant primarily for single-forest, single-domain environments. If you have a more complex deployment, prepare for some guesswork.
There are three native paths you can take to get your company from Exchange 2010 to Office 365:
- Cutover migration, which is the most straightforward option. You could say it cuts mailboxes from the source server and pastes them in the target environment.
- Hybrid deployment, which enables Exchange 2010 and Office 365 to coexist.
- PST import – or the manual approach.
Exchange 2010 to Office 365 Cutover Migration
The cutover migration is as simple as getting all users from the source server and pasting them in Office 365. Sounds simple, but there is much more to that. In another article, you can find a detailed cutover migration plan. Below, you can find some steps you need to take before you migrate mailboxes from Exchange 2010 to Office 365.
First, you need to prepare your environment. The preparation and planning might take less time than the actual migration, but it still requires a lot of attention. Below, you can find a short task list for a cutover migration.
- Update your Exchange 2010 server to SP3. While it is not mandatory, it is highly recommended.
- Before you perform the cutover migration, you should disable directory synchronization and unified messaging, if they are turned on.
- Enable and configure Outlook Anywhere. In the newest Exchange Server flavors, this is done by default. In Exchange 2010; however, you need to complete this step on your own. To successfully configure Outlook Anywhere, you need to install a trusted SSL certificate and the RPC over HTTP component on your server. You can test whether the configuration went well by connecting to your Exchange 2010 from outside of your network. This will be tested automatically when you connect Office 365 to Exchange 2010, but the manual test will save you some possible hassle later.
- Assign permissions. There are certain permissions you must assign to the account used for migration. It is common practice to use a dedicated user account for the migration, which has only the minimal required permissions assigned. The permissions the migrating account needs are ApplicationImpersonation and View-Only Configuration for the Exchange Server and Office 365. Additionally, the target Office 365 environment requires View-Only Recipients role and User management administrator if it is also responsible for re-creating users in Exchange Online.
- Create a mail-enabled security group in Office 365. Otherwise, the migration service cannot provision any migrated groups as security groups in Office 365
- Verify your domain in Office 365. It requires you to add a TXT record in your DNS zone.
- Use Exchange Admin Center to create a migration endpoint. The endpoint contains all the information necessary to connect your Exchange 2010 server to Office 365.
- Create and start the cutover migration batch. The batch includes all mailboxes and requires the migration endpoint configured a step before. This is the point when the actual migration happens. After the data transfer is finished, it is worth verifying if everything had gone well. You also need to assign licenses to users.
- Now for the post-migration cleanup, switch your domain’s MX record to point to Office 365. After the TTL passes, emails are routed directly to Office 365. You can delete your migration batch and decommission the on-premises servers.
The migration is less scary when you see what you have to do on a list. Still, remember that the whole task requires a lot of work and time. It may also include some steps which have not been listed above. It is best to study the topic well before attempting the migration.
Exchange 2010 and Office 365 Hybrid
The Hybrid deployment is a kind of migration and more. It is a modern approach to the staged migration available for Exchange 2003 and 2007. Exchange 2010 and Office 365 Hybrid is an environment in which the on-premises Exchange and Exchange Online coexist. This method is especially useful if there is a lot of data to migrate and the process is bound to take a lot of time. Hybrid is the only native method available for migration of over 2000 mailboxes. In fact, Hybrid is recommended for migration of 150 mailboxes and more.
There are organizations which do not use the Hybrid deployment as an intermediate stage, but as the final environment, which has users distributed to both on-premises and the online environments, depending on what each user needs.
The Hybrid environment is created using a dedicated Hybrid Configuration Wizard (HCW). See this article for a step-by-step guide on how to use the HCW and solve problems connected with deploying a hybrid environment.
Migration by PST
The last native migration makes use of the Office 365 PST Import Service. The general idea is to export Exchange 2010 mailboxes to PST files, and then to upload them into Office 365 organization. This method requires an admin to do some manual work. This includes creating Office 365 environment practically from scratch.
Exporting all mailboxes to PST is best done with PowerShell and New-MailboxExportRequest. For full instructions on how to perform a bulk mailbox export to PST, consult this article. The PST files need to be in a shared mailbox or on a file server. From this location, you have to upload them to the Azure storage location and create a CSV mapping file. The PST Import service uses the mapping file to import PST files to the right user mailboxes.
Microsoft also offers an option to ship physical drives to them, which requires you to copy PST files to physical storages and to send them to Microsoft. The cost for this service is $2 per GB of data.
Native limitations
Each of the above native methods for Exchange 2010 to Office 365 migration has some drawbacks. The Cutover migration is an all-or-nothing solution and is not recommended for more than 150 mailboxes. It also does not allow Exchange and Office 365 coexistence. The Hybrid configuration takes a lot of time, and you are likely to encounter some bumps in the road. With Office 365 Import Service, I do not know where to begin. PST files are… archaic. PST Migration is neither automatic, nor fast or reliable. It is only a good option if you do not have much data to move and you do not mind recreating your Exchange 2010 environment in Office 365 from scratch.
There are also native limitations which are common for all the solutions listed above:
- In many steps of the migration, you will need to use PowerShell. Although it is very valuable to know how to use this powerful scripting language, you need a certain proficiency level. Learning on the fly during this complex process might be stressful for you and harmful to the (server) environment.
- For the best migration experience, you need to upgrade your servers to the newest version. It is recommended to get your Exchange 2010 to SP3. Therefore, if you have not updated your machines, prepare for some maintenance.
- Downtime is unavoidable, especially if you want to migrate public folders. You need some careful planning, especially if the resources on your servers are used around the clock.
- Filtering is not available. Neither Cutover nor Hybrid Migration can let you filter items that are moved to Office 365.
The limitations of native solutions force many companies to use third-party tools for migration.
Exchange 2010 to Office 365 migration – the easy way
The easy way to migrate Exchange 2010 mailboxes to Office 365 is to use an Office 365 migration tool:
The migration tool presented in the video is CodeTwo Office 365 Migration. This software changes the migration process from the administrator’s nightmare to an easy and automatic experience and enables some features which are not available in the native scenarios. Here are some of the key features of CodeTwo Office 365 Migration:
- Automatic configuration – the software provides a checklist of the migration requirements and configuration tasks and does most of the administrator’s work. For example, CodeTwo Office 365 Migration automatically creates users in Office 365 and assigns the required management roles to the user performing the migration.
- Scheduling – you can configure your migration jobs, schedule them to run in chosen time frames and forget about them. The program can automatically send you migration reports to let you know how the transition goes and when it is done.
- Advanced filtering options – you can choose to migrate chosen groups of users and even select to migrate only some of their items, based on a time and folder filter. This lets you, for example, migrate only the most recent emails and calendars, switch to Office 365 and then move the older items to the cloud.
- No downtime – the migration can run in the background with no impact on users. Also, you do not need to update your servers to the latest versions before the migration.
For the full list of features, visit CodeTwo Office 365 Migration main page.
Further reading:
Hello, we have a local on primese Exchange 2010 environment, and we need to migrate to 365, the issue is, my DNS still points to the Local. is the use of this program necessary after turning the DNS, or can I do the synchronization and migration of the mailboxes before turning the DNS? Thanks.
You change the DNS record after migrating with the software, as a part of post-migration cleanup. You can check the complete migration guide here.
Hello I have a question. What if I am doing this migration. and after migration some test users and or creating some users directly on the o365 admin portal. I am not able to receive email to those mailboxes. they can send email out but if you email then from the outside it does not get the email. Any ideas what is missing> connectors? mstp relay? imm at a lost here.
It might mean that you haven’t switched your domain’s MX record, or the it hasn’t updated yet (the default TTL period takes some time). In the meantime, you can route traffic to their *onmicrosoft.com addresses instead of their custom domain ones – they should work without issues.
Hello, I inherited a hybrid 2016/ office 365 environment and would love to go pure o365. I’ve read about some nightmare stories trying to do this. Does codetwo have anything that would assist here
Great article! What type of migration would you suggest when migrating 150 users from Exchange 2010 to Office 365 with these requirements:
-I would like to have AD integration
-I would like to decomission the Exchange completely after the migration and manage users with ADUC/Adsiedit and with o365 portal
Is this even possible?
Hi Gabriel,
If you want to use one of the native methods, for 150 users I would recommend an express migration. This method is not perfect (supports only a single endpoint and only one migration batch is migrated at a time,) but it should work well for a small company.
The real problem is with decommissioning Exchange and keeping the AD integration in place. If you want to keep the AD integration and continue to use ADUC/ADSIEDIT, it is recommended that you keep the last on-premises Exchange Server.
I recommend reading the article written by Jaap Wasselius on AD synchronization without an on-premises Exchange Server. It does not answer the question which migration is the best for you, but might cause you to reconsider either decommissioning the on-prem Exchange, or keeping the AD sync in place.