How To Complete a Successful Tenant to Tenant Migration

For organizations considering a tenant-to-tenant migration, there are a lot of technical and business factors to review. In working with CDW customers we’ve found that these conversations between IT and business stakeholders can sometimes stall when both teams struggle to articulate the goals and challenges the project may have. 

This is part 2 of a tenant to tenant conversation and will focus on what to expect during the tenant cutover and some decisions that should be made to support the effort. Part 1 focused on describing what Microsoft 365 tenant is and reasons you might be considering a tenant-to-tenant migration. 

Keep in mind this is based on our most common customer experiences, and your specific scenario and environment may require a slightly different migration path. However, the defined decision points should remain valid. As you will learn, these migrations are challenging, costly and disruptive. If you take away nothing else, know that this migration shouldn’t be undertaken without a clear objective and careful consideration.

To address the elephant in the room briefly, tenant to tenant migrations typically have a large business impact and will likely include significant downtime for every transitioning user, a lot of manpower from IT team members, and there will be some data that cannot be transitioned to the target tenant.

Microsoft regularly adds new services and features to their products, and the Microsoft native or 3rd party migration tools used to migrate these services frequently lag. As a result, there are several known features/services that either cannot be migrated today or cannot be migrated without great time commitment and cost:

• Microsoft Teams Shared Channels
• Microsoft Forms
• Bookings
• Shifts
• Yammer
• Power Platform

Tenant-to-tenant migration steps focus on moving user accounts, shared resources and data between two M365 tenants. Tenant migrations are typically broken down into phases that will eventually lead to migrating users being fully operational in the target tenant:

• Target tenant preparation
• Data prestaging migration
• Cutover
• Day 1 support
• Source tenant cleanup

Most of the user-impacting tasks and business interruptions will happen during the cutover phase.  Careful planning and clear business requirements can go a long way to limiting the impact on the business.

As the users and data move into the new environment, careful planning is required to ensure that the user experience, security and compliance settings are set correctly to avoid data loss or leakage. During this phase, changes to the target environment such as these may be required:

• Target tenant settings might be changed.
• New user accounts and mailboxes are created in the target environment.
• Users are typically unaware these accounts have been created.
• Adding new users and resources to the migration once this phase starts adds complexity.
• Once this phase starts, keeping changes to a minimum is advised.

This stage requires both careful planning and execution and is highly dependent on the target tenant preparation phase. Ideally, shortly after the new accounts are created in the target environment, data can start being prestaged. The longer the delay between the steps the more likely changes (name changes, new hires, etc.) are required, which can lead to lots of one-off changes and increase the likelihood of making mistakes. Once data starts moving to the new environment, much of this phase is tracking the data migrations progress, reviewing migration logs and a whole lot of waiting. Here’s what to expect:

• Data might be migrated with a 3rd party service
• Data will be copied to the target environment to make sure as much data as possible is available for users right after the cutover. For example, if you have a 150 GB mailbox it might only be possible to migrate 50 GBs a day.
• Data isn't removed from the source environment, and users can continue to use it normally.
• Migrated data becomes available in the target, but users probably won't be using the content to avoid confusion and potential versioning conflicts.
• Once this phase starts, large changes to data structure should be avoided if possible. For example, if a user deletes a large amount of data from their mailbox after the prestaging migration has been completed, they will retain a copy of that email in the target environment and may need to repeat that cleanup effort.
• Not every M365 service supports prestaging data. For some services all of the data will need to be migrated during the cutover window.

Cutovers are typically scheduled for a weekend with the business typically instructed not to log into or leverage the tenant for that entire weekend. These cutovers have the extended IT team teed up and ready to roll at the end of the business day Friday and typically have active tasks completed late into the night. Things to expect:

