An Office 365 to Office 365 migration moves Exchange Online mailboxes and the supported mailbox content from one Microsoft 365 account to another. These include emails, contacts, notes, and tasks. Also called tenant-to-tenant migration, it becomes a necessity during divestitures or mergers of organizations, which require moving Exchange Online mailboxes across the tenants. The following methods are help to perform this task:
- Native Microsoft method: Exchange Online PowerShell with the Mailbox Replication Service (MRS)
- Migration start and management: PowerShell and Exchange Admin Center
Often, these methods may cause unavoidable complexities, which are hard to overcome. As an alternative, experts prefer using advanced Exchange migration tool. Right here, we will find out more about these crucial methods to perform Office 365 to Office 365 migration.
Reasons for Office 365 to Office 365 Migration
Several factors may trigger the need for cross-tenant migration in the Exchange Online environment:
- Mergers and acquisitions: A company may become a part of a bigger company during a merger or an acquisition. In this situation, the IT environments of both organizations must combine into one consolidated IT environment for better collaboration.
- Splits and divestitures: When a big corporate house splits into independent organizations, its data also needs systematic separation to create new tenants.
- Business rebranding: When a company wishes to change its brand identity or legal name, it will also require a new tenant with fresh domain names.
- Tenant Consolidation: It happens when an organization merges multiple tenants into a single tenant to optimize cost and management aspects.
- Compliance and data sovereignty: A company may want to relocate its business to a tenant hosted in a different geographic location to comply with the local privacy regulations.
In addition, the migration also provides multiple benefits. These include reduced downtime, batch-based migration, and Native Microsoft support among others. Let’s now focus on the main part – carrying out the tenant-to-tenant migration.
Methods to Perform Office 365 to Office 365 Migration
Microsoft’s cross-tenant mailbox migration process uses Exchange Online PowerShell and Mailbox Replication Service (MRS) to move Exchange Online mailboxes between tenants. It requires you to first configure the target tenant, followed by the source tenant, before starting the user migration.
1. Prepare the Source and Target Tenants
Before starting the migration, ensure that both tenants abide by Microsoft’s prerequisites and the users chosen for migration have due license.
- Ensure having the permissions required to configure the Move Mailbox application, Exchange Online migration endpoint, and Exchange Online Organization Relationship.
- Create at least one mail-enabled security group in the source tenant to define the mailboxes that you can migrate.
- For bulk migrations, such as those involving more than 10,000 users, Microsoft recommends using multiple groups.
- Obtain the Microsoft 365 Tenant ID of the trusted partner.
- Ensure users in both organizations have the appropriate Exchange Online subscriptions.
- Apply one-time Cross Tenant User Data Migration licenses to each user being migrated.
- Configure the target or destination tenant first.
2. Configure the Target Tenant
The first configuration stage takes place in the destination tenant. It involves several essential jobs, as mention in the steps below:
- Sign in to the Microsoft Entra admin center using the target tenant administrator credentials.
- Go to App registrations and select New registration.
- Under Supported account types, select Accounts in any organizational directory (Multi-tenant).
- Select Web under Redirect URI and enter https://office.com.
- Copy the Application (client) ID after registering the application.
- Under API permissions, select Office 365 Exchange Online.
- Select Application permissions.
- Under Mailbox, select Mailbox.Migration.
- Under Certificates & secrets, create a new client secret.
- Save the secret because it is required when creating the migration endpoint.
- Grant administrator consent to the application.
- Provide the source tenant administrator with the required admin-consent URL.
3. Create the Migration Endpoint and Organization Relationship
Once the migration application and consent are configured, create the migration endpoint and Organization Relationship in the target tenant.
- Connect to Exchange Online PowerShell in the target tenant.
- Create a new migration endpoint for cross-tenant mailbox moves.
- Provide the application ID and client secret when creating the endpoint.
- Ensure that the source tenant administrator has accepted the application before completing the endpoint configuration.
- Create a new Organization Relationship or edit the existing relationship with the source tenant.
- Enable mailbox moves for the relationship.
- Set MailboxMoveCapability to Inbound.
4. Configure the Source Tenant
The source tenant must accept the migration application and establish its Organization Relationship with the destination tenant.
- Open the admin-consent URL provided by the target tenant administrator.
- Accept the mailbox migration application.
- Connect to Exchange Online PowerShell in the source tenant.
- Create a new Organization Relationship or edit the existing relationship with the target tenant.
- Enable mailbox moves.
- Set MailboxMoveCapability to RemoteOutbound.
- Specify the application ID of the migration application.
- Specify the mail-enabled security group containing users who are allowed to migrate.
- Publish this group through MailboxMovePublishedScopes.
5. Prepare Target User Objects
Each mailbox being migrated must have a corresponding MailUser in the target tenant with the required attributes. Microsoft states that users who aren’t properly configured in the target tenant can’t be moved.
- Provision a MailUser for every mailbox being migrated.
- Ensure the target MailUser has the same ExchangeGUID as the source mailbox.
- If the source mailbox is archive-enabled, ensure that the ArchiveGUID also matches.
- Add the source mailbox’s LegacyExchangeDN to the target MailUser as an x500: proxy address.
- Copy all X500 addresses from the source mailbox to the target MailUser.
- Configure the UserPrincipalName according to the user’s new identity or target company.
- Configure the Primary SMTP Address according to the user’s new company.
- Set ExternalEmailAddress (TargetAddress) to reference the user’s current mailbox in the source tenant.
- Ensure that the target MailUser doesn’t have a previous ExchangeGUID that differs from the source ExchangeGUID.
- If required, use Set-User <identity> -PermanentlyClearPreviousMailboxInfo to clear previous mailbox information. Microsoft warns that this operation is irreversible.
- Apply the Cross Tenant User Data Migration license and the appropriate Exchange Online license.
6. Validate the Migration Configuration
Microsoft provides a way to test the configuration before starting the actual mailbox move.
- Run Test-MigrationServerAvailability against the cross-tenant migration endpoint created in the target tenant.
- Run the test from the target tenant.
- Use the primary SMTP address of the target MailUser as the test mailbox.
- Use Microsoft’s Cross-tenant mailbox migration validation script to validate the organizations and objects planned for migration.
- Use the validation results to identify discrepancies in the configuration.
7. Create and Run Migration Batches
Cross-tenant Exchange mailbox migrations are initiated from the target tenant as migration batches.
- Prepare a CSV file containing the users to be migrated.
- Use the target-tenant email address in the CSV rather than the source-tenant email address.
- Create the migration batch with the New-MigrationBatch cmdlet.
- Specify the migration name, source endpoint, CSV data, and target delivery domain.
- Start the migration batch.
- Migration batch submission is also supported through the new Exchange admin center by selecting the cross-tenant option.
8. Complete Post-Migration Tasks
After the mailbox moves successfully, Microsoft recommends completing several post-migration tasks to maintain mail routing and clean up the migration configuration.
- The source mailbox is converted to a MailUser.
- The targetAddress, shown as ExternalEmailAddress in Exchange, is stamped with the routing address to the destination tenant.
- Update the targetAddress of on-premises MailUsers in the source and target organizations where applicable.
- Remove and recreate Teams meetings because their URLs aren’t updated when items migrate across tenants.
- Use Remove-MigrationEndpoint to remove migration endpoints after the migration is complete.
- Use Remove-OrganizationRelationship to remove the Organization Relationships after the migration is complete.
Limitations of Office 365 to Office 365 Migration
Microsoft’s native cross-tenant migration has several limitations, making it a complex task overall:
- No migration for on-hold mailboxes: Exchange Mailboxes facing any type of hold cannot undergo cross-tenant migration.
- Migration is possible only for supported mailboxes: Cross-tenant migration allows transferring only user-visible content, such as email, contacts, calendar, tasks, notes, and Recoverable Items. You cannot use it to view the Teams chat folder or Outbox content.
- No updation for Teams meeting URLf: The URLS of Teams meetings go invalid in the target tenant despite migration, forcing their removal or recreation.
- Strict preparation for target users: The users in the target tenant must exist as MailUsers and need to have matching ExchangeGUID, ArchiveGUID, wherever necessary, to avoid failed migrations.
- Need for migration license: Every user needs to possess a Cross Tenant User Data Migration license to qualify for the migration.
To reduce these restrictions, Exchange administrators prefer using an alternative Exchange migration tool.
Using Stellar Migrator for Exchange to Perform Office 365 to Office 365 Migration
Stellar Migrator for Exchange is an advanced third-party automated tool, provides various features to avoid or minimize the limitations of Microsoft’s native cross-tenant mailbox migration.
It is suitable for Office 365 Tenant-to-Tenant Migration, Seamless Exchange to Exchange migration and Exchange to Office 365 & Vice Versa Migration. Some of its prominent features are as follows:
- Migrate first 2 mailboxes for FREE.
- Automated mailbox matching
- Reduced manual configuration
- Incremental migration
- Parallel processing
- Preservation of folder structures/permissions
- Selective Mailbox Folder Migration
- Hassle-free Public Folder Migration
Conclusion
An Office 365 to Office 365 (Tenant-to-Tenant) migration becomes a necessity in case of an organization’s merger, divestiture, compliance requirements, or tenant consolidation. It serves multiple benefits but also follows a complex process that requires extreme precision. From preparing the source and target tenants to completing post-migration tasks, every step needs due attention. Any lapse may lead to failed migration, causing you to face data losses. Besides, it also has several limitations, such as the need for a migration license, strict preparation for target users, and so on. To avoid such issues, an Exchange migration tool, such as Stellar Migrator for Exchange, can prove beneficial.
