Since June 2011, Office 365 has been the destination for many Exchange, Skype for Business and SharePoint migration projects. Depending on the range of estimates, somewhere between 20-50% of all Exchange mailboxes are currently run from Exchange Online in Office 365.
Moving your organization’s Exchange, Skype for Business and SharePoint services to Office 365 solves a lot of problems, but it can also create complications. One problem that Office 365 makes more difficult is getting your data out of the service, or re-configuring your data to another tenant within Office 365.
Recently, I’ve seen more organizations needing tenant to tenant migration within Office 365. The reasons for these migrations vary, but tenant to tenant migrations requires considerable planning and a good understanding of what you will and will not get from Microsoft in terms of assistance.
Deciding whether your organization needs a tenant to tenant migration is the biggest hurdle. I’ve worked with customers who had good and bad reasons for doing tenant to tenant migrations. Let’s go though some of the more popular reasons and considerations to help you decide if it’s right for your organization.
Data Localization
Some organizations have compliance regulations they must conform to. When organizations operate in multiple countries, compliancy can be much more difficult. For example, Germany and Russia require that data used by employees in their countries must be kept there. If your organization has offices in Germany, you might need to host those users Office 365 services on servers inside of Germany.
Currently, all Office 365 tenants are limited to a single region (expect for a few organizations involved in multi-region tenant testing). If your organization observes data localization rules, you may be forced to maintain multiple Office 365 tenants.
Microsoft understands that some organizations need the ability to localize specific users within an Office 365 tenant, and are working to bring that functionality to everyone. I don’t have any information about when that functionality might be available, or for what services it will be available for first. You’ll have to make your own decision if it’s a good reason to migrate some users to a separate localized tenant.
Divestitures
Sometimes business sell off divisions or groups. When an organization sells off business units, it can be necessary to move data for the people involved to a new Office 365 tenant. Since there aren’t many decisions that apply to your user’s data in this situation, I won’t spend a lot of time talking about it.
Acquisitions
The opposite end of a divestiture is an acquisition. With acquisitions, there are several factors to consider. If the new data is part of a larger Office 365 tenant that will continue to be used by the selling organization, then you may need to do a tenant to tenant migration. If your organization is acquiring an entire organization, it may not be necessary. You may also be able to keep users from the acquisition operation with their own separate Office 365 tenant. While this presents its own challenges, it could solve some problems too.
A key consideration in deciding to do a tenant to tenant Office 365 migration is identifying what data your organization needs moved.
While your focus might be email when you start to think about doing a tenant to tenant migration, there is a lot of other data in your Office 365 tenant that has nothing to do with email. Skype for Business, SharePoint, Delve, Yammer, One Drive for Business, Teams, Groups, Azure AD and other applications all hold information that could be important to your organization.
Migrating mailbox data from one tenant to another is easy. SharePoint and Skype for Business data isn’t difficult to migrate. It’s with “everything else” that problems arise. Some data cannot be migrated — as far as I know, there is no way to migrate Yammer data. Other data can’t be migrated in its current format. For example, files saved in your Groups can be migrated, but the Groups themselves cannot be migrated.
I don’t have the space to go over every type of data and what can and cannot be migrated in-depth. Before you start an Office 365 tenant to tenant migration, spend some time figuring out what data you have in Office 365, and if you can migrate it or not.
If your organization is doing tenant to tenant migration because of data localization requirements, you’ll have to manage two separate Office 365 tenants for the same organization.
Depending on how closely your users work together, this could cause issues. Does your organization need a unified GAL? What does “unified GAL” even mean?
Creating mail contacts for all mailboxes in tenant A to show in the GAL for tenant B is easy with PowerShell. If that fits your end user’s definition of “unified GAL,” then you’re golden. What about distribution lists? Groups? Conference rooms? When the management team says they need a unified GAL, it’s important to define exactly what that means.
Groups allows users outside of your tenant to access some of the features provided by that tenant feature. Make sure everyone understands what level of participation they have for resources housed outside of their home tenant before embarking on a tenant to tenant migration.
An Office 365 tenant to tenant migration is a complex and frustrating experience. I recommend you look at every other alternative before starting this type of migration.
If you do need to do a tenant to tenant migration, good planning and defining your final goals are critical. Make sure all parties understand what data and features are going to be available to each set of users. If the management team expects Yammer data to be migrated, you’ll need to manage expectations and set goals before you get started.
Hopefully as Office 365 matures, Microsoft will be able to provide a “tenant splitting” or “tenant combining” service. Until that’s option, you’re going to have to rely on good planning when you run into these circumstances.