Tenant-to-Tenant Migration: The Enterprise Guide for Mergers, Acquisitions & Divestitures

When Tenant-to-Tenant Migration Is Required

Microsoft 365 tenant-to-tenant migration is a challenging IT task for any enterprise. This process differs from a standard cloud migration. It requires transferring data between two instances of the same platform.

Each instance has:

• Its own identity system
• Distinct security policies
• Unique compliance configurations
• Separate user data

The stakes are high during this migration. Any disruption can directly affect:

• Employee productivity
• Email delivery
• Business operations

The most common scenarios that trigger tenant-to-tenant migration fall into three categories, each with distinct technical and organizational challenges that require different approaches to planning and execution.

Mergers and Acquisitions

When two organizations merge, they often need to combine into a single Microsoft 365 tenant. This helps achieve:

• Unified identity management
• Consolidated licensing costs
• Seamless collaboration without external sharing issues
• Integrated security and compliance policies

Typically, the tenant of the acquiring organization is the target. The users, data, and settings from the acquired organization transfer into it. This situation is common, but it can be complex. It involves merging two active environments that have:

• Different user accounts
• Distinct data sets
• Unique settings and configurations

• Different configurations
• Distinct policies
• Varied naming conventions
• Diverse organizational cultures

M&A migrations make up about 70% of all tenant-to-tenant migrations. These migrations also face additional pressure from:

• Deal timelines
• Transitional service agreement (TSA) deadlines

These factors can limit the migration schedule.

Divestitures and Spin-offs

When an organization sells a business unit, it must remove the departing users and their data from the parent tenant. This data can be moved to a new or existing tenant. Divestitures present challenges, as the divested entity often requires access to shared resources during the transition.

Moreover, data separation must comply with legal and regulatory requirements. This ensures a clean separation of:

• Intellectual property
• Customer data

• Transitional service agreements define the coexistence period and shared service boundaries.
• This period typically lasts 6-18 months.
• The parent organization must ensure that departing users take only the data they are entitled to.
• All data belonging to the continuing entity must be retained.

Rebranding and Restructuring

Organizations that are rebranding often prefer to migrate to a new tenant instead of renaming their existing one. This approach is useful in several situations:

• When the domain namespace changes significantly and the organization wants to eliminate old domain associations.
• When the organization seeks a clean tenant free from years of legacy configurations, policies, and technical debt.
• When regulatory requirements necessitate separation from the previous entity, such as a regulated subsidiary needing independence from a parent company.

Identity Merging: The Foundation of Every Migration

Identity is the foundation of the Microsoft 365 tenant. It is essential to prepare identity before migrating any workloads. If identity is not configured correctly, it can cause issues in later migration phases. Every Microsoft 365 service depends on the identity layer for:

• Authentication
• Authorization
• Access control

Azure AD (Entra ID) Assessment

Start with a thorough assessment of both source and target directories. Document all user accounts, including:

• Active users
• Disabled accounts
• Shared mailbox accounts
• Room and resource accounts
• Service accounts
• Guest accounts

Map the group structures and membership for security groups and distribution lists. Identify any naming conventions that might lead to conflicts.

Additionally, catalog custom attributes and directory extensions that hold important business data. Review the following items in both tenants:

• Conditional access policies
• Application registrations
• Service principals
• Administrative role assignments

Before migration starts, it is crucial to identify and resolve identity conflicts. Common issues include:

• UPN (User Principal Name) collisions: Users in both tenants may have the same username format.
• Proxy address conflicts: Email aliases may exist in both directories.
• Group name collisions: These can prevent the migration of distribution lists and security groups.
• Attribute conflicts: The same custom attribute may be used for different purposes in each tenant.

EPC Group employs automated assessment tools to scan both directories. They produce a conflict resolution report within the first two weeks of any migration engagement.

Cross-Tenant Synchronization

Microsoft's cross-tenant synchronization feature allows organizations to automatically create and manage user accounts across different tenants. This feature is crucial during the coexistence period. It ensures that:

• Users in the source tenant can access resources in the target tenant.
• Users in the target tenant can access resources in the source tenant.

Cross-tenant sync creates external member accounts in the target tenant. These accounts maintain the user's identity attributes, which enables seamless access to:

