The Top 6 Considerations for Migrating between Office 365 Tenants – Part One

Over the last decade, a growing number of organisations have either migrated from their on-premises infrastructure, or provisioned straight into the cloud-hosted, multi-tenant world of Office 365.

Unsurprisingly, a lot has changed in this time. Companies have grown, gone through mergers, acquisitions and divestitures, and new features have been released. The landscape today is unrecognisable compared to when organisations initially deployed Office 365. Naturally, the original setup has changed too.

Speaking from personal experience, international companies could create multiple tenants to keep data in the correct data residency, or because of performance concerns. With the introduction of Office 365 multi-geo, this is now less of a concern. And this is just one example of how the introduction of one feature could change a large portion of a tenant or service design.

These improving functionalities and increased number of Office 365 enabled businesses has led to a proliferation of companies moving between Office 365 tenants. There are many reasons for this:

• Consolidating legacy tenants that no longer need splitting
• Providing better user experience by being in a unified tenant
• Businesses acquiring and merging with other businesses that are already using Office 365
• Moving away into a new Office 365 tenant as part of a demerger

In this blog series, I’ll describe some of the key decisions and considerations you should think about before starting your tenant to tenant migration, and some useful insights to help you make the right decisions.

What needs to move between Office 365 Tenants?

This may be obvious, but the first task when undertaking any migration, and particularly when migrating between Office 365 tenants is identifying what needs to and can be migrated.

I recommend you start by listing your requirements for the migration using the MOSCoW method, or similar to help you choose the right tool for this project.

What can and can’t be migrated is primarily defined by the APIs published by Microsoft for access to services and their data.

SharePoint and OneDrive for Business have been used for many years and are commonly migrated apps. The APIs here are well understood by software vendors and there are now some very comprehensive solutions for moving and manipulating SharePoint data for a migration.

There are also options for migration without using a tool, such as getting users to sync their data with the old and then the new tenant. When embarking on a migration, your budget, the capability of your users, and the level of control will dictate which route you take.

Exchange is similar, however, there are still limitations to what you can move in a tenant to tenant migration. Emails and other data from within the mailbox are easy to move across, but permissions are not such a low bar. Not all third-party tools have developed the capability to migrate permissions, so be aware of your needs for sharing after migration, and ensure you select the right tool for the job.

Likewise, there is a “no tool” option for migrating Exchange Online content by exporting to PST and importing into the new mailbox. However, this will have a serious impact on things such as immutability and things such as “on-hold” data which will not be exportable to the user.

Microsoft Teams is obviously a newer member of the tool set. Teams’ APIs have only recently been released which can be used for a migration, but there are now options on the market for migrating Teams, Channels, Apps and Files associated. Again though, you must be cautious of what will be migrated and how by validating the content, and also in what way it’s moved using the APIs.

Something else to bear in mind is meeting recordings which are held in Microsoft Stream. There is not currently a migration API for Stream, so these would also be lost without manually downloading and re-uploading the data. Finally, like Exchange Online there will be content that may be deleted but protected using retention policies which may not be migrated, and this could be key in scenarios such as litigation, so be sure you know what you are and are not migrating.

Beyond those three key platforms there are wider Office 365 applications which are increasingly used across organisations, which only have limited solutions for migrating the data. Planner has limited migration APIs, but some limited data migration is possible.

PowerApps and Power Automate, however, have no migration APIs, so you will need to educate your users on how to manually export and import their solutions across to the new tenant. I have already mentioned the lack of a migration API for Microsoft Stream, and PowerBI will also need you to export your solutions and recreate them in the target tenant.

Then there will be services without data that you need to consider, such as Microsoft Information Protection which applies labels to and protects your documents. You will need to carefully consider the impact of moving protected content across tenants which is being used by new identities. You’ll also need to consider how a different classification or protection scheme in the new tenant could affect migrated documents. Or, if they’ll even be accessible after a migration, depending on what protection you apply and how you intend to migrate. Here, you will have to remove all protection before migration and then reapply the same once the data has moved.

Also don’t forget the years of configuration that may have gone in to things like your Exchange Online Protection configuration, policies in the Security and Compliance Center for retention and DLP and similar, all of which have no API to copy them across and you will be required to recreate all of that configuration manually – no easy task.

All of this goes to show that moving across tenants is about far more than just copying and pasting some emails and files, and you need to ensure you are aware of everything that should be copied across, including configuration settings, and then proactively check it has been migrated and behaves as you expect after your migration has been completed.

Join me in the second part of this series, which will be released tomorrow where I’ll be discussing the challenges you may experience with domains and identity creation and management.