For many companies, it's tempting to migrate from Exchange 2010 to Office 365. The former is becoming outdated. With Exchange, the infrastructure is on-premise, meaning you have to invest in maintenance. Your data isn't as secure. Perhaps worst of all, if disaster strikes, it can be harder to recover your data.
Office 365 is easier to manage and will save on costs in the long run. The program offers more features and is much more secure. The software is up-to-date and keeps your data much safer.
Here at Wintellisys, we understand how difficult the migration process can be. It's complex, time-consuming, and requires extensive planning. Additionally, many things can go wrong during a migration.
In this guide, we'll discuss different migration methods. We'll help you determine what the best course of action is for your company. After reading this, you'll have a better understanding of how to complete a successful Exchange 2010 to Office 365 migration.
Microsoft Exchange Server Deployment Assistant
Before getting started, you should know about the Microsoft Exchange Server Deployment Assistant. It's a free tool provided by Microsoft. You can use it to help develop the appropriate migration plan.
When you launch it, you'll have to answer a few questions about your current environment. The tool will then generate a step-by-step checklist. It has solutions for the most common migration scenarios.
The Microsoft Exchange Server Deployment Assistant is meant for single-domain, single-forest environments. A more complex deployment may require some guesswork.
Native Migration Paths
You might be familiar with IMAP migrations. This method can be used as a shortcut for transferring mailboxes from pre-2000 versions of Exchange. However, IMAPs won't transfer tasks, contacts, or calendars. IMAP is primarily used for migrating non-Exchange email systems to Office 365.
For an Exchange 2010 to Office 365 migration, Microsoft supports three native paths. They are:
- Cutover migration. This is typically the most straightforward option. Essentially, it involves cutting mailboxes from the source server and pasting them into the new environment.
- Hybrid migration. This approach allows Office 365 and Exchange 2010 to coexist. It's considered the most complicated of the three native paths.
- PST import (also referred to as the manual approach). This method is relatively archaic. It should only be used if you do not have much data to move.
Read on to see each method further detailed.
In theory, the cutover method sounds simple. You've got to get all of the users from the source server. Then, you paste them into Office 365.
In practice, however, it is much more complicated. You'll want to have a good understanding of the process before getting started.
The migration itself requires attention, but the planning and preparation might actually require more time. Some things you want to include in your task list include:
- Upgrade your Exchange 2010 server to SP3. While not mandatory, this task is highly recommended. It can save you a lot of trouble further down the line.
- Configure and enable Outlook Anywhere. For Exchange 2010, this is not the default. To do this manually, install the RPC over HTTP component and a trusted SSL certificate on your server. Manually test the configuration before proceeding to save hassle later on.
- Disable unified messaging and directory synchronization.
- In Office 365, verify your domain and create a mail-enabled security group.
- Assign permissions. One dedicated user account should have the following minimal permissions:
User Management Administrator
- Create a migration endpoint using the Exchange Admin Center.
- Create the cutover migration batch.
- Verify that the data transfer was successfully completed.
- Assign licenses to users.
- Implement post-migration cleanup procedures.
Keep in mind that this is not a comprehensive list. As you go through the process, you'll likely have to complete other steps.
There's also stage migration available for older versions of Exchange. Then there's hybrid deployment. This is considered the more modern approach.
With hybrid migration, on-premises and online Exchange can coexist. This method is perfect for when you have a lot of data to move. It's the only native method available for 2,000+ boxes. In fact, hybrid deployment is recommended if you have 150+ mailboxes.
This method can be used as an intermediate stage. Some businesses use it just for the final environment. Users are distributed to both on-premises and online environments. This will depend on what each user needs.
Deploying a hybrid environment can take weeks of planning. You must collect data on the infrastructure and current configurations. This information is used to plan migration stages. The data also will help you implement proper testing.
For this process, you'll need to use the Hybrid Configuration Wizard (HCW). Once you launch the program, it'll search for the correct Exchange server. It'll verify user credentials to continue its deployment.
Then, you need to enable Federation Trust. This allows users to freely share information such as calendar tasks.
The next step involves establishing the connection between online and on-premises Exchange servers. A window will pop up prompting you to select the server that will receive Office 365 emails. On port 25, the server should have the appropriate SMTP certificate. Additionally, the port can't be blocked by the router or any firewall software.
Next, establish the server for the Send Connector. You also have to identify the Transport Certificate. This'll allow for secure communication between Exchange 2010 and Office 365.
Finally, enter the fully qualified domain name. This'll complete the transfer.
But you aren't done yet. You'll want to analyze the wizard's logs. The txt files show you every task the wizard performed. This will allow you to determine exactly where problems occurred. By understanding the txt files, you'll be able to locate and to resolve any issues.
In short, the wizard is easy to run, but the tasks it performs are complex. You should analyze the tasks it performs before creating a hybrid environment. This will allow you to avoid problems where possible and adjust your plan as needed.
Also referred to as the manual approach, PST import is your third native option. You will have to use the Office 365 PST Import Service.
The general idea: start by exporting mailboxes to PST files. Then, upload them to the Office 365 organization. To accomplish this, an admin will have to do manual work. They'll have to create an Office 365 environment from scratch.
You should make use of PowerShell and New-MailboxExportRequest. These tools will allow you to perform bulk exports.
PST Import: Migrate Exchange 2010 to Office 365 Step by Step
- Place PST files on a shared file server or mailbox.
- Upload them to the Azure storage location.
- Create a CSV mapping file.
- Import PST files to the respective user mailboxes. For this step, use the PST Import Service.
Microsoft also accepts physical drives. This requires you to put PST files on physical drives and send them in via mail. The service costs $2 for every GB of data.
Limitations to Native Approaches
Each native approach has its limitations.
Cutover Migration Limitations
- This is an all-or-nothing approach. You won't be able to select certain items to import.
- It shouldn't be used on servers with more than 150 mailboxes.
- It does not allow Exchange 2010 and Office 365 to coexist.
Hybrid Migration Limitations
- You are likely to come across obstacles.
- The process takes a lot of time.
PST Import Limitations
- The expense of the physical drives service can add up.
- It's not fast, automatic, or reliable. It should only be used when you don't have much data to move.
- You have to recreate your Exchange 2010 environment from scratch.
In general, all of the native methods can have these limitations:
- You have to use PowerShell. This scripting language is powerful and good to know. However, it can take a while to master. If you aren't already fluent, you will have to learn it along the way. This can cause unnecessary stress and produce poor results.
- You need to upgrade your servers. This will result in the best migration experience possible. If your servers aren't updated, be prepared to do some maintenance.
- There are no filtering options. You can't choose what specific items you want to be moved to Office 365.
- Your company will experience downtime. During migration, your servers won't always be available. You have to plan work hours around when the transfer occurs. Especially if you want to migrate public folders, you will experience downtime.
The Easiest Method
The limitations of native approaches cause many businesses to look for alternatives.
A migration tool might be the way to go. This method provides the administrator with an easier experience. The process is automatic and implements convenient features. Some of the most popular migration tools feature:
- No upgrades required. You won't need to update your servers to the newest versions.
- No downtime. Migration tools can run in the background. This allows users to continue operations as normal.
- Automatic configuration. The software does the bulk of the administrator's job. It provides a checklist of requirements and configuration tasks. For instance, tools can automatically create users in Office 365. Then, they assign the management roles required.
- Advanced filtering options. Use this feature to migrate certain groups of users. You can even choose to only migrate some of their items. This is done using folder and time filter. For instance, you can opt to only import the most recent calendars and emails.
- Scheduling. This feature allows you to easily configure migration jobs. Schedule them to run during selected time frames. Once this is done, you can forget about them.
- Migration reports. You'll receive regular reports. They will detail how the transition is going. They will also let you know when everything is completed.
The Bottom Line
The benefits of an Exchange 2010 to Office 365 migration are well worth the hassle. Your office will have an interface that is much easier to navigate and manage.
Keep in mind that you have several options available to you. Native paths can serve as practical methods. That's if you are familiar with the processes.
If you aren't comfortable with doing it yourself, third-party migration tools are the way to go. They ensure the smoothest possible transfer. This allows you to focus on other aspects of your business.