• Shared Teams channels
• SharePoint sites
• Other collaborative resources during the migration window

The synchronization is bidirectional. It supports attribute mapping, scoping filters, and provisioning rules. These features control which users are synchronized and what attributes are maintained.

Multi-Forest Active Directory Considerations

Organizations that use on-premises Active Directory forests face extra challenges. If both organizations have their own forests synced to different tenants, the target environment must be ready for synchronization from both forests during the transition.

To manage the merged directory, configure Azure AD Connect or Azure AD Cloud Sync. This setup requires:

• Conflict resolution rules
• OU filtering
• Attribute mapping that fits both organizational structures

After migration, the source forest is usually decommissioned or changed into a resource forest. Organizations that use hybrid Exchange must coordinate on-premises directory changes with cloud mailbox migration. This coordination is essential to avoid mail routing failures during the transition.

Domain Transfer and DNS Cutover

Domain transfer is a crucial and time-sensitive step in tenant-to-tenant migration. When a domain shifts from the source tenant to the target tenant, email routing changes for all users on that domain. This process needs careful planning and precise execution.

Remember that:

• A custom domain can only exist in one Microsoft 365 tenant at a time.

The domain transfer process has a clear sequence. First, all user accounts in the source tenant must update their UPN and email addresses.

They should change these to either the source tenant's onmicrosoft.com domain or another domain.

The custom domain cannot be removed from the source tenant if any object references it. This includes:

• Users
• Groups
• Distribution lists
• Application registrations

Next, follow these steps:

• Remove the custom domain from the source tenant after clearing all references.
• Add the custom domain to the target tenant and verify it using DNS TXT record verification.
• Update MX records to point to the target tenant's Exchange Online.
• Update SPF, DKIM, and DMARC records for the target tenant to ensure email authentication continues working.
• Assign the migrated domain to users in the target tenant for their UPN and email addresses.

This process can disrupt email delivery while DNS records update worldwide. Careful scheduling helps minimize this disruption.

EPC Group reduces the risk of DNS propagation by:

• Lowering TTL values to 5 minutes at least 48 hours before the cutover.
• Executing domain transfers during weekend maintenance windows when email volume is lowest.
• Maintaining email forwarding rules as a safety net for messages delivered to either tenant during propagation.
• Monitoring MX record propagation across major DNS resolvers globally to confirm a successful cutover.

The entire process usually takes 4-12 hours, depending on the number of domains and DNS propagation speed across the organization’s global footprint.

Mailbox Migration: Exchange Online Cross-Tenant

Microsoft's cross-tenant mailbox migration feature allows for the transfer of mailboxes between tenants while maintaining full fidelity. This includes all mailbox content such as:

• Email
• Calendar items
• Contacts
• Tasks
• Notes
• Folder structure

The migration process uses background synchronization. This method copies data incrementally over several sync passes. Finally, a cutover switches the mailbox to the target tenant with minimal downtime.

Migration Batch Strategy

Enterprise migrations should be done in planned batches. Migrating all mailboxes at once can lead to issues such as bandwidth saturation, overwhelmed help desk resources, and increased risks.

When planning batches, consider the following:

• Department groupings: Keep teams together to ensure collaboration.
• Mailbox size distribution: Balance batch throughput to avoid bottlenecks from users with 50GB+ mailboxes.
• VIP and executive users: Provide white-glove migration with extra testing and same-day validation.
• Shared and resource mailboxes: Ensure these are available in the target tenant before or during user migration.
• Compliance considerations: Maintain litigation hold and eDiscovery requirements throughout the migration.

A migration for 10,000 users usually occurs in 8 to 15 batches over a period of 4 to 8 weeks. Each batch involves several key steps:

• Pre-migration validation: This step confirms user readiness and resolves any outstanding issues.
• Migration execution: This takes place during off-hours to reduce the impact on production traffic.
• Post-migration testing: This verifies mail flow, calendar sharing, and delegate access.
• User communication: Help desk preparation is in place to quickly address any user-reported issues.

EPC Group conducts migration batches during off-hours and weekends. They provide 24/7 support during cutover windows and same-day help desk assistance for each batch.