• Communications to end users and the business should be drafted, tested and circulated to all users in preparation for the cutover task.
• Potential M365 outage that can last from a few hours or a day or two. Incoming email may not be delayed or might be undeliverable and need to be resent during this time, and users may not be able to log into M365 on either the source or target environment.
• Run a delta migration on all migrating resources to get the latest emails and file versions. Certain services that don't support data prestaging may take a few days or weeks to fully migrate content.
• User participation is required during this phase. Users may be asked to do some or all of the following after the outage window:
  1. Log out and log into Office apps on their phone and workstations
  2. Delete and recreate certain calendar meetings
  3. Leverage a new username and password
  4. Reshare previously shared documents
  5. Invite certain members and guests to Teams and SharePoint sites
  6. Closing and reopening OneNote files
• Users are typically moved in large batches (sometimes even the entire company) leading to a lot of users having issues the first few days after the cutover. Make sure that the project team and business are prepared to spend a large amount of time getting users back up and running.
• Vanity domains can be transferred between tenants during this phase.

After a cutover window expect a lot of your users to need help getting back up and running on their first day back in the office (and maybe even before) once the cutover has been completed. It is not uncommon for our customers to try and find ways to supplement their frontline support staff to make sure that there are enough team members manning the phones and walking end users through questions and issues.

This stage typically takes place a week or two after the cutover to give users and IT a chance to recover from the heavy cutover activities and migrate any content that was missed in the previous phases. Previous project phases are focused on getting copies of data into the target tenant. This is great because we can always go back to the source and grab any data that was missed. If for business or legal reasons the data transitioned to the target tenant should no longer exist in the source environment, that content will need to be identified and deleted in the source tenant. Depending on the goals of your migration this phase may not be necessary.

A tenant-to-tenant migration is a huge undertaking for both IT and the business with a lot of potential and branching paths forward. The decisions made early in this process have a huge impact on both the path and level of effort, so CDW recommends that business leaders clearly define their business objectives and be willing to adjust the plan when required.

In addition to the high level business objective, here is a list of decision points to outline before the migration planning starts:

• What tenant is going to be the target tenant? If the target is already being used by another group, do the governance, compliance and security policies of the two orgs align? Are we going to need to review/redesign the design of the target before moving content? What admin access is the team who manages the source tenant going to get in the new tenant?
• Is the domain (cdw.com, ACME.com) going to change for users as they move to the new tenant? If email addresses change, how soon will users need receive email at the new address, and how soon will users need to send email at the new address?
  
• Do we need to keep all of the historical data and workflows? Consider:
  
  1. Email
  2. OneDrive files
  3. Teams and SharePoint sites
  4. Teams private chat messages
  5. Microsoft Teams channel messages
  6. Meeting recordings
  7. Power apps
  8. Power automate
  9. Power BI
• What should happen to the old accounts and data after the migration? Are there are any active users in the old tenant that should or shouldn't have access to this content? For example, the company is splitting and there is an HR team with data in it. What data should be copied to the new tenant? What data should be left behind? Is there any data left after the cutover that should be deleted from the source?
  
• Is there a team that cannot be offline for a cutover weekend? What are the minimum actions needed to perform during any outage window?
  
• What team is going to manage the user accounts and resources in the target environment? Does that team have the skillsets and staff members required to execute and support this migration?
  
• What are the plans to support end user devices during this transition? What team will be managing these devices? 
  
• What are the plans to support the AD environment and datacenter? What team is going to support these resources? Do these resources need to migrate?
  
• Do you have any servers or services supported in Microsoft Azure? What team will support these resources? Do these resources need to migrate?
  
• What business applications rely on the current M365 tenant? What service do they provide your users? Which of these applications will be required in the new M365 tenant?  For example, do your users navigate Zoom, but use Azure AD for SSO? Or perhaps there might be a connector to SalesForce to make sure all emails are tracked in your CRM system?
  

If a tenant-to-tenant migration remains the right choice for your business, I highly recommend you compile the information above and reach out to a professional services team to assist with your migration. Again, this content was put together based on common customer experiences, but there is quite a bit of variance from project to project in how these projects are tackled. With a project this complex and with such a high potential for negative business impact, it is critical to bring in the right expertise to execute on the migration and help you plan for supporting the environment beyond.

Story by Ryan Bandel, a Technical Architect focused on Microsoft Collaboration on the Services R&D team at CDW.