Why a “Hybrid” or Remote Move Migration is Always the Right Choice
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 [email protected], but [email protected])
- 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.
Comments (31)
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!
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.
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!
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.
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 :)
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.
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! :)
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.
Andy
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.
Hey Dave! Yes, this would be a separate server, preferably at least 2012R2 Standard.
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.
Steve
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.
Hi
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?
Thanks
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.. I have described all the steps here for review.
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
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!
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.
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?
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.
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)?
Correct the Hybrid Configuration Wizard can be run from any member server, and does not require Exchange to be present on that system.
Hi Alexander,
First of, thank you very much for sharing your expertise on this! You have helped me greatly with the work I’ve been doing migrating a local exchange server to O365. I I have completed all steps listed in your article, however, I am missing a few User Mailboxes that are available on Exchange but not on O365. I created a test mailbox on on-premise exchange that didn’t seem to have appeared in the user list when I start the Move Migration. Is there a reason for that? How would I force sync something like that or even check the status of it?
Thank you very much!
If you have created the account in an OU that is indeed selected for sync, ensure that the Azure AD Connect has exported this user to O365. Find the user in the O365 admin portal and ensure it says synced with active directory. Also, be sure that the mailbox has the address policy applied, so that there is an alias associated to that on-premises mailbox that matches [email protected]. Then, the mailbox will show up as a user mailbox on prem, but it would be listed under the contacts tab in the cloud. When you migrate the mailbox from on-prem to cloud, what happens is the mailbox object on-prem should go away, but you will then see it under the contacts tab in the on-prem EAC. In the cloud EAC the opposite will occur–you would no longer see the user listed in the contacts tab, but it will show up as a mailbox in the cloud EAC. Hopefully that make sense.
Hi Alexander,
For one of my customers, I’m planning on a hybrid migration.
I’ve done some migrations in the past, using the minimal hybrid configuration.
After finalizing the migration batch, Outlook (2010 and 2013) gave no promt asking to reconfigure.
So we had to create new profiles for each user.
Therefore in this new situation I’m planning on a full hybrid migration using their Exchange 2010 server.
The main goal is a seamless migration, without the need to reconfigure Outlook manualy, with at the end a 2016 exchange server for managing purposes only.
After the migration is finished, I want to install a new exchange 2016 server for managing purposes ONLY, and remove the 2010 Exchange server.
( I don’t want to keep Exchange 2010 bc. it’s almost EOL)
That’s why I would like all clients, remote and local to connect directly to the 365 servers.
Would I be able to do this, without reconfiguring Outlook?
So something like:
1. Migrate mailboxes.
2. Finalize the batches -> Outlook reconfigures automaticly?
3. Change the Internal and external autodiscover CNAME to O365
4. Change (Or remove? ) the SCP local? (Would this cause Outlook to be reconfigured?)
5. Install Exchange 2016, re-run the hybrid wizard.
6. Remove Exchange 2010
Would this be the way to go? Or am I missing something.
You will be auto reconnected to the new mailboxes after completing/finalizing the migration batches. No need to change any SCP or autodiscover. You could change those after 100% of users are moved/finished. Otherwise, that looks accurate.
Great article, Alex.
An on-premises user that has synced to Office 365, but hasn’t had his mailbox moved, will appear in Exchange Online as a Mail Contact. Messages addressed to that Mail Contact are delivered using an Exchange Online outbound connector (even if the address is an authoritative accepted domain for the tenant). With full hybrid, the wizard will have created an outbound connector for your domain, designating your on-premises server as a smart host. If you did a minimal hybrid, that won’t exist, so it will use the default Exchange Online outbound connector, which will look up MX records to deliver the message. So for this reason, if you do a minimal or express hybrid, you have to leave your MX records pointing to on-premises until all mailboxes are migrated, otherwise messages to users with an on-premises mailbox from users in Exchange Online will get into an MX loop. I’m pretty sure this is correct, but I haven’t found it anywhere in Microsoft’s documentation. Anything I read about MX records for hybrid Exchange says you can have it pointing to one or the other with no caveats, but I think the author is always assuming full hybrid without saying so explicitly. Does your experience confirm this?
The minimal is specifically designed to support quicker migrations, cutovers, not co-existence. You could manufacture your own internal relay setup (vs. authoritative domain), etc., but if that need exists, why not just choose full hybrid?
Well, of course, if you chose minimal it’s because you want something simple and quick for the purpose of migrating all users to Office 365 and closing all your local databases. Even if you do that, there are plenty of reasons you might have to close a migration batch before others are done.
Thanks for your input.
Hey Alex – I’ve been following and constantly re-reading your articles on Exchange migration in preparation for our own migration. Thank you so much for the work and the detail that went into this!
I have one last thing that I am not sure about. We are coming from SBS 2011, so naturally we plan to do hybrid, which includes standing up a second Windows server and installing Exchange with the free hybrid license. I am not sure what to do about the server OS though – money is a factor here. Here are my thoughts:
– We could use the Windows Server 180 day trial: I am not sure if this is legal to use for production situations like this though.
– Purchase a license for the oldest Windows Server OS that is compatible with Exchange 2013 (I believe Windows Server 2008 R2?). Since all of our users are correctly licensed in SBS 2011, would we need any CALs in this case?
When you go to purchase Windows Server, you can only purchase the current edition. You have downgrade ability to install older editions, but you always just buy what is current at the time. If you plan to use this as a migration tool only, and ditch it after the fact, just work within the 180 day trial. Otherwise, if it is going to be around a while, might as well bite the bullet. The CAL’s that are “included” with SBS only apply to the SBS box.
For a two exchange server 2007 environment (with the mailbox role on one 2007 server and hub transport/client access roles on the second exchange 2007 server) – which will have a new hybrid 2013 server setup – is the HTTP/HTTPS/SMTP inbound ports from the internet required to be open to the new exchange 2013 server?
Outbound for 25/443 for the 2013 exchange 2013 I would assume is required however inbound from internet is unclear.
Microsoft outline their mail flow process in this scenario on their documentation and show that inbound emails will hit 2007 first and then route via the hybrid 2013 server and off to exchange online as required:
https://docs.microsoft.com/en-us/exchange/exchange-2013-and-2007-hybrid/transport-routing#route-incoming-internet-messages-through-your-on-premises-organization
It also states that the client access server would change to 2013 after hybrid is setup – what does this mean in real terms and how are end users impacted? Does outlook/mobile devices/etc automatically connect to the new hybrid server and there firewall rules be changed to prepare for this?
https://docs.microsoft.com/en-us/exchange/exchange-2013-and-2007-hybrid/server-roles#exchange-server-topology
I believe you are correct, that it would work even without switching your inbound services over to 2013 on the edge of the network. If you use the hybrid agent now, it should just publish the virtual directories out to Azure via Azure App proxy, which means no real need for firewall, but this scenario does not support mailflow, so you’d still have to account for that if you wanted co-existence (if you cut over all at once it won’t matter either way).