Asked by:

Office 365 Migration Options - A Way to Stage Migration

Question

I've been looking into migrating our on-prem Exchange 2013 server to our Office 365 tenancy for a while now, but I'm not happy with the two options I'm given - Cutover or Hybrid.

We're looking at a little over 100 mailboxes totalling around 500Gb worth of data. I want to get this running on Exhange Online with minimal disruption to the users, but I also want to migrate completely if I can, removing my on-prem server when I'm
done.

A hybrid deployment would be non-disruptive but you pay the price for that by having to maintain your hybrid on-prem exchange server forever even if it has no mailboxes on it. This makes no sense if the aim is to migrate completely.

Cutover is a terrible solution.There's no way we could migrate all mailboxes in a time when the users wont notice, and what's more to change them from on-prem to 365 we'd have to reset all their Outlook profiles, which means helping them setup Outlook again
(as simple as the setup wizard is, many would need help with this), it also blows away signatures and other settings in the process. It would do this to all users at once, this is just too disruptive.

We're doing device refreshes for our users soon, where we have to change each user over to a new PC, so it's really disappointing that there used to be a staged migration option but it's no longer available to our Exchange 2013 server. So I'm pondering
whether I can make up my own simple staged migration that allows us to control when users switch to 365, wherein we can move them to 365 as we upgrade their PC.

As we refresh a user's PC, forward their on-prem Exchange 2013 mailbox to their onmicrosoft.com 365 email address using Set-Mailbox <Identity> -ForwardingsmtpAddress <address>.

Move their mailbox to Exchange online (please tell me there's a way to do this that's not PST export/import related)

Switch Outlook to 365 during the refresh as well (users will have to setup applications on their new PC at this time anyway).

Work through all the users in small groups using this process.

When complete, switch the MX records for our domain from the on-prem infrastructure to 365.

Decommission on-prem Exchange.

So, I guess what I'm wanting to know is will this even work? The use of -ForwardingsmtpAddress worries me, as will this affect internal mail at all? If not, can I use -ForwardingAddress to redirect mail to 365 or does this only work for internal
mail? Or, can someone suggest a more elegant approach to effectively stage a 2013 migration and allow me to remove my on-prem server when I'm done?

All replies

If you intend to use Azure AD Connect to synchronize your on-premises directory with Azure AD and Office 365, then the only supported method to do recipient management is with an on-premises Exchange server. That server doesn't consume a lot of resources
nor do you need to pay for a license since you can obtain a free hybrid license. I'm not going to answer the specific questions that follow because they're moot, and you're really overthinking things and probably making this whole thing way more
complicated than it should be.

Let me add that you can tear down a hybrid configuration when you're done, if you know what you're doing. Creating a hybrid is not necessarily a lifetime commitment.

If you set up a hybrid configuration or otherwise have bidirectional mail flow, you can move your MX record whenever you want.

You don't want to move your Autodiscover record until you no longer have on-premises mailboxes that require Autodiscover for client connectivity.

I don't understand the purpose of the server you propose for your DR location.

You can block port 443 if you don't need to move mailboxes. You can block 25 if you don't have any mail flow to the cloud. Consider how you'd deal with any on-premises document scanners or SMTP sending hosts in that situation.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.