Mitigating Risk during Office 365 Staged Migrations

There are really only three scenarios for an Office 365 Migration.   Only three (3)

  • Cutover
  • Staged
  • Hybrid

In the Cutover scenario you literally export all of the email and content on side a) (Exchange any version) and Import all of the email to side b) (Office 365).   Flip your MX records about and go.   Risk to this scenario is dependent upon the Window of DNS cutover time as you may have mail flowing to the old environment or your STOP mail flow period.  (I avoid this concept like a Star Trek fan avoids trying to explain the reason the Klingons looked different in the 60’s version vs the modern Klingons)

In the Hybrid scenario you are running an Exchange 2010 or Exchange 2013 environment, and a mailbox/trust is established with Office 365 and you can migrate up or down as you choose with mail flowing seamlessly.   If you have this setup, this is very nice with minimal risk since you can move test mailboxes up, verify connectivity and determine what needs to happen.

Then there is the Staged migration scenario only available and supported for Exchange 2003 and 2007 servers.   This takes a LITTLE bit of technical knowhow to setup (not a lot) but offers up and interesting alternative to the cutover.   It offers up a VERY low Risk migration if you can’t do a Hybrid configuration.

In this configuration Office 365 connects via Outlook Web Access from the On Prem environment and does an initial mirror of the entire mailbox.  It then establishes SMTP forwarding of inbound emails to the destination Office 365 mailbox to ensure emails sent to the old address forward to the new.

I’ve seen references online which state “After Migration is complete, you disable the Exchange mailbox, flip the user to Mail-enabled, then reconfig them to Office 365”

This is all well and fine but imagine a larger migration that takes over a week? 

Users that are in Office 365 can not communicate with users that are on premise (although they can receive).   Also what about your rollback strategy? 

I prefer not to break or change anything drastically in the old environment until I am 100% satisfied all is good.   More importantly if there is ANYTHING that is a deal breaker that we didn’t plan for, I need to be able to say with 100% conviction “All of your data from Exchange will be there Monday if something bad happens.”

Normally the configuration of Outlook for Office 365 is simple. 

  • Start Outlook
  • Outlook checks to see if this email is part of Exchange
  • Failing that it checks DNS to see if there is an Autodiscover record for it
  • It gets the info from Autodiscover
  • you get prompted for an ID and password for Office 365
  • It’s configured and AWAY YOU GO!

But if you’re in the “partially staged” setup and you need to configure some with Office 365 but can’t use their regular email address the answer is simple.   Set the Email address in Active Directory with the value of their onmicrosoft.com address.

Remember every single user in Office 365 has one.   What will happen then is Outlook see’s the onmicrosoft.com address, immediately gets the configuration for Office 365.  The user experience is still the same, login with your regular email address and your password.   All gets configured and working.

This provides you with an interesting option.  If the user NEEDS to communicate BACK to on-prem users, for that migration period they can still use the old Outlook Web Access to do so.

It also means for a “rollback” (which may not need to happen but you always play “What if) that nothing has actually been deleted.

There are other things to plan for I may talk about later, but the fact you can have BOTH mailboxes accesible DURING a staged Migration is pretty damned cool.

Also note that during your Staged Migration although MAIL will flow to the other side, changes to the local Calendar,Contacts,Notes and Tasks will not.   So if you have to rollback you must remember to export/import that data back.

Sean
The Energized Tech

Leave a Reply