Back to blog

Office 365 Tenant to Tenant Migration: Step by Step

Nov 5, 2020 by Mike Weaver

Performing an Office 365 tenant to tenant migration is a huge undertaking, with multiple considerations for each workload.

As a leading vendor in this space, we’ve learned a lot along the way, and this step by step guide is designed to help you:

  • Define the problem and review the specifics for each workload
  • Study endpoint challenges, such as issues with mobile devices and user workstations
  • Prepare for the ‘Gotchas!’ that can throw you off course
  • Decide whether a Big Bang cutover or staged migration is right for you.

This 15-minute video and accompanying transcript should give you a great grounding in everything you need to know before embarking on a tenant to tenant migration.

Step by Step O365 Tenant Migration Guide

Let’s go back a few years and talk about the adoption of Office 365. When we first started adopting cloud technology, many of us had a lot of concerns over our tenant being in a shared service. In simple terms, we wanted to ensure the Coke recipe never ended up in the Pepsi tenant.

As time has gone on, we have accepted that these controls are in place. However, these same controls that keep tenants separate cause challenges, especially when we have a merger, acquisition, or divestiture, and we need to combine tenants.

As a result, migration options can be very limiting. Microsoft provides a couple of basic migration options but these programs – at the time of publication – are still in preview. Because of this, while we’ve been able to create robust solutions for the most common workloads for tenant to tenant migrations, it’s not a complete package, and there are challenges in this space.

If you’re familiar with on-prem migrations, you’ll see while some concepts are the same, there are still many differences between an on-prem migration and a tenant to tenant migration.

What are the challenges for the most common workloads?

Exchange Online

Let’s talk about Microsoft Exchange, the most common workload in Office 365, and likely to be the most mature workload that you face. Many of us have administered on-prem Exchange systems for years and may have even done a merger, acquisition, or divestiture project with Microsoft Exchange.

When we look at Exchange from a tenant to tenant migration perspective, we tend to see very, very large volumes. When doing on-prem migrations, we gave users small mailbox quotas, and that allowed us to speed up the migration because there wasn’t as much data, with even some of the most basic licenses including a 25 GB or 50 GB mailbox.

However, users don’t do clean up anymore, and as a result, the mailbox size keeps getting larger and larger and larger, and when we add in other challenges, like the SMTP domain only being able to be in one tenant at the same time, this can create some complications.

Exchange Online Tenant to Tenant Migration

Speed is essential, but so is function, and there are lots of other items that can form part of your needs in an Office 365 tenant to tenant migration for Exchange, including elements like permissions.

Check out our series on all the different permissions with Exchange where we cover delegate mailbox permissions from the full mailbox level, and also folder level permissions, which includes items like calendars.

Some aspects do not move. One good example is ‘client rules’, which can be challenging if organizations are heavily using them, so it’s essential to include this in your communications. However, with proper planning, the Exchange migration is usually the most mature and well-planned aspect of an Exchange Online migration.

OneDrive for Business

OneDrive has completely changed the way companies collaborate, both internally and externally. As a result, in an Office 365 tenant to tenant migration, the most significant impact isn’t the data move, but the actual sharing. These don’t typically migrate because, in many cases, you’re usually sharing with the company you’re moving to. This can be the biggest hurdle in planning and executing your OneDrive for Business migration.

The other aspect to keep in mind is that the data volumes can be quite large, so just as we highlighted in the Exchange section about not having mailbox limits with the default limit being 1 TB in some cases, users can have a lot of data here. When we add in all the different versions that the user can have, that can be a challenge. If you’re an organization that relies on versions, you also need to ensure that your solution supports those.

In terms of planning and executing the end-user communications and the permissions, please read this blog post for more information.

Microsoft Teams

Let’s move on and talk about Microsoft Teams, the adoption of which is probably one of the best success stories recently. With the COVID-19 pandemic, many organizations adopted it very quickly, and it’s transformed how businesses work: it’s our phone, our file storage, and how we collaborate internally and externally. It’s become a mainstay tool for all of us.

Office 365 tenant to tenant migration steps for Teams

However, in terms of tenant to tenant migrations, it can represent a significant obstacle. Microsoft has not yet provided many APIs for us to be able to migrate this data. As a result, some organizations may slow their adoption if they know they have to do a tenant to tenant migration soon.

For now, we can migrate by recreating the teams and channels. We can re-add the members, and we can migrate the channel chat. There are limitations to this API and how fast things can move, so this is one aspect – particularly with many remote workers – that requires careful planning.

SharePoint Online

SharePoint Online is a great way to collaborate and share documents with large groups of people. Many organizations have heavily adopted aspects of this over the years. Some of this started with on-prem SharePoint implementations that have been moved into Office 365.

A lot of people have been through a migration when they went from the on-prem SharePoint environment up into Office 365. A lot of the common Gotchas!’ and issues that you had in that migration remain today, even though we’re going from one tenant to the other and not shifting versions.

The SharePoint steps in your Office 365 tenant to tenant migration

