Despite large amounts of effort from Microsoft in online resources and education over the past year, many organisations are still having difficulty with migrating their email infrastructure to the cloud and are confused as to the various migration options available. This blog post is intended to assist organisations gain an understanding as to the various options available to them for migration to Office 365 and pick the right migration solution to meet their needs.
Microsoft provides organisations four methods for migrating user mailboxes from an on-premises Exchange environment to the Microsoft Office 365 cloud based on an organisations requirements. These migration solutions include:
- Exchange Cutover Migration
- Exchange Staged Migration
- Hybrid Exchange Deployment
- IMAP-based Email Migrations
Each of these migration solutions will be covered individually below.
Exchange Cutover Migration
An Exchange cutover migration involves cutting over all domains from an on-premises infrastructure to the cloud in one hit, usually over a weekend. The advantage of Cutover Migrations is that no additional infrastructure needs to be provisioned on premises such as the Microsoft Online Services Directory Synchronisation tool, Hybrid Exchange Servers or Active Directory Federation servers. The disadvantage with Exchange Cutover Migrations is it provides no co-existence between the on-premises Exchange environment and Office 365. Cutover migrations migrate the user’s entire on-premises mailbox to the cloud and are generally used when there is a small number of on-premises users which need migrating to Office 365.
Exchange cutover migrations work by the Office 365 servers connecting to your on-premises Exchange servers through RPC over HTTPS (also known as Outlook Anywhere) and downloading all mailboxes into Office 365. To ensure Office 365 is kept up to date with new emails/items and calendar information or content deleted by the end user, Office 365 will automatically synchronize with the on-premises Exchange environment once every 24 hours.
In a cutover migration, once all on-premises mailboxes are synchronised in Office 365, administrators can plan a date in which disruption can occur (usually a weekend) to cutover the mail MX records to the cloud. This means all external mail servers on the Internet relaying mail to the organisation will now send mail directly to the cloud.
It is recommended prior to performing the MX record update, the time to live (TTL) on the MX record be reduced to a smaller value such as 30 minutes to ensure mail servers around the world release the old record and request the updated record. If the MX record has a large TTL value such as one week, it could mean that for some mail servers, it may take up to a week before mail is sent to the new Office 365 address. Directly after the MX records are changed, it is recommended a final on-demand synchronisation be performed within the Office 365 interface.
Office 365 will automatically generate new passwords for all user accounts in the cloud. On Monday morning administrators will need to run around to all computers and recreate the users a new Outlook profile to ensure users are setup correctly. It is important to note that because the users Outlook profiles need to be recreated, the user will lose their local cached mailbox or OST file. In an Exchange cutover migration every user will need to re-download their cached mailbox which can present problems especially when there are a large number of users accessing Office 365 behind the same internet link.
It is also important to note that not all permissions are preserved when mailboxes are moved to Office 365 using a cutover migration. For example Send As permissions on mailboxes will be lost and administrators will need to reconfigure this once users are moved across into the cloud.
Exchange cutover migrations support Exchange 2003, Exchange 2007, Exchange 2010 and Exchange 2013.
Exchange Staged Migration
Unlike an Exchange cutover migration, staged migrations allow users to be moved across to Office 365 in small controlled batches. Staged migrations provide simple co-existence with Office 365 in which mail flow is maintained between the on-premises Exchange organisation and Office 365. This allows for users to exist both on-premises and in the cloud during migration. It is important to note that staged migrations only provide simple co-existence meaning only mail flow will be available between the on-premises and environment and Office 365. Exchange rich collaboration features such as delegation, calendar sharing, free-busy and meeting rooms will not function between Office 365 and on-premises users in a staged migration deployment.
Staged migrations also require additional infrastructure be deployed on premises. The Microsoft Online Services Directory Synchronisation tool (also known as Forefront Identity Manager or DirSync) needs to be deployed on-premises on a server which is not running as an Active Directory domain controller. This tool ensures that all recipient objects on premises are synchronised to Office 365 to ensure the Global Address List is fully populated both on-premises and in the Office 365 cloud. This allows users both on-premises and in the cloud to view the entire global address list - a process which is often referred to in online documentation as GALSync. It is also important to note that Office 365 tenants must have an M or an E type licensing plan available in their Office 365 subscription in order to use the Microsoft Online Services Directory Synchronisation tool.
Exchange staged migrations also work by the Office 365 servers connecting the on-premises Exchange servers through RPC over HTTPS (also known as Outlook Anywhere) and downloading all mailboxes into Office 365. As a result the on-premises Exchange environment must be configured with Outlook Anywhere and a valid digital certificate for the migration process.
Unlike cutover migrations however, staged migrations do not support incremental synchronisation of mailbox information. This is because in a sense, staged migrations do not need incremental synchronisation to due to simple coexistence. When the Office 365 migration wizard starts migration on a selected batch of on-premises users, the wizard automatically configures the TargetAddress property of the user’s on-premises mailbox using administrative credentials of an on-premises administrator supplied to Office 365 to an Office 365 specific email address. This ensures for every email the on-premises mailbox receives, the on-premises Exchange server also forward a copy of the email onto Office 365. This process is shown in the following diagram.
Note: If the user creates changes in the user’s mailbox such as deleting content or performing tasks which do not involve SMTP transport, these changes will not be synchronised to the cloud during simple co-existence as these activities cannot be sent via an email message.
When the Microsoft Online Services Directory Synchronisation tool runs it creates mail-enabled users for every mailbox user on-premises within Office 365. As soon as the first migration batch is run in a staged migration, Office 365 will convert the mail-enabled user in Office 365 to a mailbox user. As a result users can begin using the cloud based mailbox instantly – with this in mind however the users mailbox will be completely empty as the migration batch has just been kicked off and has not synchronised yet. Companies can provide users instant access to their Office 365 cloud mailbox and advise the users their mail “is still coming” and reinsure the users they will not lose any mail. Alternatively administrators can wait until a synchronisation batch has completely finished and then provide users access to their Office 365 cloud mailboxes.
After every mailbox in the on-premises organisation has been migrated to Office 365, companies can then point the MX records for any on-premises “accepted domains” to the mail gateway addresses provided by Microsoft for Office 365. Like with cutover migrations, all user profiles will require recreation and users will get a new OST file meaning they need to re-download their entire mailbox from Office 365. Staged migrations do have an advantage over cutover migrations however - companies can minimize the performance hit of re-downloading the users OST files by allowing users to recreate their profile in batches. Also as with cutover migrations, all users will receive a new password from Microsoft which is to be used for accessing their Office 365 mailbox.
It is important to note that staged migrations only support Exchange Server 2003 and 2007, not Exchange Server 2010. In Exchange 2010 and Exchange 2013, the TargetAddress property can't be modified. This is the reason that staged Exchange migration doesn't support migrating Exchange 2010 and Exchange 2013 mailboxes to Exchange Online.
Hybrid Exchange Deployment
Microsoft Office 365 hybrid migrations provide rich coexistence between an on-premises Exchange environment and Office 365 such as mail routing, calendar and free/busy information and mailbox delegation. It provides organisations the ability to slowly move individual mailboxes to the Office 365 whilst keeping the rich collaboration experience provided by Microsoft Exchange between on-premises and cloud users.
Unlike cutover and staged migrations, Exchange hybrid migrations do not rely on RPC over HTTPS (Outlook Anywhere) to transfer the user mailboxes from an on-premises Exchange to Office 365. In fact Exchange hybrid migrations use the mailbox replication proxy (MRSProxy) to perform mailbox moves to the cloud - a concept known as "cross-forest" mailbox moves. MRSProxy is the same technology built into Exchange for performing things such as on-premises mailbox moves between mailbox databases or between Exchange servers in a local Exchange organisation. The mailbox moves between an on-premises Exchange server and Office 365 are "online mailbox moves" which means the user is able to work and send/receive email while their mailbox is being uploaded to Office 365.
Out of all the Office 365 migration methods, Exchange hybrid migrations require the most amount of on-premises infrastructure be deployed and is the most complex migration method in terms of integration work. The complexity built into the solution is what gives users a completely seamless experience irrespective of what environment they are in whether it be cloud or on-premises.
Exchange hybrid migrations require a minimum of three servers be deployed on-premises with more required in the event high availability be implemented. These servers include:
- The Microsoft Online Services Directory Synchronisation tool (also known as Forefront Identity Manager or DirSync)
- Active Directory Federation Services (ADFS)
- At least one Exchange 2010/2013 server on the on-premises Exchange environment
Note: The term Exchange hybrid server is used many places on the Internet. This is simply an Exchange 2010 server with at minimum the Client Access and Hub Transport roles installed in an existing Exchange 2003 or Exchange 2007 on-premises organisation. Exchange hybrid servers are not a different version of Exchange 2010 nor do they have different installation media. It is the same version of Exchange, just configured to provide rich coexistence through federation.
Below is an overview of how hybrid configurations with Office 365 fit together taken from the Microsoft Exchange Deployment Assistant.
The DirSync server as with staged migrations is responsible for ensuring the global address list in both on-premises and Office 365 environments remains fully populated with all mail-enabled users, groups and contacts in the Exchange environment. This process is often referred to as GALSync in online documentation.
The Active Directory Federation Services (ADFS) server is a mission critical server in hybrid configurations and as a result it is often recommended clustering be implemented through Microsoft Network Load Balancing (NLB) or a third party load balancer technology. When Office 365 is configured in a hybrid deployment with an on-premises environment, the "source of authority" is configured to point to the on-premises Active Directory environment. What this means is all authentication requests for user which happens within a tenants Office 365 environment is sent back to the on-premises environment through ADFS to authenticate against an on-premises domain controller. In the event the on-premises ADFS deployment become unavailable, users will not be able to authenticate with Office 365.
The Exchange 2010 / 2013 server is required to setup a federation trust between the on-premises Exchange organization and Microsoft Federation Gateway. This is what enables the rich co-existence to occur between the on-premises Exchange environment and Office 365 to allow features such as free/busy and delegation to work between the two environments.
A hybrid configuration between Office 365 and an on-premises Exchange environment is the best approach for organisations who wish to setup rich co-existence and migrate users slowly in controlled batches. Unlike other migration methods such as cutover or staged, hybrid configurations do not require users to obtain a new password. Through the use of ADFS they can continue using their on-premises username and password for logging in and accessing cloud resources a process known as single sign-on.
Another advantage of performing a hybrid migration to Office 365 is users do not need to recreate their Outlook profile, a major disadvantage of cutover and staged migrations. This means users do not need to re-re-download the entire Outlook OST file or “cached exchange mode” cache.
Think of a hybrid configuration as making your on-premises Exchange and Office 365 environment one and the same. Some organisations setup a hybrid configuration for other purposes other than just migration to Office 365. For example, if you want to put a user’s secondary archive mailbox in the cloud a hybrid configuration is needed. Hybrid configuration also allows you to migrate users through mailbox moves from the cloud back to an on-premises environment providing the utmost flexibility.
IMAP-based Email Migrations
An Office 365 IMAP migration provides the ability to migrate an IMAP based mailboxes to Office 365 in which Office 365 downloads the user’s mailbox by connecting to the IMAP server. IMAP migrations are intended to provide a migration path for non-Microsoft email systems to Office 365.
An IMAP migration works by creating a CSV file with all the account names and passwords for each of the IMAP users which are to be migrated to Office 365. This process means administrators need to gather each user’s password to their IMAP mailbox and manually input the password into the CSV file. This CSV file is uploaded to Office 365 in the web interface. Office 365 will then connect to each mailbox and download all email for each user into Office 365.
As with cutover migrations, Office 365 is able to perform incremental syncs every 24 hours for IMAP mailboxes to ensure any new emails which arrive on-premises are also synchronised to the cloud.
When all users have been migrated to Office 365, administrators simply need to cut over the MX records for any domain names associated with the mailboxes and distribute the new Office 365 username and passwords to the end users.
I still need help!
In the event you need assistance with planning or performing your Office 365 email migration, I am more then happy to assist. Please get in contact with me by emailing me on
clint.boessen@avantgardetechnologies.com.au or leave a comment below.
I hope this blog post has been helpful.
