Microsoft Office 365 tenant to tenant migrations have become a common exercise today.

The most common reasons for this are:

• A requirement to change the location of your data and / or your licensing rights.
• Mergers or divestitures meaning that you need to move users and content into a new tenant.

There are several tools that help with this task. Most of these tools copy the data from one tenant to another and then keep the source and destination copies of data in sync.

There are a few problems with these tools:

• The tools all result in an interruption of some sort to the user.
• Most of the tools need the users to rebuild their mail profile with their new UPN, primary SMTP address and re-synced OST content. This is a manual task that needs to be performed on every computer. This task normally needs to be done by an IT person.
• The automation tools that assist with the creation of new mail profiles need to be installed on every client computer, and these tools come at a much higher cost. They also have a bandwidth and end user experience implication as the users mail OST file still needs to be rebuilt.  

The question is, how am I going to migrate from one Office 365 tenant to another, without having to touch every computer in the environment?

The Conundrum Kicker

A migration of any sorts will always be judged by the end user experience. If we accomplish little to no disruption with our migration, we will make the IT team look like superheroes, especially when our users are aware of the need for a migration, but then when it actually happens, they notice little to no disruption.

We are going to discuss how we can use common technologies that we all have access to so that we can migrate from one Office 365 tenant to another, while making sure that our users smile all the way. This four-step guide will hopefully give you the confidence to plan around the manual tasks normally required with tenant to tenant migration and you too can become a superhero. 

Email has always been the central workspace for most. Yes, times are changing, and some workload is moving to applications such as Microsoft Teams, but we still live in a world where people get grumpy when they lose access to their email, even if it is for a short while.

Ensuring that email is migrated in a great way is already 80% of the battle won! So here is what we are going to do…

Step 1

We are going build a Microsoft Exchange hybrid mail environment between Office 365 and our on-premises servers (an Azure server can also be used for this, with some small mail routing caveats).  

We will then migrate the email from Office 365 to our Microsoft Exchange environment. This will temporarily switch our user’s mailboxes from Office 365 to Microsoft Exchange, without the need for profile recreation or visiting the user’s computer. The user might be prompted for a restart of Outlook, but even this disruption can be minimised by ensuring that all our client computers are on the latest version of Microsoft office. So, we have started off in the right direction and this is exactly what we want, migration without user disruption or without the need to visit or touch each client computer. 

Once all mailboxes have been migrated to Microsoft Exchange, we have completed step one.

*** Please think about a temporary backup strategy just in case the unthinkable happens before moving onto step number 2. Move into the next step without a backup at your own risk….

Step 2

Next, we are going to break or remove our AAD Connect relationship (otherwise known as directory synchronisation) from the old tenant. You will also need to remove the Hybrid mail configuration relationship between the old Office 365 tenant and the Microsoft Exchange environment. Please make sure that you change your MX records to deliver to your Microsoft Exchange environment before removing your Hybrid mail configuration.

Phew, now that we are done with that, we have one less service that is reliant on our current Office 365 tenant and we can start focusing on getting the rest of the services synced and moved.

Step 3

The next step is going to require the use of a migration tool. There are a few tools available that we can use for this, the choice and research into which tool will be left up to you. The goal is to migrate SharePoint and OneDrive content with full fidelity.

At the start of writing this blog, there were no tools capable of migrating the Teams set up and content with full fidelity because Microsoft hadn’t made the APIs available for this yet. Thank goodness it took me a while to write this blog! 😊

During the second week of January 2021, some of the migration tools started to include a Teams migration with full fidelity, which is obviously great news! A Teams migration without this is just messy, to say the least. Again, poor user experience reflects badly on your IT superheroes!

In this step, we are going to use one of these self-guided migration tools to create and mirror the same structure of data in the target tenant that exist in the source tenant. An initial copy of the data will be done to get the heavy lifting of data done in the backend. A delta sync of the content will be performed just before cutover.

Once the migration of this content is complete, you will be moving the domain name(s) from the old Office 365 tenant to the new.

*** It is probably a good idea at this stage to “force” a log out all users from the old tenant. A brief mail to all users asking them to log back into their Office 365 services (Teams, OneDrive and SharePoint) should be the worst of your user disruption (if things have been done properly).

Step 4

With your traditional Office 365 to Office 365 migration, everything must go live in the target tenant at the same time.

What we did in step one bought us some time for the most important and sensitive step of the migration, email. We managed to break the big bang approach up into two streams of migration, making sure the user experience is top notch and the chances of things going wrong are much less – gee, we really superheroes, aren’t we??

At this stage, we need to reconfigure AAD Connect and the Hybrid mail configuration into our new or target tenant.

***If the new or target tenant is not a brand-new tenant, and there was a previous AAD Connect relationship, there may be some object matching that needs to be done at this stage.

We are now going to migrate all our “on-premises” Microsoft Exchange homed mailboxes back to Office 365 and into our new tenant. Again, there is no need to visit each client computer as the hybrid migration process switches the mailbox location without the need for a new profile or a rebuild of the OST file. This all equals a great user experience!

Once all our mailboxes have been migrated back to Office 365 and into our new tenant, we can change our MX records to once again deliver straight into Office 365 and can proceed to decommission our Microsoft Exchange environment.

Step 4 is now complete and if all went well, we are officially a Superhero…

What about the “old” Office 365 tenant?

Once the migration is complete and all your users are happily working in the same Office 365 tenant, what do you do about the one you have just migrated out of?

You can keep the data in the source tenant (that you have just migrated out of) for as long as you like, by keeping the necessary Office 365 licensing in place. Remember, all your non mail related data hasn’t been moved to the new tenant, you have copied it. The situation with mail data is different due to our hybrid approach.

Once you remove the Office 365 license from the old tenant, all the data will be deleted within 30 days.

Want some advice or help?

Office 365 to Office 365 migrations are becoming common place, and just require a bit more thought and planning. 

We have successfully delivered many of these projects; it is our bread and butter so to speak.

If you would like to know more or you would like some help, please contact us for a discussion.