One of the largest issues in the tenant to tenant migration space for SharePoint are custom applications and bespoke customizations. As your data migration vendor, we can pick up and migrate the data, but sometimes the views and some of those issues can be quite challenging. You may find if you have several applications running on top of SharePoint, necessitating a lot of mini-migration projects at once.

Using our Nova management platform, we identify who the owner of this application is, and who can help us with the migration and make that plan. In a lot of cases, we may execute the data migration with our toolset, and then an app owner will come in and do some light reconfiguration.

Still, the most common use cases of SharePoint are document libraries and basic pages – part of the standard Office 365 tenant to tenant migration product we provide.

Cloud Commander

Let’s talk about the Reconfiguration Agent for Cloud Command for tenant to tenant migrations.

It’s important, regardless of the tool you’re using. that your product will reconfigure all aspects of the Office install. This includes resetting the Office install if you’re doing click-to-run so the user gets a new license, but also resetting Microsoft Outlook, OneDrive for Business, and Teams, so the user can effectively be in their new tenant and up and running.

The Reconfiguration Agent we use in Tenant to Tenant Migrations

When you’re doing an Office 365 tenant to tenant migration, you want to practice this aspect as much as possible to limit those end-user impacts and get your documentation up-to-date so that your helpdesk can be there, ready to go.

Perhaps the number one helpdesk call during a tenant migration is around mobile devices. The reality is, they don’t have a great way to repoint the new tenant. This gets even more complicated when you’re moving the users UPN or the domain in the same weekend. The Outlook client on mobile devices does not handle this very well.

We’ve developed a guide for organizations to assist them with mobile device reconfiguration. We recommend distributing it to your end-users so you can avoid that helpdesk volume. Some organizations have even put in policies to bar people calling the helpdesk on Monday morning for mobile devices so that they can focus more on the PCs.

Plan for this aspect by understanding your users and their devices and projecting the impact on your projects so you can avoid this helpdesk volume.

Big Bang or Staged Cutover?

Come Monday morning, when deciding if you’re going to do a Big Bang cutover or a staged migration, there are a couple of things to look for, such as your domain makeup.

If you have a lot of domains, you can move them domain by domain. That could mitigate the risk, cutting the project down in a piecemeal fashion before moving the rest over. Best practice is to try to figure out if you have a quiet period in your business when you could do larger-risk items.

Weigh up the benefits of a big bang or staged cutover.

Talking about risk, you also must understand your organization’s appetite for it. When you do a tenant to tenant migration in stages, your risk is little bits of loss, productivity and organizations collaborating in the two tenants. The payoff of doing a Big Bang migration is everybody moves at once, but you could potentially put the entire business into a lousy configuration all at once.

If there’s a challenge with the project, you need to balance the pros and cons and decide what is right for you. We’re seeing most of our clients moving to a Big Bang cutover – even the larger organizations. It’s not uncommon for organizations with 15-25,000 users to still prefer a cutover migration.

Our record is 100,000 users in a single weekend, and we can attest – with proper planning – a Big Bang migration can work out for you, but again it must be the right decision for you.

Yammer

One big challenge is Yammer. For organizations that have a large adoption of Yammer, there are no APIs to support this kind of migration.

Steps to be aware of in a Yammer migration

Most organizations doing a Yammer migration must recreate everything on the other side. If you have certain discovery requirements, you may have to do an eDiscovery search on the source, collect all that data, and preserve it.

Be mindful that users won’t have access to it while you’re scoping your project, so look for Yammer usage and plan accordingly.

Power Apps & Stream

Some other challenges are Flow, Power Apps, and Stream. When we talk about those, there still aren’t migration options. For user-facing options, the only option is for users to actually document what they had and then recreat it on the other side.

Stream is a disappointment because a lot of organizations rely heavily on this data. So, to migrate that, the user has to download the video, download the metadata, and then re-upload it on the other side. The real shame with this method is that you’ll lose all the views and additional information – a real problem for organizations that have adopted it for their training needs.

Azure Active Directory

Another challenge and ‘Gotcha!’ for a tenant to tenant migration is Azure Active Directory, or just identities as a whole. We recommend you read this article: Office 365 Identity Management in Cross-Tenant Migrations.

The Azure AD steps of an O365 tenant migration

Another thing to keep in mind when you’re doing your migration is you may find things like Azure app registrations that are also in your tenant – tied to the domain. This is how deep you need to go with your application migration planning.

All the Azure workloads will require additional planning. In this post, we’ve focused on the Office 365 products, but as you expand out and look at your Azure tenant, you may find a whole bunch of usage challenges that come your way.

If you find that you have heavily adopted Azure workloads and a lot of applications, that’s going to be a massive part of your planning exercise as well.

Conclusion

Office 365 tenant to tenant migrations are typically the result of a merger, acquisition, or divestiture. At Quadrotech, we’ve produced a library of valuable content to support organizations going through these processes.

Many of the technical aspects covered in this post are more straightforward for organizations, but the ‘people factors’ can also present difficulties. This not only includes end-user communication templates and guides on how to assist users through this, but also guiding your IT organization and each other through this challenging transformation into your new company.

We hope you found this step by step Office 365 tenant migration guide useful. If you have any questions or you’d like to discuss an upcoming project, please contact our specialist team today.