Outlook Profile and Client Impact

After mailbox migration, users need to reconfigure their Outlook profile. For most users with modern Outlook versions, this process is handled automatically by Autodiscover. However, organizations should prepare for manual profile recreation in some cases.

• Autodiscover fails or users have older Outlook versions.
• Re-authentication prompts with target tenant credentials may confuse users.
• OST file recreation can temporarily slow Outlook synchronization.
• Delegate and shared mailbox reconfiguration is necessary, as permissions must be re-established.
• Outlook mobile app re-authentication requires users to sign in with new credentials.

Clear communication with step-by-step instructions can reduce support needs during this transition. EPC Group offers migration communication templates tailored for each batch.

These templates include:

• Specific instructions for users
• Guidance on the migration process
• Support resources for affected individuals

SharePoint and OneDrive Content Migration

SharePoint content migration is often the largest component of a tenant-to-tenant migration. OneDrive for Business data transfers per user along with mailboxes. However, migrating SharePoint sites requires careful planning and execution. This includes:

• Document libraries
• Lists
• Associated metadata

Content Assessment and Inventory

Before migrating SharePoint content, conduct a thorough assessment. This should include the following:

• Total data volume across all site collections and libraries.
• Site collection inventory with owner identification and last activity dates.
• Custom solutions, including SPFx web parts, workflows, and any legacy InfoPath forms that need remediation.
• External sharing configurations and active guest access that must be maintained or terminated.
• Content types and managed metadata term stores that need to be recreated in the target tenant.
• Search configuration, including custom result sources, managed properties, and search schema customizations.
• Retention labels and compliance policies applied to sites that must be maintained post-migration.

Migration Tools and Approach

SharePoint migration tools help manage different parts of the migration process. Key tools include:

• Microsoft's SharePoint Migration Tool (SPMT)
• ShareGate
• AvePoint

These tools handle site structure, document libraries, list data, permissions, and metadata. However, some elements require special attention and cannot be fully automated.

• Managed metadata term stores: These must be recreated in the target tenant before migration. If not configured properly, documents with managed metadata columns will lose their values.
• Content type hubs: These need to be reestablished with matching content type definitions.
• Custom SPFx solutions: Redeployment in the target tenant's app catalog is necessary. Code changes may be required if they reference tenant-specific endpoints.
• Power Automate workflows: These must be recreated and reconnected to the migrated content.
• Site-level permissions: Remapping from source tenant identities to target tenant identities is essential. This requires identity mapping prepared during the identity merging phase.

Teams Migration Strategy

Microsoft Teams migration is often seen as the most challenging aspect of tenant-to-tenant migration. This is because Teams is not just a single workload. It serves as an integration layer that connects various services:

• Chat
• Meetings
• File sharing
• Collaboration tools

• SharePoint
• OneDrive
• Exchange

• Exchange for chat and calendar
• SharePoint for file storage
• OneDrive for personal file sharing
• A variety of third-party applications through tabs, connectors, and bots

To migrate Teams successfully, you must coordinate across all these underlying services at the same time.

The recommended approach involves several key steps for a successful migration. These include:

• Migrating team structures and channel configurations using the Microsoft Graph API or third-party tools.
• Transferring channel files stored in the underlying SharePoint site during the SharePoint migration phase.
• Accepting limitations on one-to-one and group chat history, which cannot be fully migrated. This history should be archived for compliance before decommissioning the source tenant.
• Recreating Teams apps, tabs, and connectors in the target tenant, as these are configured per team and reference tenant-specific application registrations.
• Migrating Teams phone system configurations, including call queues, auto-attendants, calling policies, and phone number assignments, which require coordination with the telephony provider.
• Re-establishing Teams meeting policies, compliance recording configurations, and guest access policies in the target tenant to match or improve upon the source tenant configuration.

Intune Policy Migration

Organizations using Microsoft Intune for endpoint management need to rebuild their device management setup in the target tenant. This is because Intune configurations do not transfer between tenants.

To recreate the setup, you can use:

• Documentation
• Exported configuration files

