If you would like to read the other parts in this article series please go to:
- The Evolution of Exchange Online Migrations (Part 1)
- The Evolution of Exchange Online Migrations (Part 2)
Introduction
In part 2 of this article series, we looked closer at the migration options that were available with the next version of Exchange Online, which was included with the rebranded offering that going forward was and still is known as Office 365.
In this part 2, we will continue where we left off in part 2. More specifically, we will take a closer look at the remaining migration options we had and still have at our disposal, which are the Cutover Exchange migration and the at the time brand new and comprehensive Exchange hybrid deployment migration option.
Let’s get going…
Cutover Exchange Migrations
So one of the major drawbacks of the staged Exchange migration option, we covered in our previous article is that it didn’t and even today only supported Exchange 2003 and Exchange 2007. If you had or have Exchange 2010 or later deployed on-premises, you would need to either go with a cutover Exchange migration or an Exchange hybrid deployment based migration. Alternatively, you could go with an IMAP based migration or third party.
Not all Exchange customers could go with a cutover Exchange migration instead of a staged Exchange migration though, as it back then only supported up to 1000 mailboxes in the on-premises Exchange organization. This was later lifted to a 2000 mailbox limit.
Note
Although the current limit for cutover Exchange migrations is 2000 mailboxes, the recommendation from Microsoft is that 150 mailboxes or less is more reasonable (recommended) due to the length of time it takes to create and migrate 2000 mailbox users (source).
Because many customers already had Exchange Server 2010 or later deployed on-premises, the majority went with an Exchange hybrid deployment. There were of course other reasons, why they took the Exchange hybrid deployment approach (which will be covered later), but the limitations in a staged and cutover Exchange migration forced many customers to go with that route.
One thing that kept most Exchange organizations from using the cutover Exchange migration option even though they had less than a 1000 mailbox users was the fact the users would be provisioned in the Office 365 tenant by the migration tool and not by using the DirSync tool (directory synchronization) as it was called at the time. This meant that organizations that had Exchange 2010 or later deployed, had less than 1000 mailbox users and wanted true single sign on (SSO) using AD FS based federation was forced to going with an Exchange hybrid deployment, if native tool were to be used since AD FS expects the on-premises Active Directory to be the source of authority.
I don’t have many screenshots to share of a cutover Exchange migration as I due to this approach being the least popular never finished an article covering this migration option.
But like a staged Exchange migration, you basically added your domain to the Office 365 tenant and created a migration batch, that provisioned the users and mailboxes in the tenant and started to synchronize mail data to the respective mailboxes. You then changed your MX record to point to Exchange Online or more specifically FOPE, which was the filtering service in front of Exchange Online before the migration from FOPE to EOP.
Lastly, you completed the migration batch so that one final delta was initiated in order to make sure all mail was migrated to the Exchange Online mailboxes.
The Exchange 2010 Hybrid Deployment Migration Option
The last and by far most popular migration option from the past is the Exchange hybrid deployment based migration option. With the release of the Exchange Server 2010 RTM on-premises version back in November, 2009, Exchange hybrid deployments was now a thing.
Unlike staged and cutover Exchange migrations, organizations now had an option of setting up an Exchange hybrid deployment, which would provide rich coexistence between the on-premises Exchange organization and the customers Exchange Online tenant in Office 365.
Back then we did not have a fancy hybrid configuration wizard to do the magic for us. Instead, we had to configure the Exchange hybrid manually, which was a time-consuming task as we had to go through huge number of manual configuration steps to have it fully configured. There was a pretty good TechNet resource (approximately 72 pages!) that had all the steps collected in one place, which helped a bit, but still it was a multi-day thing to setup.
To name some of the things, we had to manually setup and configure. We had to configure a special service domain (changed since then), add accepted and remote domains on-premises and in tenant, create an e-mail address policy, setup organization relationships on-premises and in tenant, create receive and send connectors on-premises and in tenant, federate respective domains, configure external DNS. My buddy Neil Johnson still have a great blog post covered many of the manual steps, that you had to configure back then here. These are of course no longer supported by Microsoft, but still an interesting read to get an idea of what was configured behind the scene before we had the hybrid configuration wizard.
Going through all these manual steps was not the worst thing though. The worst thing was when this didn’t work as intended and you had to troubleshoot your way through the activity list again. Remember we didn’t have the same detailed log files as today, so this was a painful time for not only consultants but also Microsoft Customer Support Services as they had a lot of cases logged that all took a long time to solve as they often had to go through most of the configuration steps to see, where the issue(s) were.
Figure 1: The Exchange Online organization has now been added as an additional Exchange forest in the EMC
What made Exchange hybrid deployments what pretty much all organizations went with in this period? So as mentioned this is the only native migration option, that provide rich coexistence. Some of the things you got was:
- TLS secured mail routing between you on-premises Exchange organization and Exchange Online
- Mail routing with a shared domain namespace. That is the primary SMTP domain used on-premises could be used in Exchange Online as well
- A unified global address list (GAL)
- Free/busy and calendar sharing between on-premises and Exchange Online mailboxes
- Centralized control of inbound and outbound mail flow (to honor compliance policies etc.)
- A single Outlook on the web URL for both the on-premises and Exchange Online organizations
- The ability to move existing on-premises mailboxes to the Exchange Online organization (and offboard) in a transparent fashion as in end users could continue working while their mailbox was moved (depending on the on-premises Exchange version hosting the mailbox)
- Mostly centralized mailbox management using the on-premises Exchange Management Console (some settings would be set directly in Exchange Online)
On top of this, an Exchange hybrid deployment fitted well with the DirSync and AD FS setup that most customers went with back then and go with even today.
This concludes part 3 of this multi-part article series.
