How to perform a Cutover Migration to Office 365
My preferred method for migrating Email to Office 365 is to use the Remote Move (aka “Hybrid”) method. If you are coming from SBS 2011 or Exchange 2010, then definitely go that route. If you are coming from older versions such as SBS 2008 or Exchange 2007, note that it is indeed possible to add a free hybrid server to complete the Remote Move migration.
Still, for various reasons, many people will end up choosing the cutover method, so I want to detail the process here. Finally, in case you run into issues setting it up, there is a fail-safe method you can use (export/import PST), which I will also share in this article. Here are the steps to complete a cutover migration:
- Prepare for the migration
- Migrate Exchange data
- Create a migration batch in Exchange Online OR
- Export Outlook data to .pst files
- Export other Outlook settings
- Finalize the migration batch & activate the mailboxes
- Complete your Office 365 Setup and cut-over DNS
- Changes to on-premises Active Directory and Exchange
- Add SMTP relay connector (if applicable)
- Create new Outlook profiles, import data & settings
- Reconfigure mobile devices
- Post-migration tasks
Step 1. Prepare for the migration
If you haven’t already, go ahead and sign up for an Office 365 account online and verify your domain. Also: so many pitfalls can be avoided by taking the following precautions:
- Have a good backup before making any changes–for Active Directory as well as Exchange
- Ensure your source server has the latest service packs / updates
- Run Best Practices Analyzers to identify potential issues with existing configuration
- Any users with more than 15-20 GB mail data should archive old items (e.g. prior to 1-2 years)
- Review the steps in advance and communicate the plan to stakeholders / end users
If you do these things first, you will avoid many issues and be able to recover in case of unforeseen problems.
Step 2. Migrate Exchange data
Two methods are discussed in this article, because some folks have trouble getting their migration batches working, and may need to fall back on the “manual” PST export/import procedure. I will discuss both in turn.
A. Create a Migration Batch Online
Now you are finally ready to begin moving mailbox data. First you need to create a migration endpoint. Go to the Exchange admin center in the Office 365 Admin portal. Navigate to recipients > migration and find the ellipse (see screenshot):
Step through the wizard to define your on-premises Exchange server as the migration endpoint. Pick Outlook Anywhere since this is a cutover migration.
After the endpoint is defined, choose the plus symbol and select Migrate to Exchange Online from the drop down.
Step through the rest of the wizard–you will need to provide the Internet address of your Exchange server as well as credentials for reading the mailbox data. Once you complete the wizard, data will begin to copy. You can return to this portal later on to watch the progress of your sync.
B. Export Outlook data to .pst files (optional)
In case you have issues connecting Exchange Online to your on-premises Exchange server, the fail-safe method I mentioned earlier is to export and import your email, contacts and calendars to an Outlook .pst file. The following article from Office support will help your users do just that, from various Outlook versions:
Note: You can use the .pst export/import method to migrate Public Folders also, if applicable.
C. Export other Outlook settings
Whether you use a migration batch, or do manual .pst export/import, Outlook rules and signatures are not included. Have the users export their rules, and back up their signatures and auto-complete lists. Do this in advance of the cut-over date, while the data is still moving.
Step 3. Finalize the migration batch & activate mailboxes
If you were able to use the cutover migration batch successfully, the status of your migration batch(es) will say “Synced”. In this state, the initial synchronization is completed, and deltas will continue to run every 24 hours. You can now cut over your DNS records at any time. Note, depending on when your batches finish and when you cutover mailboxes, there may be some “delayed” mail items, since there is a chance some new messages have been delivered on-premises. Over the next 24 hours, this should get all caught up, so just be sure to set expectations in advance.
Also, in case you haven’t activated your users’ licenses yet, return to the Office 365 Admin center, bulk-select your Users, and click Edit product licenses to apply the Office 365 / Exchange Online licensing. This will activate the cloud mailboxes.
Finally, if you are using the Windows Server Essentials Azure AD / Office 365 Online Integration services (instead of Azure AD Connect), you will want to click on each user in the Essentials Dashboard and Assign a Microsoft Cloud account (this will link the on-premises account to its counterpart in the cloud). Completing this action will force users to reset their passwords on next login, so that the new credentials can be synchronized to Office 365.
Step 4. Complete the Office 365 Setup and cut-over DNS
I usually complete steps 5-8 after hours, at the end of a work day, and set expectations that mail will be unavailable until the morning when we proceed to reconfigure Outlook profiles and mobile devices. However, tech-savvy users would be able to configure their own devices as soon as you are done cutting over DNS records.
As soon as you’ve finalized the migration batch, you are ready to complete the Office 365 setup process you started earlier by verifying your domain. Return to the Office 365 Admin center > Settings > Domains to complete your set up. You will be required to enter additional DNS records with your domain registrar / service provider.
Once you have added the records, mail will no longer be delivered to your on-premises Exchange server.
Note about DNS changes / Email delivery: After DNS cutover, it is possible an email or two could still delivered to the old server, but the “finalized” migration batch will sync deltas during the next 24 hours, which can cause a “delayed” email effect in the new mailboxes. This behavior should cease after DNS TTL has expired and the new record has propagated.
Step 5. Changes to on-premises Active Directory and Exchange
On-premises, there are some changes that need to be made at this time, also. First, DNS will need to be updated, but only if the zones for your Email domain names exist on-premises. Note that you only need to add the autodiscover records for the Email domains, and not for “.local” or “.lan” DNS zones. If you only have a “.local” DNS zone, and no zones for the Internet domain name that you use for Email, you can skip the on-premises DNS update.
A. Update DNS Records
Open the DNS management console on your Active Directory server. If you have existing (A) records for autodiscover, remove them first. Expand the DNS zone for your Email domain, and edit or add the CNAME record for autodiscover here: autodiscover.outlook.com.
You can verify it is working by clearing the DNS cache on the server and then pinging autodiscover.yourdomain.com. It should return a value for one of the Microsoft datacenters, such as nameast, namwest, namnorth, etc.
You can add the other DNS records if you choose to use Skype for Business, Intune, etc., but this one record alone would be sufficient for the purposes of Email migration to Office 365.
B. Changes to Exchange Server
Depending on which version of Exchange Server you are migrating from, you will have some different adjustments to make to ensure that clients no longer attempt to connect to the local server.
SBS 2008/2011 or Exchange 2007/2010
Open the Exchange Management Shell and type the following:
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.outlook.com
And press Enter.
Next, to disable Outlook Anywhere, simply type the following into your Exchange Management Shell:
Disable-OutlookAnywhere –Server <ServerName>
And press Enter. You’re done.
SBS 2003 / Exchange 2003
Open the Exchange System Manager. Expand the tree to find your server, and right-click to open the Properties dialogue.
Navigate to the RPC-HTTP tab and select Not part of an Exchange managed RPC-HTTP topology.
Click OK–you’re done.
Step 6: Add SMTP relay connector (if applicable)
You might also want to add an SMTP relay connector to Office 365, if you were previously using your Exchange server to relay mail from on-premises LOB apps, or from scan-to-email devices, etc. Office 365 can provide a relay connector to replace this functionality.
1. From the Exchange Online admin portal, go to Exchange Admin Center > Mail flow > Connectors. Use the “plus” symbol to add a new connector, choose From: Your organization’s email server and To: Office 365. Step through the wizard, specifying the external IP address(es) of your organization under By verifying that the IP address… and clicking the “plus” symbol. You can leave default values in the rest of the wizard.
2. Ensure that your spf record in DNS includes spf.protection.outlook.com as well as ip4:<YourExternalIp>:
v=spf1 ip4:[ExternalIPAddress] include:spf.protection.outlook.com -all
3. Check that your firewall allows SMTP (25) outbound from the device(s) that require access to the connector.
4. On the device itself, you will need to change the SMTP or smarthost address from the internal Exchange server’s IP to the host of your MX record (e.g. companyinc-com.mail.protection.outlook.com). You can ping this address to obtain an IP if the device only accepts inputs of IP rather than hostnames.
Step 7. Create new Outlook profiles, import data & settings
A. Outlook clients
Users will now be required to setup a new Outlook profile and import the data & settings that were exported earlier. These Office support articles can help your users complete these tasks:
- Create an Outlook profile
- Outlook email setup
- Import email, contacts and calendars from an Outlook .pst file (if applicable)
- Import or Export a set of rules
- Copy email signatures to another computer
- Import Auto-Complete List
B. Public Folders (if applicable)
If you exported Public Folder data to PST, you will need to create a Public Folder mailbox in Exchange admin center first, before importing the data to Office 365. Go to Exchange admin center > public folders > public folder mailboxes.
Step 8. Reconfigure mobile devices
Users must also reconfigure mobile devices to use Office 365. In most cases, this just involves removing and then re-adding the Email account. Assuming you have autodiscover configured properly, this should be pretty straightforward.
If you have to enter manual settings, you would use outlook.office365.com for the server name, and re-enter the email address again if asked to provide a domain\username.
Step 9. Post-migration tasks
Now that you are done migrating Email to Office 365, you no longer need your on-premises Exchange server. See this post for how to remove Exchange 2007 or 2010 (written for SBS servers but works on non-SBS Exchange boxes also).
If you made it this far, congratulations on the migration! Don’t forget to keep improving–explore what else is new in Office 365. Maybe you will want to configure Mobile Device Management (MDM), Multi-factor authentication (MFA), or turn on Email encryption with Azure Rights Management (RMS). Or check out other add-on features such as Advanced Threat Protection (ATP) to help with emerging / zero day threats.
All of these technologies would have likely represented separate third-party products / investments in the past. Now you can leverage the Microsoft Cloud to easily & cost-effectively deliver them from one place to your end users. How about that?
Comments (53)
Hello,
Thanks for the useful article. I have my cutover migration batch created and plan to use ADSync once cutover migration is complete. Once the cutover batch creates my users and syncs the mailboxes can I then enable ADSync and will it match my users? I’m concerned that if ADSync syncs on premise exchange attributes it will cause issues for the Office 365 mailboxes. Is Office 365/ADSync smart enough to not overwrite Office 365 exchange attributes with on premise attributes if it detects an Office 365 mailbox exists?
Thanks
Gareth
Yes, it should work just fine and use SMTP matching. It will overwrite some properties, but if the primary SMTP addresses match it will understand that as the same identity. I also recommend adding the Internet domain name suffix to your internal domain, and switching all users over to using that suffix, if you haven’t already. The idea is that even on the local domain users could login using their email address as the identity, instead of domain\username as we’ve trained them to do for years. This will give you the best and most consistent results with Azure AD Connect.
Hi, Great articles in this site. thanks for providing light on this process. I am planning to migrate using cutover from 2010 to o365. I planned to use Adsync however im concerned about the exchange attributes being removed after we decommission the exchange server. Should i just turn it off? or is it safe to decommission ex2010 without affecting the Adsync tool?
thanks
I would recommend keeping an Exchange server for management if you’re using Azure AD Connect–it is technically not supported to remove the last Exchange server when you’re setup that way. An alternative method is to use the Essentials Experience role and enable Office 365 integration. I’ve also written about how to remove a legacy Exchange server and move to the integration instead.
Great, Thanks for the information.
Excellent article. One minor thing to clear up though: the text says “Select your batch and move the status to Complete.”. I can’t see any way to move the status to complete! All I can do is start.stop/delete etc.
You know what, Jim–I didn’t realize at first that this was the “cutover” migration article. You are correct, that complete button is only available if you’re doing a Remote Move (hybrid) style migration. Once it says Synced, you are basically ready to cutover. By default, it will continue to sync deltas every 24 hours after the initial sync is complete, so depending on when you cutover, there may be some delays, unless you sync manually again after you flip the DNS records. Article updated, thanks for the comment, and good catch!
Just a heads up, as of 2 Feb 2017…if you enable Azure AD Sync before you create your migration batch you can’t select a cutover migration, and if you created the batch but did not run it, then install AD Sync, it will cause the migration to fail.
I’ll follow up with whatever winds up fixing this in a later post…
Thanks for the comment Dave. I imagine that you would be able to disable Directory Synchronization in the Azure AD tenancy, and try the batch again. But keep us posted. I have updated the article. Since they recently released the Express migration option, seems like the “new cutover” method of choice.
Hi Alex,
Is this method “not destructive” for the existing onpremises exchange.
I mean , can we just setup the cut over and let it sync be active for a longer period , without cutover , and just use the on premises exchange.
In that case one can prepare “synced” O365 mailboxes , without interruption running operations and “time” the cutover.
The way it works is that a synced mailbox will sync deltas once every 24 hours. So no matter when you pick your cut-over time, it is possible that there could be some “delays” from the user’s perspective, depending on when that delta sync is happening, and how long DNS takes to propogate, etc. There are a couple of ways to minimize this effect with good timing (e.g. end of a workday/overnight). In general, if you have the option between cutover and hybrid, always choose hybrid–it really is way less hassle with the client machines. But, if you must go cut-over, just be wary of the timing. Last: you could still, upon DNS cutover, write in the onmicrosoft.com address as the “targetAddress” property on each user’s AD account. This would create an effect similar to hybrid, in that any mail delivered to the on-prem exchange server after cutover time would be automatically “forwarded” to the cloud mailbox.
Very good article. We’ve been planning to move to office 365 for the past few weeks now and there has been obstacles on every move we’ve had.
We’ve ran the AD connect on our server to sync our identity information (pwd). That’s been running fine so far. All users were moved to office 365 and have been assigned a license.
We currently have an on premise exchange (2010 SP 1) and we are unable to upgrade to SP 3 as we do not have the proper resources to have a disaster recovery in place prior to proceed with the SP 3 update. Hence, hybrid migration is a fail.
We’ve then tried to do a PST upload move. Before proceeding, we’ve ran a few tests to ensure the users’ mailboxes were in order. However, upon reviewing the mail settings, we got the following error message: “This user’s on-premises mailbox hasn’t been migrated to Exchange Online. The Exchange Online mailbox will be available after migration is completed.” We really don’t know what else to try now.
You are getting that message because you have Azure AD Connect installed. This can only be leveraged if you are doing a hybrid migration (Remote move). Cutover means that you do not have AD Connect in place. So you have two options: 1. Remove AD Connect on-prem and disable the synchronization in your tenant or 2. you can update to SP3 and do the hybrid/remote move… if you need an easy backup all you have to do is a one-time Windows Backup of that system, and then run the SP3 updates. I have not seen issues updating to SP3 that were not quick and simple to resolve. But, if you remove the Azure AD Connect piece and also disable syncing in the Azure AD tenant, you should be good to go with a cutover style migration.
Great article. Many thanks for it. We have just taken over a client that has already setup AD Connect to their Office 365 portal with Exchange 2010 on premise. They want to move to Office 365 and decommision the local Exchange 2010 server. The Migration Endpoint option is available but when you go to the Migration to Online Exchange, the Cut-Over option is not available. Does this mean I cannot use your guide to perform the migration?
If they already have Azure AD Connect and have synchronized from the local on-premises AD then your best option is probably going to be Remote move (aka Hybrid migration). I do have an article on that also. If they want to decom the 2010 server at the end, they will also need to remove AAD Connect. Microsoft’s official stance about Azure AD Connect with Exchange Online is that you must have an on-premises Exchange box, for management UI, even if you move all of your mailboxes to the cloud.
Its possible after cut over migration completed I will install AD azure sync tool for password replication ?
Yes, this is possible. You can configure Azure AD connect after a migration rather than before. Note, that values you manipulate in the cloud will be overwritten by the values contained in the local AD, for example proxyAddresses (aliases). So just be careful to keep it consistent, and match the UPN on-prem to the email address for best results.
Alex,
How can I enable Office 365 integration in my on-prem Server 2012 r2 Essentials dashboard if I already have it integrated with on-prem Exchange 2013? We are conducting a cutover migration from Exchange 2013 to Office 365. I’d really like to be able to manage it from a central place and have the user’s passwords synchronize. Great article btw!
Well if you are coming from Exchange 2013 I would strongly suggest using the hybrid/remote move method. It is much easier. Also, this means you would disable the integrations for Essentials and just use the Azure AD Connect tool from the Exchange 2013 server. If you are going to stick with cutover, then you would disable the Exchange integration, and then enable the Azure AD & Office 365 ones after.
Is this the preferred way when moving from SBS 2011 to O365?
Is it optional to use Windows Server Essentials Azure AD / Office 365 Online Integration services (instead of Azure AD Connect)? Do iu have to deploy a hybrid server first like mentioned in the other article?
There are several supported methods. Cut-over is indeed supported. In order to be supported with Azure AD Connect and a Hybrid configuration, you would need a “bridge” server running Windows Server Standard (to support Azure AD Connect) and Exchange 2013 or 2016 with the hybrid license. Azure AD Connect/Hybrid is not supported directly on SBS 2011, hence the hybrid server I recommend in that method.
I would like to cutover from an SBS 2011 to O365 without Hybrid/Azure AD. Is this possible in that way?
Correct. You do not need hybrid and can just go cutover. Some prefer this method, to avoid hybrid.
We are looking to move our 160 or so users from our on-prem Exchange 2010 installation to exchange online. We would really like to decommission the on-prem server for a variety of reasons, so a cutover seems to be the right choice. I have run the AD Connect tool to provision my users in O365 (so they can start using the other aspects of it while we work on the mailboxes) but from reading through the comments here I will need to uninstall this before I migrate mail, and then can reinstall it after exchange is decommissioned on prem to allow password sync, is this correct or will this cause issues?
When you remove Exchange, the uninstall will remove Exchange-related attributes such as proxyAddresses. So it is a good idea to export those to CSV, and re-import them before you re-enable Azure AD Connect. Also, you can still do a hybrid migration, then decom the hybrid server per this article: https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx
Unfortunately it looks like we will need to keep our exchange server around to continue to be able to manage things as well as keep those attributes in AD. The good news is that we can get an updated exchange key for a hybrid deployment as part of O365 (which I learned from another article here, so thanks!) this alleviates a lot of our concerns, but I really wish MS would let us completely remove the on-prem servers in an O365 deployment without losing all the management through AD Connect.
How would things work with trying to migrate from an external shared hosted Exchange 2013 i.e. we cannot access the server directly? There are only 30 users on this legacy solution, and we want to make the move to Office 365 as easy as possible.
The easiest by far would be to use a third-party tool like BitTitan. Otherwise, Cutover or IMAP methods are available, but they are similar in that you’ll have to reconfigure local Outlook profiles manually.
Thanks Alex! We used CodeTwo for our on-premises Exchange 2008 migration which worked well for us, and I had hoped that Exchange 2013 would be even easier. BitTitan does indeed describe exactly our case, to work with an external host that does not provide admin or server access.
Hi. Thank you for great articles. I am preparing cutover migration from old Exchange2007 to existing 365 environment, for the first time to existing tenant. If I add new domains to existing tenant (internal relay), create connectors and transport rules on 365 for domains on 2007, this is enough for all users, on 365 and 2007 to send mail between servers without problem during cutover batch phase? Before those migrated users get 365 licenses, their mail is not active on 365 so routing will be active to old 2007 through connector?
I will put it this way: I have heard of people finagling this successfully. Basically creating a “DIY” hybrid mailflow scenario. I have not done this personally, but I suppose anything is possible. However, 2007 supports both cutover and staged style migrations. And staged will probably accomplish what you’re looking for. With cutover style, all of the mailboxes would be moved to 365 at once, in a single swoop, so co-existence isn’t really a big concern. Another tip: after cutover procedure is complete and DNS is moved, you can optionally set all “targetaddress” attributes on the user objects on-premises to read “[email protected]”–so any mail still flowing into the old Exchange box will be forwarded automatically to the corresponding mailbox in the cloud. This is useful for sluggish DNS propogation and also local relays like scan to email. Be sure the SPF record includes both the Exchange online protection address as well as the external IP of the local firewall.
Staged migration at this moment is not possible at this moment unfortunately. As far as I tested this configuration with connectors and transport rules, it works after registering domains and testing manually created users before creating batch job, so I hope it will work during the batch job also. My plan is let job active for a week, so this is the only time when mail flow between on premise server and 365 must work. Thank you for your suggestions and I will let you know was there any problem.
Hi, thanks for posting this. I’m planning a cutover of only 10 users and I understand that once the batch is synced it sends deltas every 24 hours so I’m thinking of starting the migration batch on a Wednesday and then complete the work at the weekend. Due to other work commitments this looks like my only option to get the migration completed in the time I’ve been given. Do you see any problems with this?
As long as you don’t have any really large mailboxes probably would be fine. But note that migration time is completely dependent on how much data you have, and your ISP connection. I have seen some larger sized mailboxes take several days on slower WAN links.
Thanks this is a great guide..one thing that might help those doing their first cutover…the user passwords are emailed to the account used to create the migration batch, as long as you first assign yourself a license to create a mailbox.
Thanks for a great article. I’m curious why you prefer the Hybrid Minimal over the Cutover migration.
We’ve done several Cutover Migrations and they work extremely well.
Having said that, we’re usually moving them to a new server along with a new AD forest (getting them off the old .local domain and onto a FQDN that’s unique, like corp.cantoso.com), so we have no use for the old SBS/AD setup.
That’s a legit migration path, and makes sense for cutover.
Thanks for the excellent article Alex. I (In my “free” time) manage 10 sbs 2011 environments (each with <10 end users). I am finally getting around to migrating on prem exchange to O365 and have a quick question. I plan to perform a cutover for the first as the client is leaning towards the eventual removal of the SBS server and not incorporating another Microsoft on prem server in the future (possibly workgroup clients with local SAN for file storage). In any case, I want to pursue the O365 cutover now and leave the sbs server in place (file server /centralized Auth /etc) until the client makes a final decision regarding the future on prem server. What will the user sign on /authentication experience look like if I proceed in this fashion. Will I lose SSO and be prompted for O365 credentials once the new Outlook profiles are created? (Currently have Win7/Outlook 2007 clients and introducing Windows 10 during the cutover).
Thanks in advance!
Shawn
Right with cutover there will be separate username/password for the cloud, so they will be prompted to put in email address and password for Outlook. They will not want to try using Outlook 2007. Get the 365 software installed so they have the latest bits to authenticate to the cloud mailbox.
Thanks much! This client is now considering a SBS 2011 to MS365 migration path. In these situations have you typically acquired a new domain name to use within the cloud environment and then just migrated email/data or is there a good hybrid approach that will allow me to reuse the existing domain name?
Thanks!
Thanks much! They are now actually leaning towards a SBS 2011 – > Microsoft 365 migration (Which I am extremely excited about as it seems to be the most cost effective SMB approach). In these scenarios, have you typically stood up a new DNS namespace/azure infrastructure and just migrated data or have you used a hybrid approach?
Thanks again for all of your assistance!
Shawn
Generally you would not need any kind of server infrastructure (unless you have legacy LOB apps that require a Windows Server infrastructure to run). In the 365 admin center you can just add the existing public domain name that is already being used for email–you just have to put some records in at your DNS hosting provider to prove you own the domain, and then eventually update the MX, SPF, etc. when you’re ready to cut-over. That’s all that is required. Computers are dis-joined from local domain and re-joined to Azure AD, and you just sign in using your email and password + second factor.
Oldie but goodie article.
I have a client on SBS 2008 with Exchange 2007…yikes! They are finally letting me drag them kicking and screaming to Exchange Online and a new server for PDC and file services. So first I’m moving them over to Exchange Online. From what I have researched, a Cut Over migration is my only choice in this due to the age of the on-prem Exch.
When I create the migration batches, and run them, it will create the users in 365 and move the emails over. What happens to new, incoming email during this time of migration? It should go to on-prem because the DNS records haven’t been changed yet, but do those new emails migrate?
Also, from what I have seen, I have to manually reconfigure Outlook on each computer…true? This client has two remote offices, so configuring Outlook on each PC would be daunting.
Any insights and/or ideas would be much appreciated.
You can use a third party tool or the Microsoft native tools. Third party will give you more control over the final delta syncs (which just happen 1x/day with MSFT with very little control over when it goes) as well as the endpoint cutovers. For instance, BitTitan has a tool that will flip the Outlook profiles over for you. I would check out BitTitan’s Migration Wiz product if I were you in this situation. Also I would look REAL hard at Microsoft 365 Business instead of a local file server–migrate files to OneDrive, SharePoint/Teams, and join PC’s to Azure AD. That is going to be way better in the long term.
Hi,
Thank you so much sir for clearing out this topic.
Please I have a question just to be sure in cutover migration I don’t need to sync users with Azure ad connect.
just create the patches and perform the migration will create users in office 365 automatically.
Please answer me.
Right, for cutover you do not have to use AAD Connect if you don’t want to. For hybrid style it is necessary, but it is optional for cutover.
Hi Alex,
Fist i wanted to do Hybrid but my “Minimal hybrid” option is greyed out. So im looking for cutover.
I want to do a cutover migration to O365 from my Exchange server 2010. What I’am concerned about is two things:
1. I have existing users on tenant syced using ADConnect tool, some of users are using Teams etc. Can I use cutover migration for this scenario will the cutover delete existing users or match them?
2. I have Exchange 2010 and 3rd party anti-spam appliance in front of it. From public internet Exchange is only available on port 443 and anti-spam is available on port 25. Does Exchange need to be published externally on port 25 also, and do i need to reconfigure some public DNS in this scenario?
Don’t do cutover. If the option is greyed out then you might already be in minimal hybrid. I have seen that before. You can use Get-HybridConfiguration on-prem to see if it already exists, and look for outbound connector to 365. You can also try checking for a migration endpoint in the cloud, and create one if it doesn’t exist. But you can dismantle a “part-way done” hybrid by removing the hybrid config on both sides, then running the wizard again.
Hi Alex,
Good point. After review with Get-HybridConfiguration command there was already hybrid configuration which was corrupted. I deleted old configuration and deleted Hybrid from ADSI. After that i started again HCW and I was able to select Minimal Hybrid.
Just to answer my second question maybe will help others, after HCW setup I successfully migrated one test user. I didn’t published Exchange on port 25, (Exchange was only published on 443) HCW did the job, and didn’t have to do any modifications on 3rd party anti-spam service.
I have a doubt, supose that i create the migration batch in first place, the migration change to the state “Synced”, i change the DNS and emails start coming from Office 365, what happend with the emails received in on-premises from the last Sync, until i start receiving from Office 365?
The migration batch continue syncing emails, even when you already change the DNS and start receiving from office 365?
In some moment after change the DNS the migration batch stop syncing?
I Hope if you can answer this doubt that i have, thanks in advance…
Cutover is different than hybrid. Hybrid is usually the way to go, as there is no question–the email box gets removed on-prem and relocated to the cloud. Mail delivered on-prem flows to the cloud.
In cutover, you can cut DNS, most mail will start flowing to 365, but some may still come into old server, however that only gets synced 1/24 hours so the first day after cutover it can be a bit funky–but usually fine after that. Or plan off-hours so this is less likely to happen. But again, cutover method sucks, I only do hybrid anymore.
Thanks for your answer, well in this case is a migration for only 15 users, not Hybrid estimated at this time.
I just wanna know what happend with the emails received from the last sync of the migration job and the momento when you switch to office 365, of course you always try to make the switch closest moment of the last sync.
I set up the minimal hybrid option no matter how small the customer is–just so much easier.