• Device compliance policies: Define what makes a device compliant.
• Device configuration profiles: Push settings to managed devices.
• App protection policies: Secure data in managed applications on BYOD devices.
• Conditional access policies: Integrate with Entra ID for access control.
• Windows Autopilot deployment profiles: Enable zero-touch device provisioning.
• Application deployment packages: For line-of-business and standard applications.

EPC Group uses Intune configuration export tools and infrastructure-as-code methods to accelerate policy recreation.

However, it is essential to validate each policy in the target environment before re-enrolling devices.

Device re-enrollment is the most disruptive part of the Intune migration for end users. This process typically involves:

• A device wipe and re-enrollment through Autopilot
• A manual un-enrollment and re-enrollment process

Both methods remove management policies from the device for a short time. Proper sequencing is essential for success. It ensures that devices are re-enrolled after the user's identity and mailbox have migrated. This approach reduces disruptions for each user.

Coexistence Period: Keeping Business Running

The coexistence period is when users work in both tenants. During this time, both environments need to function well together for daily tasks. This phase typically lasts 2 to 4 months for large enterprises.

To ensure business continuity across all collaboration workloads, specific configurations are necessary. These include:

• Maintaining user access
• Ensuring data integrity
• Facilitating communication between platforms

• Mail flow coexistence: Transport rules forward mail between tenants so users receive messages regardless of their current mailbox location. Forwarding rules are configured bidirectionally and updated as each migration batch completes
• Free/busy coexistence: Organization relationships between tenants enable calendar free/busy sharing across the migration boundary so users can schedule meetings with colleagues regardless of which tenant hosts their mailbox
• Teams federation: Cross-tenant access policies enable Teams chat and meeting between users in source and target tenants, maintaining real-time communication throughout the migration
• SharePoint access: Cross-tenant synchronization and B2B guest access enable continued access to shared sites and document libraries during the migration period
• Application access: Conditional access policies in both tenants must accommodate users authenticating from either tenant during the transition period without triggering false security alerts
• Global Address List: GAL synchronization ensures users in both tenants can find each other in the address book, maintaining the seamless communication experience users expect

Timeline for 5K-50K User Organizations

Risk Mitigation: Avoiding the Five Most Common Failures

Tenant-to-tenant migrations fail for predictable reasons. Understanding these failure modes and implementing mitigation strategies prevents the costly rollbacks and extended outages that plague poorly planned migrations.

• Email disruption during domain cutover: Mitigated by reducing DNS TTL values 48 hours before cutover, configuring bidirectional mail forwarding, scheduling cutover during lowest-volume windows, and monitoring DNS propagation across global resolvers before declaring cutover complete
• Data loss during SharePoint migration: Mitigated by running pre-migration validation scans that compare source and target content inventories, using incremental sync to capture changes made during the migration window, and maintaining the source tenant in read-only mode until target validation is complete
• Identity conflicts causing authentication failures: Mitigated by comprehensive directory assessment before migration begins, automated conflict detection and resolution tooling, and a staged approach that resolves all conflicts in a test batch before proceeding to production batches
• Third-party application breakage: Mitigated by inventorying all applications authenticated against the source tenant, coordinating with application vendors on tenant change procedures, testing application connectivity in the target tenant during the pilot phase, and maintaining a rollback plan for critical applications
• User productivity loss from inadequate communication: Mitigated by department-specific migration communication plans, pre-migration training sessions, migration day cheat sheets with step-by-step instructions, and augmented help desk support during each migration batch

Partner with EPC Group for Tenant-to-Tenant Migration

EPC Group has successfully managed tenant-to-tenant migrations for organizations with 2,000 to 75,000 users. Our clients come from various sectors, including:

• Healthcare
• Financial services
• Government
• Technology

We have refined our methodology through numerous M&A integrations and divestitures. Our approach ensures zero data loss and minimal business disruption.

Our Microsoft 365 consulting practice provides end-to-end migration services including pre-acquisition IT due diligence that assesses the technical complexity and cost of tenant consolidation before deal close, migration planning and architecture that defines the phased approach timeline and resource requirements, execution and project management with dedicated migration engineers and 24/7 cutover support, coexistence management that maintains business continuity throughout the migration period, user communication and training that minimizes productivity disruption, and post-migration optimization that validates the target environment and decommissions the source tenant.