5 Considerations when moving to Exchange Online

So the decision has been made to move to Exchange Online. Your current Exchange on-premises solution is grinding to a halt and you want to us a cloud-based service. That’s fantastic news, and a decision I would fully support, but has everything been considered? Migrating to Exchange Online can be as easy as configuring a Hybrid connection with your Office 365 tenant and migrating the mailboxes. However, often it is not that simple. There could be years worth of on-premises Active Directory configuration and process that can trip you up as you start to migrate mailboxes.

Below are 5 considerations that I have encountered during migrations to Exchange Online:


Internet Connectivity

Exchange Online is a cloud-based service. This means that connectivity to user’s mailboxes will go out via your Internet connection and just across your LAN. Due to this your bandwidth utilisation will go up. How much so? That depends on how much data from the mailbox you cache locally on devices and how much email your users will send and receive. Microsoft do have a bandiwdth calculator available to help estimate this type of usage. The calculator can be found here. It is a fairly old calculator now, but it still provides a good estimation on the impact migrating to Exchange Online may have on your bandwidth. Should your bandwidth become saturated, the Exchange Online user experience can be poor. Slow loading times for Outlook, emails not being downloaded quickly, loading online mailboxes and search can all take a big hit and cause frustration for users trying to perform basic day to day tasks.

Equally important around your Internet Connectivity is how traffic to Exchange Online is routed out to the Internet. Many businesses will have a web proxy in place to filter web traffic and restrict access to sites that shouldn’t be accessed on company devices. Whilst web proxies have a place in your Internet setup, they can cause performance issues when accessing any Office 365 service, not just Exchange Online. The recommendation is to bypass the proxy for Office 365 related traffic, but this then means your Firewall must be configured to allow users out to the Internet directly. Which, in itself, causes more complexity. Ensuring that users can connect to Exchange Online without any performance hits is important, and I would fully recommend that if you have any devices managing connectivity to the Internet, contact the vendors to find out what they can do to make accessing Office 365 services easy. Many vendors now have built-in configurations for Office 365. It may be that a newer model is required, or maybe just a software update. But that conversation should be had to make your life easier during this migration.

Mailbox Permissions

It is important to understand how mailbox permissions work in a hybrid setup. The below is from Microsoft from their Exchange Hybrid documentation:

“Exchange hybrid deployments support the use of the Full Access and Send on Behalf Of permissions between mailboxes located in an on-premises Exchange organization and mailboxes located in Office 365. Additional steps are required for Send As permissions. Also, some additional configuration may be required to support cross-premises mailbox permissions depending on the version of Exchange installed in your on-premises organization.”

What this means, is that in a coexistence scenario Full Access and Send on Behalf Of permissions work cross-premises, whereas Send-As do not. For Send-As permissions to work post migration, both the mailbox granting permissions and the mailbox receiving permissions need to be migrated at the same time. If they are not, you may find that the permissions need to reapplied.

Another consideration with mailbox permissions is that any permissions assigned to objects that are not mail enabled, will not migrate to Exchange Online. An example of this I have seen a lot is where mailbox permissions are configured to AD Security Groups. Commonly, these groups are not mail-enabled and therefore, the permissions do not migrate to Exchange Online.

When migrating to Exchange Online I would advise reviewing your permissions structure so that it can assist with your scheduling for migrations but also gives an opportunity to refresh how permissions are applied and if it is now the best way to apply permissions on mailboxes in Exchange Online.


Groups are well used in Exchange. Distribution Groups have been used for years to send email to multiple users at once and as mentioned above, security groups have been used to manage permissions for mailboxes. There are several gotchas regarding groups when migrating to Exchange Online:

  • Distribution Groups synchronised from AD cannot be managed from a users mailbox in Exchange Online
  • Non Mail-Enabled Security Groups cannot be used to apply permissions on mailboxes in Exchange Online
  • Office 365 Groups cannot be used to apply permissions on mailboxes in Exchange Online
  • Office 365 Groups are not just for email distribution
  • Users can create Office 365 Groups by default
  • Office 365 Groups can be created in multiple locations, including the browser and the Outlook client

All of these points have caused customers I have worked with pain during their migration to Exchange Online and can easily be missed. They should be considered before migration to ensure user’s are not impacted and the right group is used for the right situation.

New Mailbox/Leavers Process

New Mailboxes/Leavers processes have generally been in use for years before Exchange Online and Azure AD is introduced. And with this introduction, these processes can change quite a bit. The following areas are worth a discussion point:

  • New mailboxes to be hosted in Exchange Online should be created as a Remote Mailbox in Exchange on-premises (if you have an Exchange Server remaining on-premises). Does your starters process need to change the PowerShell commands used? Are users licensed as soon as their remote mailbox is created?
  • Shared Mailboxes cannot be created as a Remote Mailbox from Exchange on-premises. Does this change your process? Is a shared mailbox the correct object for what the user wants anymore?
  • When a license is removed from a user (leaver) then their mailbox enters a 30-day countdown before it is deleted. Does this fit with your leavers process?
  • Once a mailbox is deleted (30 days after the license is removed), it cannot be restored. Do you need to retain data to meet compliance requirements? Are retention policies required?
  • Shared Mailboxes do not require a license, but if you need the data to be retained they need at least an Exchange Online Plan 2 license assigned. Does this impact your licensing budget?

All of the above questions, and more need to be asked and answered prior to a migration to Exchange Online. The last thing you want is to migrate all users, have an amazing success and then find out that your Service Desk have been using a legacy process and you now have a handful of mailboxes hosted in Exchange on-premises.

Other Office 365 Services

Exchange Online is just one service available within Office 365. For many organisations, Exchange Online is the first step. But if you have purchased an Office 365 E3 License for each user there are more services available. Have you considered SharePoint Online for document collaboration? How about Teams for further user collaboration, or Instant Messaging? Are you using Office 365 Pro Plus as your Office client?

There is a lot to consider once you make the jump to your first cloud-based service. Then there is the possibility of the Enterprise Mobility & Security suite which adds additional security to your Office 365 tenant and data plus includes Microsoft Intune for mobile device management. All of these services can be fit together to provide a wealthy cloud-based platform for your users to work from. Why consider all of this before you migrate your mailboxes, why not look at these services before and build a roadmap of your own?


These are 5 considerations I recommend making before migrating to Exchange Online. As I wrote this, I thought of more, but I have seen these 5 cause the most pain post migration. I fully recommend at least having a discussion around these points to ensure that they do not fly under the radar.

About the author