Why a “Hybrid” or Remote Move Migration is Always the Right Choice

11. January 2016 Opinion, Technical 20

True, hybrid does require more up-front configuration, and of course there are those pesky pre-requisite requirements of having Exchange 2010 or 2013, as well as Azure AD Connect for Directory Synchronization. But the benefits do outweigh these concerns—trust me. The overall time commitment to your migration project will plummet with a hybrid server, and it will be easier.

But what if you are still on Exchange 2003 or 2007? Aren’t you pigeon-holed into one of the other migration methods by default? Absolutely not; for example, if you install a 2013 server alongside 2007, you are covered. Microsoft allows you to do this with a free license if you have a qualifying Enterprise Office 365 plan, and you intend to use a hybrid deployment to move to Office 365!


The migration checklist goes something like this:

Before migration:

  • Ensure all your domains are verified in your Office 365 tenancy;
  • Your on-premises Exchange environment should be fully patched/updated;
  • Active Directory users’ UPN names should be configured to match their email address (e.g. they should not look like username@domain.local, but emailname@domain.com)
  • You must install and configure Azure AD Connect (formerly DirSync);
  • This step is only required if you do not already have Exchange 2010, 2013:
    • Re-key & reimport your UCC cert to include a new DNS name such as “hybrid.domain.com” in addition to mail, autodiscover, etc.;
    • Get your hybrid Exchange product key
    • Install a new or temporary Exchange 2013 server with all of the standard roles, activate using the key, and import the UCC cert;
    • Ensure your firewall is configured to allow HTTP/HTTPS and SMTP traffic to/from the new Exchange server, same as it is configured for the old Exchange server;
    • Create a new DNS (A) record for hybrid.domain.com—for the new server—and point autodiscover CNAME records to hybrid.domain.com;

To migrate:

  • Run the Hybrid configuration wizard from the Exchange server;
  • Migrate mailboxes using the Remote Move method;
  • Migrate Public Folders, if required;
  • Complete the Office 365 setup by finalizing migration batches and cutting-over DNS records:
    • Autodiscover CNAME and SCP should be configured to point to the hybrid server;
    • If you want mail to flow into Office 365 directly instead of coming through your local Exchange server, be sure to update MX and SPF to point to Office 365 also (recommended).

After migration:

  • Remove legacy Exchange servers and update on-premises DNS (only if necessary, depending on your scenario).

That is really all there is to it—notice that it doesn’t require super specialized skills or an Enterprise-sized organization.  If you can run through a couple of wizards, import a certificate and change some DNS records, you will be able to do this migration all by yourself, and with minimal time commitment/end-user hassles.

If you do not want to keep your hybrid server around after the fact, then there is an approved process to remove it. Please note that certain management features are easier with a hybrid server in place, and I generally recommend keeping one around if you are planning to continue using password/directory synchronization. Microsoft also recommends this. More on this topic here.

