Comparing Office 365 Migration Methods

At the time of this writing, Microsoft offers three primary migration paths from on-premises Exchange servers into Office 365: Cut-over, Staged and Remote Move.*  In this series I would like to discuss each of them, and highlight the differences.

Cut-over migration

The first option is the cut-over migration. Cut-over can be used with any version of Exchange server, and is typically recommended for smaller organizations. This option can be performed with or without DirSync in place (e.g. for password synchronization). They claim you can use this method for up to 2,000 mailboxes, but I personally wouldn’t use it with more than about 25 or so.

It seems like a fairly straight-forward, simple process: all you have to do is define a migration endpoint (your Exchange server’s web address) along with some administrative credentials.  The migration batch will copy all mailbox data from your on-premises server to the cloud, and once it’s done, you just “flip the switch” and cut-over your organization’s DNS records to the new service.

Except that it is not that simple. There are six basic categories of reconfiguration required for cut-over migrations, and all of your client devices will stop working against the old server until you reconfigure them to use Office 365:

Internet DNS. Your organization’s Internet DNS records will require updates. A TXT record will verify that you own the domain(s) you say that you own, while MX and CNAME records will (at cut-over time) be switched to Office 365, away from your on-premises server.

SMTP relay. Next, if you are using SMTP relay from any on-premises multifunction devices or applications, such as scan to email or automated communications/alerts from line-of-business software, you will need to reconfigure them manually to use one of the Office 365 relay methods.

Permissions.  Unfortunately, cut-over migration rarely seems to pull certain delegations and other permissions (full access on mailboxes, access to public folders, etc.) that exist or are configured on the Exchange server.  You may need to manually copy these or reset them in the cloud.

Local servers. You will need to adjust some settings in your Active Directory/DNS servers, update Autodiscover SCP’s, disable Outlook Anywhere or RPC over HTTP, and eventually properly remove/uninstall Exchange from the environment altogether (sometime after migration has been fully completed/verified).

Mobile devices. For mobile devices this is usually pretty straightforward. If you remove the account and re-add it (inputting an email address and password), autodiscover will take care of the rest, assuming your DNS records are already in place.

Outlook clients. Outlook clients must be done manually.  With a fair number of users, this can become a laborious, time-consuming endeavor very quickly. Profiles have to be setup from scratch—autofill, signatures, rules and archives—none of this stuff comes along for the ride by default, and each requires some technical steps of their own to complete. One of the most common ways to deal with these headaches is to send out “self-service” instructions to end-users, and field support calls for a few days after cut-over to iron out the issues.

In sum, this method is highly manual and time consuming, which is why I only recommend it for very small businesses where there are few users, and the changeover can be done quickly.

Staged migration

The second method is a staged migration, which can be used with Exchange 2003 or 2007, and is usually recommended for mid-sized or larger organizations. The principles here are exactly the same as cut-over migration (above), except that you can split up the cut-over into smaller batches of users, and just do a few at a time. This is useful when you have hundreds or thousands of users to get through, but the cut-over process is still very labor intensive and time-consuming.

When you configure a staged migration, mail flow destined to mailboxes which have been migrated to the cloud will be forwarded from your on-premises server to Office 365.  Likewise, in the cloud, mail-flow for addresses that still exist on-premises are forwarded back down to your local server–this requires a little bit of extra configuration to get it working right.

During migration, users who are still on-premises will be able to communicate (send and receive emails) with users who have been migrated to the cloud, but that is about the extent of it.  You cannot view shared mailboxes, contacts, calendars, etc. that live in disparate places, so functionality is reduced until the migration is fully complete and DNS records are cut-over.

Remote Move a.k.a. “Hybrid” Migration

The best and most robust method is to use Remote Move migration or “Hybrid” Exchange.  This method requires an Exchange 2010 or 2013 Server, as well as Directory Synchronization with Azure AD / Office 365. It is usually recommended for larger/Enterprise customers.  I recommend it for SMB customers as well.

Hybrid configuration allows your local Exchange server to partner with your Office 365 tenancy in the cloud, and create a single environment that shares resources.  So when you transfer a mailbox from the on-premises organization into the cloud, it is still your original mailbox; it shares the same GUID and all of the properties that your old mailbox had.  Therefore, both Office 365 and your local server are always aware of who is in possession of which resources, and what those resources look like.

Unlike with cut-over and staged migrations, you will not need to worry about reconfiguring Outlook clients and profiles manually. You can also continue to use your on-premises server for SMTP relay, if you so choose. Permissions are transferred more reliably, and technically less server-side and DNS changes are necessary to complete the migration.

The best part is a completely zero-touch Outlook experience from the perspective of the end-user.  At cut-over time, clients are simply prompted with a message similar to: “An administrator has made a change that requires you to close and reopen Outlook.”  Once they do, they are reconnected to their mailbox in the cloud.  If SSO is not configured using ADFS, then they will also be prompted to enter their credentials (and choose the option to remember password). That’s it!  Mobile devices will still require you to delete and re-add accounts, as always.

Why wouldn’t you choose to use this method? Especially when coming from Exchange 2010 or newer.

Happy migrations!

*You’ll notice I left out IMAP migrations. They certainly have their place, like when you have zero administrative access to a hosted Exchange server, or you’re coming from an altogether different email system.  This method is even more laborious than these others, since you have to provision the Office 365 cloud accounts yourself before you can migrate, and oftentimes (in the end) it can come down to just manually exporting/importing mailbox data via PST files, anyway.