Comparing Office 365 Migration Methods

Back to Blog

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.


Comments (3)

  • Beayn Reply

    For Hybrid configuration, you ask the question, “Why wouldn’t you use this method?” Wouldn’t an answer to that question be – because you have to keep your old exchange server running to manage your users mailboxes?
    I’m working on a client migration now and we want to use hybrid for user convenience but also want to shut down the server after… and have minimal effort involved. I’ve only just begun reading up on this and it doesn’t seem all that easy to do Hybrid / Exchange shutdown (which requires Exchange 2019 anyway).

    April 17, 2023 at 7:54 am
    • Alex Fields Reply

      Well a couple of notes here. First, this post is old. That having been said, hybrid migration has been possible since Exchange 2010 (2019 is/was not a requirement). Even if you were on an unsupported version such as SBS, you could simply insert a “bridge” server temporarily to do the migration. Eventually they made the whole process even easier with updates to the HCW, and “modern” hybrid. At the end of the day, this isn’t all that hard to accomplish. Especially because a lot of people were doing AAD Connect back then (these days I am pushing folks off of it). In any case, upon completion of migration, you can either keep hybrid around or dismantle it (your choice). Please note also that you no longer need to keep Exchange around if you want to do hybrid–it is now supported to remove the last Exchange server. But, these days if someone is coming from an older system like SBS, 2010, 2013, then I would just as soon use a third-party tool and call it a day. No AAD Connect, none of the hybrid stuff.

      April 17, 2023 at 10:00 am
  • Beayn Reply

    Hi and thanks for the reply. Sorry at the time I did not know how old the post was. It only says 14 JAN at the top for a date.
    We’ve just come back to this and decided to do minimal hybrid, so just researching and prepping. It’s Exchange 2016 and about 110 mailboxes.
    Thanks again for the info.

    September 13, 2023 at 1:39 am

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.