20 thoughts on “Why a “Hybrid” or Remote Move Migration is Always the Right Choice”

  • 1
    Brad on November 14, 2016 Reply

    Hi Alex,

    OK so i have bounced around A LOT when trying to decide which migration path to use. My environment on-premises is Exchange 2010 SP3. I have Outlook anywhere, Azure AD Connect and the added domain UPN. I am basically ready to roll with the migration path of my choice but there seems to be a few things about each that scare me. I should state that i want to decommission my On-premises Exchange eventually, and I would love it if my Users passwords synched to the cloud. Here is where my stuff gets weird. We made our 365 tenant a while ago and as a result we have ACTIVE users using it for their office suite, nothing else; just office. This became an issue because I discovered if I was using cut-over I would have to delete them prior. Plus I’m reading that password sync could have issues with the user accounts after if I don’t convert users to mail-enabled users. With that being said, am I better off taking the Hybrid approach and how close am I to being able to do that? Thanks!

    • 2
      Alexander on November 14, 2016 Reply

      Hi Brad, I believe hybrid is the best option. Some notes about this:
      1) Hopefully you do not already have mailboxes enabled on the accounts in the cloud–in that case it is still possible, but will require some more work, because you cannot have more than one mailbox GUID between on-prem and cloud environments when you turn on the sync. So you may have to make sure there is only one mailbox for each user (and that it exists on-prem only). If you already have Exchange online active for some users, removing the checkmark box for the Exchange Online plan in the 365 portal will not be enough by itself–there is another process whereby you connect to Exchange online using PowerShell and clean them up all the way, so to speak. I don’t have a good link on that process, but if you open a service request through the 365 portal, my experience with MS cloud services support has been very good lately–they are usually responsive and can walk you through it over the phone or in a remote session. Again, this may not be necessary if you don’t have any Exchange online licenses/active mailboxes out there in the cloud yet.
      2) Once you have verified the above or taken steps to clean it up, then before you activate Azure AD Connect for directory synchronization/password sync, it is possible to install the tool in “staging mode” (one of the last screens of Azure AD Connect custom install wizard) so that it does not export any data to Azure AD. That way you can verify the accounts are matching correctly before you take it out of staging mode. You will be able to create a soft match of objects between your local domain and the cloud instance based on the User Principal Name (UPN), and Display Name. Best practice is to ensure that the UPN matches the Email address.
      3) If you wish to eventually retire your Exchange servers altogether, it is possible to either: A) remove Hybrid relationship & Azure AD Connect, B) optionally replace Azure AD Connect and Hybrid Exchange with password sync provided by the Essentials experience integration (up to 100 users) or C) Migrate to a free version of hybrid Exchange server that is installed on a member server (sometimes the Azure AD Conenct/management server) or even a Domain controller (which is supported but MS issues this statement).
      This may sound like a lot, but there really isn’t much more than a half-day or so’s worth of work between you and being able to synchronize and get hybrid all setup.

      • 3
        Brad on November 15, 2016 Reply

        Hi Alex,

        Thanks for the response! So I would say yes my cloud accounts do have mailbox’s setup and it is the same as the on-premises email address. When I tested AD connect with the password sync the accounts lined up with no errors in Idfix and I tested password synchronization as working fine (just a few accounts). This was when my approach changed. My plan was to switch them over to cloud, then bulk-migrate (.pst import) the on-premises mail into the cloud accounts and I was done. Now I am re-evaluating my approach. I was steered away from hybrid by classmates in a 365 course where everyone said go cutover if you can, hybrid was just too much work. I wanted to do hybrid, I wanted to stage things but followed their advice and focused on cutover. Now I am in a bit of a mess because id like to transition this over during the holidays and I still cannot firm-down on a strategy. Especially reading your blogs about going Hybrid if you can. What’s better at this point?; just blast away the cloud accounts JUST prior to running the cutover wizard (so it creates all new ones with the migration batch), or firm-up on the steps needed to hybrid this to the end. I have a server setup already with AD Connect, Outlook anywhere prepared. Is hybrid as simple at this point as installing the Hybrid role into my on-premise exchange and configuring Hybrid migration within the cloud exchange online console? If you were to take on a project in this state, could you map out the process? Thanks again!

        • 4
          Alexander on November 15, 2016 Reply

          I won’t say one approach is necessarily better than the other. From my experience, I like hybrid because of how much less impact it is on users, and how much less time I spend working with them on Outlook profile switch-over, autocomplete, etc. When I switched in my practice to using hybrid over cut-over, my profitability went up–I still charge the same per mailbox for migration, but my time investment is less from an admin standpoint.

          That being said, if you ran the hybrid wizard now, you may not be able to migrate through the portal because there can only be one mailbox per identity, and right now you have two. When you’ve already got active mailboxes in the cloud (empty, I’m assuming), and you’re attempting to migrate the on-prem data, you really have two options. 1) You can just do pst export/import–it is easy and reliable, but requires a little patience from users and admin. Or, 2) You would need to remove the mailboxes from Exchange Online (completely–using MS support), and get the mailbox guid’s from on-premises re-synced to the cloud, and migrate from there. That second option would be necessary whether you are using Microsoft’s cut-over or hybrid (remote move) method through the portal. Technically the third option is to use a third party tool, but many organizations shy away from that because of cost.

          Because you already have mailboxes in both locations for the same identities, either way is going to be more “involved.” Hybrid is great when you set it up from the beginning though, because it is just about as easy as running a wizard, essentially.

          • 5
            Brad on November 15, 2016

            Hi Alex,

            I understand. So its safe to say that the rumors surrounding the fact that we already had identities in the cloud could cause an “issue” is true. I cannot just delete a cloud identity from the Portal admin center you’re saying? I will need MS support for that?

            Thank you again for your response 🙂

          • 6
            Alexander on November 15, 2016

            If you remove Azure AD sync, completely remove the cloud identities and then re-install /reactivate the sync (without adding licenses to the users that are created) then all new identities would be starting from scratch and I think this would be possible to move forward w/ hybrid. A lot of folks who move partially to 365 on other items before doing Email migration, for example might be using OneDrive, SharePoint, etc. and that path isn’t an option for them since they’d be removing actual data by blowing away the cloud accounts. But if you have no data to lose, it might be just as easy to do it that way.

  • 7
    Brad on November 15, 2016 Reply

    Hi Alex, All good stuff. I think since the cloud accounts do have nothing i am going to go through the purging approach, i mean you get a 30 day grace period on the office suite anyway. Thanks and ill be sure to follow your work good stuff bud! 🙂

  • 8
    Andy Bryant on November 18, 2016 Reply

    Hi Alex,

    Nice article. I am faced with a migration from SBS 2008 to O365 over the Christmas period. This seems like a lot of work, especially if you are migrating 25 users in a company with limited resources i.e. the resources to configure and deploy a VM to run a temporary copy of Exchange 2013. As far as I can see the main benefit of this over a staged migration, which was the approach I was planning on, is that it saves you having to amend the clients Outlook profiles. I can see the attraction of doing this if you’re moving hundreds of mailboxes.


  • 9
    Dave on February 25, 2017 Reply

    Great blog Alex. I am a bit confused on the Hybrid Exchange 2013 server though. Can this be installed on my SBS 2008 server that has exchange 2007 running on it or do I need to build a new server and install the hybrid exchange server on that?

    Thanks again for the blog. Its been a life saver.

    • 10
      Alexander on February 25, 2017 Reply

      Hey Dave! Yes, this would be a separate server, preferably at least 2012R2 Standard.

  • 11
    Steve Dimestico on May 12, 2017 Reply

    Hello Alex,

    We have done some migrations of clients from SBS 2011 with Exchange 2010 to Office 365 online successfully but they have been with just ten or so users, using the import /export method of PST file to move the data to Exchange online. Now we have to do it with a few clients who have 50 users and databases of 250 gb. We were going to do a cutover migration because we felt that it would be the best way to stage it over a coupe weekends with the least downtime. However, the clients already have some users on Office 365 licenses for Skype for business. There are no Email exchange online accounts, but the entire organization had been synced using AD connect and we configured the UPN names as well. In talking to Microsoft they have now indicated, in order to do a cutover migration, we would have to remove all the licenses, disable AD connect and purge all the accounts which could take up to 72 hours before we could do a cutover migration. We essentially have to start over and allow the cutover to recreate the accounts, then reassign licenses and then re-enable AD connect. Is that how you understand it? When I read your article, it maybe made more sense to use the hybrid configuration, but the goal is to completely decommission the on premise Exchange Server. We have other domain controllers on the network. If we did decommission the on premise Exchange server, but still had domain controllers on the network would that take care of the directory synchronization without any further configuration? Or…..should we just give in and use the old PST method. Your input would be greatly appreciated.


    • 12
      Alexander on May 12, 2017 Reply

      Yes that is accurate. So in this instance, since Azure AD Connect /UPN changes are already done, you are halfway to a hybrid migration. It is fully supported to do that type of a migration, which would not require any rework or removing accounts, etc. If any users were created in the cloud with mailboxes prior to running the Azure AD Connect tool, you would not be able to migrate the on-prem mailbox (a cloud one already exists), but it sounds like that is not the case here. So you should be good. Afterward, yes you could totally remove the Exchange server, but keep sync. MS’s official stance is that they do not recommend removing Exchange completely. I have seen it done however, and you just have to use ADSIedit to manage stuff like alias addresses (proxyAddresses attribute). The way I get around this issue in small clients who don’t really want an Exchange server, but also want to be fully supported–I just add Exchange 2016 into the environment–can be added to any member server or even Domain Controller (fully supported, but comes with a warning/statement from MS). I have several clients who opted for this, and it’s nice because then you still have an on-prem management interface for dealing w/ Exchange properties on user accounts, without using ADSIedit. After you install Exchange 2016 (pre or post-migration), then you can fully remove the legacy system, whether 2010 or 2013. If coming from 2007, you need to add Exchange 2013 before doing hybrid, in order to support hybrid mailbox moves.

  • 13
    Mikey on May 29, 2017 Reply


    1. Above you wrote about doing this before migration: “Create a new DNS (A) record for hybrid.domain.com—for the new server—and point autodiscover CNAME records to hybrid.domain.com”. ==> So typically autodiscover.domain.com already exists outside. Does this mean removing the existing record and instead adding a CNAME for autodiscover pointing to hybrid.domain.com externally?

    2. Above you wrote about doing this: “Autodiscover CNAME and SCP should be configured to point to the hybrid server”. ==> Not sure what this means. Do you mean doing this INTERNALLY on DNS immediately after finalizing the hybrid wizard?


    • 14
      Alexander on May 30, 2017 Reply

      1. I usually stand up a new name such as “hybrid.” and ensure autodiscover is associated to it rather than the legacy environment, but it can be done either way–you could also setup coexistence and cutover your cas/front-end services to the new hybrid server, with a name like “legacy.” for the old system. 6 of one, half dozen of the other.
      2. Two things: Yes it means changing your DNS for autodiscover, but it also refers to the Service Connection Point (SCP) in AD. This can be accomplished in PowerShell with Set-ClientAccessServer -AutoDiscoverServiceInternalUri . I have described all the steps here for review.

  • 15
    Ross on September 11, 2017 Reply

    Thanks for this article! I have several customers where we have setup a new Office 365 tenant, added mailboxes and use mail in the cloud for a while. Then the customer wanted to sync passwords, so we added DirSync and soft matched the on-prem AD accounts to the existing Office 365 accounts. This worked well…we now create new accounts on-prem, they get synced up to Office 365, then we assign a license and O365 creates a mailbox and we can manage mailbox sharing and most other stuff through the O365 Exchange Admin Cecnter. We just have to manage the proxyAddresses in AD user attribute editor and that’s about it for on-prem Exchange management.
    We have a NEW customer now that has SBS 2011 and we want to do hybrid migration to O365, but absolutely don’t want to keep an Exchange server around long term. Question is when we decommission the on-prem Exchange server (on SBS), what does that process look like to keep the on-prem AD accounts syncing with DirSync? And can we still use O365 EAC to manage the more advanced Exchange functions like we do with that first customer I described (mailbox delegation, shared mailboxes, message tracing, etc)?
    Thanks in advance, having a hard time finding definitive info on this scenario!

    • 16
      Alex on September 11, 2017 Reply

      This is a great question, one I get so often that I will need to write an article to address it. Microsoft does not officially support the use of AAD Connect /DirSync without the on-premises Exchange server, technically speaking. However, it is possible to do, and manage just the way you describe, where directory sync is added after the fact, once Exchange is completely removed.

      There is only ONE caveat you need to be aware of: before you decom /uninstall Exchange, you will need to export all of your proxyAddresses to a CSV file. During this time it is good to stop the sync utility temporarily. Then, when you uninstall, all of the proxyAddresses are removed from the users, so you will then need to re-import them. Finally, you can re-enable the sync, and it will work just as before.

      Check out this resource for a nice script that does the export & import, shared recently by another member of our community.

      • 17
        Ross on September 12, 2017 Reply

        Thanks! I just came across your article on the newer Express Migration method. My plan now is to use that process with the one-time AD sync, decommission Exchange after a while, then implement AD sync again later using the server Essentials role. Is that a “safer” more supported way of doing it? The Essentials role would work fine here because the customer just needs a single local server. Or do you feel the Essentials role method is really unnecessary if I’m using the method you described in your previous reply?

        • 18
          Alex on September 12, 2017 Reply

          The real difference is that the Essentials role provides a supported way of editing on-prem and cloud objects simultaneously (while not being a true “sync” service–it provides that illusion, as well as one-way password sync). The key word here being “supported.” The option I described before works for keeping true directory synchronization, but it is *not* officially supported. Though, rumor has it MS is softening their stance here, I still haven’t seen it published anywhere. Essentials might be the safer choice. I do have an article on decomming the Hybrid server and replacing with Essentials, as well.

          • 19
            Ross on September 12, 2017

            Thanks again for the info. On the subject of the Express Migration in an SBS 2011 environment….since AAD Connect can’t be installed on a SBS server, the Hybrid Configuration wizard should be run on a member server instead? This won’t pose any issue even though Exchange is not on that member server (no Exchange 2016 install on the member server)?

          • 20
            Alex on September 12, 2017

            Correct the Hybrid Configuration Wizard can be run from any member server, and does not require Exchange to be present on that system.

Leave a Reply

Your email address will not be published. Required fields are marked *