Understanding Microsoft 365 Tenant-to-Tenant Migrations
As organisations continue to grow and adapt, the requirement for tenant-to-tenant migrations becomes increasingly in demand. A Microsoft 365 tenant-to-tenant migration is the process of migrating workloads from one Microsoft 365 tenancy to another, which can involve the migration of one or many workloads and can include some or all content within a specific workload.
We have a strong record of delivering successful migrations and we have access to the right tools. Find out more about our M365 tenant-to-tenant migration offering here: https://www.intelogy.co.uk/microsoft-365-tenant-to-tenant-migration/
Why are tenant-to-tenant migrations required?
Below you will find some of the common reasons why an organisation may need to perform a tenant-to-tenant migration:
Acquisitions and mergers
An organisation may have been acquired by or merged with another, and this often requires them to migrate from an existing source tenant to an existing target tenant. In certain cases, you may find that instead of moving one tenancy into the other, they may instead opt to migrate both organisations into a new target tenant. This is common in circumstances where the conglomerate of the two organisations undergoes rebranding or if there are regulatory requirements associated with their merge.
When an organisation is subject to divestiture, and sections of the organisation are to be split away, this often results in a need to migrate select objects and content from an existing source tenant to a new target tenant.
During a rebranding exercise it might become a requirement to create a new tenant name to match the rebrand. This would typically involve migrating from an existing source tenant to a new target tenant.
An organisation may have to meet specific regulatory requirements that require them to migrate to a new tenant. In this case the organisation would migrate from an existing source tenant to a new target tenant.
What are the different approaches?
1. Single event migration
The single event migration approach involves migrating all users and workloads in a single cutover event. A cutover is the point in which a user or workload transitions to the target tenant, and typically involves a period of pre-agreed downtime.
If you have a substantial amount of data to migrate, it is important to consider performing a pre-stage migration when choosing this approach. In this case, the bulk of the data will be migrated ahead of the cutover, which helps to mitigate the amount of downtime necessary to complete the cutover as well as greatly reducing the quantity of data that needs to be moved during the cutover period.
This approach has the following advantages:
• It provides a consistent sign-in experience for all users
• Users will continue to use a single identity to access all workloads
• Users will only require licensing in both environments for a limited amount of time
• Planning and communication are less complicated
This approach has the following disadvantages:
• Puts all users and workloads at greater risk if something does not go to plan
• Downtime will affect all users and workloads at the same time
• You will need enough available resources to support the entire organisation post-cutover
2. Phased migration
The phased migration approach involves migrating selected users and workloads across multiple cutover events.
If you have a large user base or overall data size, a staged migration may be the better option. It will provide you with the flexibility needed to break the migration down into batches, allowing you to migrate selected users or workloads individually. For example, you could schedule the migration of the Exchange workload for one weekend, and the SharePoint or OneDrive workload for the next.
This approach has the following advantages:
• Lower overall risk as only specific workloads or groups of users are migrated at a time
• Provides greater flexibility
• Batches can be organised so that the amount of data migrated is manageable within the cutover window
• If any issues are encountered during the migration process, such as transfer throttling, it’s possible to mitigate and plan around these issues for the migration of future workloads
This approach has the following disadvantages:
• Users will often require duplicate licensing across the source and destination environments for extended durations
• Requires more planning and communication due to added complexity
• Users will need to sign-in with multiple identities for a period of time if you opt to batch by workload
• There may be limitations on what can be done in the destination environment until the migration is fully complete
What are the challenges of a tenant-to-tenant migration?
Below you will find some common challenges an organisation must overcome when performing a tenant-to-tenant migration:
Downtime is inevitable when performing a tenant-to-tenant migration and it is important to understand from the outset that a level of downtime will be required to support the migration. The length or number of services affected by downtime can be mitigated by using different migration approaches, for example using a staged migration will allow you to cutover workloads at separate times allowing for some workloads to be up and running whilst others are down.
Re-profiling of applications
Part of the tenant-to-tenant migration process involves users receiving a new identity, part of which means that they will need to re-profile applications such as Outlook, OneDrive, and Microsoft Teams. Tools can be used to aid the re-profiling of some applications such as Outlook, however it is key to provide clear and precise communication to users to guide them through the process as well as providing support for those that struggle.
Objects or containers exist across multiple sources
You will often find when an acquisition or merger occurs that a lot of departments and users will exist across both organisations. For the departments and users that do exist across both organisations you will need to consider how and if their mailboxes, OneDrive, Teams and sites will be merged. You will also need to advise users where to store documents and other resources in such a way as to support and work alongside the migration, and not result in data being lost or requiring re-migration.
You need to consider how you are going to handle the migration of duplicate department and user objects. For example, if a team called HR exists in both tenants and the plan is to have one HR department following the merger you will need to determine how the duplicate teams will be merged. It’s conceivable that if two businesses work in very different ways, the purpose of some identically named sites, accounts and mailboxes may not work in similar ways, and merging may therefore be inadvisable.
Likewise, people may have identities that exist across the directories of both organisations, making it important to contemplate what will be the primary identity post-migration and how will their Microsoft 365 resources be merged.
If you choose to perform a staged migration and opt to migrate workloads separately you undoubtedly will have some users that require access to multiple tenants for a period of time.
Requiring your users to access multiple tenants using multiple identities is a challenge, and it is key to provide clear communication to overcome this challenge. You will need to make sure that you make users aware of which tenant they should be using for which service and which identity they should be signing-in with.
From experience, one way to simplify this experience for users is by configuring multiple profiles within Microsoft Edge – one profile for each tenant they need to access. This enables them to easily switch between tenants and they can easily access the tenant and services required whilst using the correct identity.
Workloads without migration paths
Although there are now a number of reliable ways to migrate workloads within Microsoft 365, there are still several workloads that do not have tools or APIs available to migrate them. In these cases, it is important to review the workloads that can and cannot be migrated, whilst evaluating the amount of content within each workload. A lot of the workloads that do not have migration options available will need to be manually re-created, and therefore it is important to determine whether the effort required to re-create what exists in the workload is worthwhile; for some workloads, you may opt to manually migrate them, whereas others you may decide not to migrate.
What are the key components of a successful tenant-to-tenant migration?
One critical component towards a successful tenant-to-tenant migration is planning, as with the correct planning you can minimise the risk associated with performing migrations and improve the overall experience both for users and those responsible for coordinating the migration.
Below are some of the main points to consider when planning a migration:
• Make sure you have oversight of the existing tenancies, ideally via an inventory of the content and objects that make up the digital estate
• Review potential networking restrictions or bandwidth restraints on the organisation which may prevent the timely migration of data
• Consider the governance principles you would like to implement in the target tenant and factor these into the platform design
• Review the end user impact and factor this into a communication plan
• Think about the resourcing requirements to facilitate and support the migration
• Consider organisational deadlines and commitments to prevent scheduling critical phases when the organisation is busiest
Communication is vital to ensure that everyone involved is aware of what is going on and what may be required of them.
Below are some of the most important considerations when communicating the migration:
• If any actions are expected of users during the migration, it is important to provide them with clear and timely instructions on how to complete them
• Have early discussions with the organisation about any workloads or content that might not be included in the migration to gather feedback on unforeseen issues it might cause
• Highlight any limitations of the migration and clearly outline this to users with mitigation steps if possible
• Clearly outline all new ways of working
• Identify any department-specific requirements or issues that may impose complexities to the broader migration effort
It’s important to conduct enough research and select appropriate tooling to assist with the migration process.
Below we selected Intelogy’s preferred tools to assist when performing a Microsoft 365 tenant-to-tenant migration:
BitTitan MigrationWiz is a migration tool that focuses primarily on the migration of mailbox data and has proven to be a reliable tool for migrating mailbox content from source to target. This tool offers a user migration bundle, the purpose of which is to assist in the process of re-profiling a user’s Outlook via a specific tool. This can also be scheduled to trigger at the point of cutover.
ShareGate is a migration tool that is primarily focused on facilitating the migration of SharePoint and Microsoft Teams data. The tool has proven to be one of the most reliable of its kind and provides a rich feature set. Not only can the tool assist with the migration of data, but also has several great reporting capabilities to assist in the planning phase, as well as a number of administrative and analytics tools that can be used post-migration to maintain control of your governance plan.
A Microsoft 365 tenant-to-tenant migration can be a big undertaking but is sometimes a necessity, whether to merge organisations’ Microsoft 365 environments or in order to meet regulatory requirements. The key to achieving a successful tenant-to-tenant migration is ensuring correct planning, communication, and tooling. If you are interested in finding out more or require any additional guidance on M365 tenant-to-tenant migrations, please get in touch. We have a strong record of delivering successful migrations and we have access to the right tools. Find out more about our Microsoft 365 tenant-to-tenant migration offering here: https://www.intelogy.co.uk/microsoft-365-tenant-to-tenant-migration/