How to Migrate from One Microsoft 365 Account to Another?

Migrating from one Microsoft (News - Alert) 365 account to another is called cross-tenant migration. Generally, this type of mailbox migration is needed during organizational restructuring activities like mergers, acquisitions and divestitures to consolidate tenants.

Cross-tenant migration is a process that moves users’ mailbox and identity from the old tenant to the new one while keeping users’ email account working and minimizing disruption to their day-to-day work. To perform this task, an Exchange admin has to perform many steps such as assigning proper permissions, setting up migration endpoint correctly and then executing several Exchange Online cmdlets. Each step requires methodical preparation and execution, which we will discuss in the next section.

Prerequisites and Preparation for Cross-Tenant Migration

Before starting the cross-tenant mailbox migration, ensure the following are in place:

1. Administrative Access
Confirm you have Global Administrator or Exchange Administrator credentials in both source and target tenants, with access to Exchange Online PowerShell.

2. Licensing
Both tenants must have compatible Microsoft 365/Exchange Online subscriptions (Business Basic/Standard/Premium, F1/F3/E3/E5, Office 365 E1/E3/E5, or standalone Exchange Online). Each migrating user needs the Cross Tenant User Data Migration add-on license assigned in addition to their base Exchange license.

3. Identity Planning
Document which mailboxes need to be migrated and confirm each source user has a planned identity in the target tenant (same UPN, renamed UPN, or merged account).

4. Azure AD Migration Application
Register a migration application in Microsoft Entra ID (Azure AD) in both tenants with Mailbox.Migration permissions and admin consent granted. Have the Application ID, Tenant IDs, and client secret ready.

5. Cross-Tenant Trust
Configure Entra ID Cross-Tenant Access Settings to allow inbound access in the target tenant (from source) and outbound access in the source tenant (to target).

6. Source (News - Alert) Tenant Setup
Create a mail-enabled security group containing users to migrate, and export key mailbox attributes (UserPrincipalName, PrimarySmtpAddress, ExchangeGuid, LegacyExchangeDN, Alias) to a CSV file.

7. Target (News - Alert) Tenant Setup
Pre-create user accounts in the target, convert them to MailUser objects, and stamp each with the source mailbox's ExchangeGuid and LegacyExchangeDN (as x500 proxy) for proper matching and mail routing.

Cross-Tenant Microsoft 365 Migration

Below are the steps you need to follow to perform cross-tenant migration:

A. Enable cross-tenant migrations (both tenants)

To register a migration application in Azure AD and grant it the Exchange permissions needed for mailbox moves in both tenants, follow these detailed steps:

1. Sign in to the Microsoft Entra admin center for the target tenant at https://entra.microsoft.com with admin credentials. In the left menu, go to Azure Active Directory > App registrations.

2. Click New registration to create a new application. Provide a name for the application. Here, we have provided the name as CTMM App.

3. Under "Supported account types," choose Accounts in any organizational directory (Multitenant).

4. For a typical desktop-based migration tool connecting to Microsoft 365 with OAuth, you can use Microsoft’s standard native-client redirect URI:

https://login.microsoftonline.com/common/oauth2/nativeclient

Note: If your specific migration product’s docs mention a different redirect URI, use the vendor’s value instead so it matches what the tool expects.

5. After registration, on the application page, copy the Application (client) ID and Directory (tenant) ID values for later use.

6. Go to API permissions on the left hand side and then remove any unnecessary default permissions. For instance, you can remove User.Read permission. After that click on Add a permission.

7. Select APIs my organization uses, type and select Exchange, then choose Application permissions.

8. Under Mailbox, check Mailbox.Migration permission, then click Add permissions.

9. After adding, select Grant admin consent for [your target tenant] and confirm to grant permission.

10. Now go to Certificates & secrets, select New client secret, enter a description, choose an expiry, then click Add. Copy the secret value that will show up immediately, as you won't see it again.

11. Repeat the above steps for the source tenant to register the same app or a similar migration app with identical permissions.

12. Share the Migration Application's client ID, tenant ID, and client secret between source and target admins as needed for migration endpoint configuration.

B. Configure Entra ID Cross-Tenant Access Settings

1. Sign in to the Microsoft Entra admin center.

2. Navigate to External Identities > Cross-tenant access settings.

3. Under the Inbound access tab, add the target tenant’s Azure AD tenant ID or domain as a trusted tenant:

• Click Add organization.
• Enter the target tenant’s tenant ID or domain that was written down earlier
• Configure the inbound access permissions (e.g. allow all users/groups or specific users). By allowing specific users or groups, you're telling Entra ID to trust those accounts from the source tenant so they can access your migration endpoint without being blocked as untrusted external users.

4. Do the same in the Outbound access tab for source tenant. For this, you have to login separately into the Source tenant and go the Outbound access tab and provide outbound access permission. This allows users/apps in the source tenant to obtain tokens and reach resources in the target tenant.

5. Save and apply these settings. This allows Entra to allow cross-tenant collaboration and permission delegation.

C. Prepare Source Tenant by Creating a Mail-Enabled Security

In the source tenant:

1. Go to https://admin.exchange.microsoft.com and navigate to Recipients > Groups>Mail-enabled security. After that, click Add a group

2. In the wizard:

Choose a group type: select Mail-enabled security

3. Give it a name such as CTMAllowed

4. After that, assign owners and add members that will join this group. In one instance, you can add up to 20 members. Later, you can add more members to the groups by going to Active teams & groups.

5. Here, you can provide a group email address. This group email address should have one of the accepted domains in your source tenant. If you want to confirm which domains are accepted, you can find them and even manage them by going to the Mail flow > Accepted domains (on the left-hand side) in the Exchange admin center.

D. Export Source Mailbox Attributes to CSV

Before moving to the target tenant, you need to capture key attributes from the source mailboxes that will be migrated. Before migrating mailboxes to the target tenant, you need to capture key attributes from the source mailboxes. These attributes are used to set up matching MailUser objects in the target tenant ahead of time, so the migration process knows where to place each user's data.

6. Connect to source using Exchange Online PowerShell with the following command:

Connect-ExchangeOnline

7. Export the mailboxes you plan to migrate (for example, all members of the CTMAllowed group or a specific set of users) into a CSV with the required attributes:

PowerShell

Get-Mailbox -ResultSize Unlimited |

 Select-Object UserPrincipalName, PrimarySmtpAddress, ExchangeGuid, LegacyExchangeDN, Alias |Export-Csv "C:\Temp\SourceMailboxes.csv" -NoTypeInformation -Encoding UTF8

Copy this CSV file (for example, SourceMailboxes.csv) to a location that is easily accessible from the location where you'll run the target tenant PowerShell commands in the next section.

E. Prepare Target Tenant

Using the CSV file in the last step, we can provision MailUsers in the target tenant

For that, we need to create the basic users in the target Microsoft 365 admin center:

1. Go to https://admin.microsoft.com > Users > Active users.
2. Create users that match the people you will migrate (UPN / primary SMTP as per your plan
3. Give them licenses if you want mailboxes ready after migration (licenses can be provided post-migration, so you don’t have to do that in this step)
4. Turn users into MailUsers and stamp GUID + x500 by using PowerShell and connecting to Exchange Online.

PowerShell

Connect-ExchangeOnline

5. Import your CSV (copied from the source step):

PowerShell

$csv = Import-Csv "C:\Temp\SourceMailboxes.csv"

6. For each row, make sure a MailUser exists, then set the attributes:

Powershell

foreach ($m in $csv) {

    # Ensure a MailUser exists (if the user already has a mailbox, you skip this MailUser creation step)

    $mu = Get-MailUser -Identity $m.UserPrincipalName -ErrorAction SilentlyContinue

    if (-not $mu) {

        New-MailUser -Name $m.UserPrincipalName `

                     -ExternalEmailAddress $m.PrimarySmtpAddress `

                     -UserPrincipalName $m.UserPrincipalName `

                     -Password (ConvertTo-SecureString "TempP@ssw0rd!" -AsPlainText -Force)

    }

    # Stamp ExchangeGuid and LegacyExchangeDN as x500

    Set-MailUser -Identity $m.UserPrincipalName -ExchangeGuid $m.ExchangeGuid

    Set-MailUser -Identity $m.UserPrincipalName `

        -EmailAddresses @{add=("x500:" + $m.LegacyExchangeDN)}

}

Result: for every migrating user, the target tenant has a MailUser whose ExchangeGuid and x500 alias match the source mailbox, which is required for cross-tenant moves.

F. Create the cross-tenant migration endpoint in target

In target Exchange Online PowerShell, keep these details ready as you will need them in the Powershell command:

• AppId = Application (client) ID of the migration app
• TenantIdSource = source tenant ID
• Secret = client secret you created for the app

1. Create a PSCredential object for the app:

PowerShell

$AppId     = "00000000-0000-0000-0000-000000000000"

$TenantId  = "source-tenant-guid-here"

$Secret    = "your-app-secret-here" | ConvertTo-SecureString -AsPlainText -Force

$Cred      = New-Object System.Management.Automation.PSCredential ($AppId, $Secret)

2. Create the endpoint:

PowerShell

New-MigrationEndpoint -Name "CTM (News - Alert)-Endpoint" `

    -ExchangeRemoteMove `

    -RemoteServer "outlook.office365.com" `

    -RemoteTenant $TenantId `

    -ApplicationId $AppId `

    -Credentials $Cred

This tells MRS how to reach the source tenant using your app registration.

F. Test the Endpoint and Start Migration

1. Pick one of the MailUsers you created in the target (its primary SMTP):

PowerShell

Test-MigrationServerAvailability -EndPoint "CTM-Endpoint" -TestMailbox [email protected]

• Success = your trust, app, and MailUser attributes are correct and you’re ready to build New-MigrationBatch for that user.

2. Build the migration CSV in the target

In target Exchange Online PowerShell (where MailUsers are already prepared), use the following command:

PowerShell

Connect-ExchangeOnline

3. Export the MailUsers you want to move into a CSV with a single EmailAddress column (what New-MigrationBatch expects for cross-tenant moves).

PowerShell

Get-MailUser -Filter {RecipientTypeDetails -eq "MailUser"} |

  Select-Object @{Name='EmailAddress';Expression={$_.PrimarySmtpAddress}} |

  Export-Csv "C:\Temp\CTM-Users.csv" -NoTypeInformation -Encoding UTF8

4. Create and start the migration batch

In this step, we are going to start the migration batch. But before doing that, we can name the migration endpoint and target’s tenant’s domain as:

• Migration endpoint name: CTM-Endpoint
• Target tenant’s onmicrosoft.com domain: targettenant.onmicrosoft.com

PowerShell

$csvPath = "C:\Temp\CTM-Users.csv"

New-MigrationBatch -Name "CTM-FullMove" `

    -SourceEndpoint "CTM-Endpoint" `

    -CSVData ([System.IO.File]::ReadAllBytes($csvPath)) `

    -Autostart `

    -TargetDeliveryDomain "targettenant.onmicrosoft.com"

This immediately creates the batch and starts syncing mailbox data from the source to the target for all users listed in the CSV

5. Monitor and complete the batch

For monitoring the batch and ensuring that it is synced, we can use the following command:

Powershell

Get-MigrationBatch -Identity "CTM-FullMove"

Get-MigrationUser | ft Identity,Status,PercentComplete

6. When the batch shows Synced (all users are ready), you can complete the migration:

PowerShell

Complete-MigrationBatch -Identity "CTM-FullMove"

Once completed, the MailUsers in the target become full mailboxes, and the original source mailboxes are converted to MailUsers pointing back to the target.

Post-Migration DNS and Cleanup

After the migration batch completes and users are working from the target tenant, finalize DNS and cleanup tasks:

Update DNS Records (if domains are moving)

If the email addresses used by migrated users are being transferred to the target tenant (for example, moving companyb.com from source to target), update the following DNS records for those domains to point to the target tenant:

• MX records – to route inbound mail to the target tenant's Exchange Online.
• Autodiscover records – so Outlook clients automatically configure to the target tenant.
• SPF records – to authorize the target tenant to send mail on behalf of the domain.

Once DNS is updated, test inbound and outbound mail flow to confirm email is routing correctly through the target tenant.

If users received new email addresses in a domain that was already in the target tenant, no DNS changes are needed for the old source domain.

Clean up Source Tenant Configuration

Review and remove or adjust legacy configuration in the source tenant that is no longer needed:

• Send/Receive connectors – delete any custom connectors that routed mail to or from the source tenant for migrated users.
• Transport rules (mail flow rules) – disable or remove rules that applied to migrated users or domains now in the target.
• Hybrid configuration – if the source had hybrid settings (on-premises Exchange integration), remove or update those settings if they're no longer relevant.

Decommission the Source Tenant if Needed

If you no longer need the source tenant:

• Remove accepted domains that have been transferred to the target.
• Delete or disable the MailUser objects left behind after migration, once you confirm mail routing is stable.
• Revoke licenses and app registrations to avoid ongoing costs and administrative overhead.

Making It Easy with Stellar Migrator for Exchange

Performing cross-tenant migration natively using the Microsoft method requires an Exchange admin to meet many prerequisites, perform various attribute checks, and execute several PowerShell scripts. To simplify and expedite this complex process, Exchange migration tool can be used. It provides the following benefits, making the task of an Exchange admin simpler:

• No Complex Setup Required: Stellar tool connects the source Microsoft 365 tenant with the target tenant via an easy-to-use auto-registration method that simply requires Microsoft 365 Global admin credentials. Therefore, it eliminates the complex setup requirements of supplying server information, registering an application in Azure AD for managing user access, configuring authentication, and assigning permissions. As a result, the cross-tenant migration process becomes simple and straightforward for Exchange admins.
• Map Mailboxes Automatically to Simplify and Expedite Migration: By comparing email addresses between the source and target servers, the Exchange migration tool automatically maps mailboxes. In case, the automatic mapping doesn’t match some mailboxes accurately, you can manually match them after automatic mapping is completed.
• Fast and Efficient: You can move many mailboxes at once (up to 10) as the tool supports concurrent mailbox migration. It also has the provision of using CSV files for mapping users at the very beginning, which is highly useful when you already have mailboxes matched. This option works well when you have to manually pair specific mailboxes (e.g., [email protected] to [email protected]) in scenarios such as mergers with renamed UPNs.
• Preserves Folder Structure: The Exchange migration tool keeps your mailbox folders exactly as they are—Inbox, Sent Items, custom subfolders, and even nested hierarchies stay organized and intact during migration. When users open their mailbox after cross-tenant migration is complete, they see their Outlook just as they had it before migration.

Conclusion

By planning cross-tenant migration properly and executing migration steps correctly, an Exchange or Microsoft 365 admin can migrate mailboxes from one Microsoft 365 account to another using native Microsoft tools. Although this process works well, it requires a lot of preparation and PowerShell scripting, which makes this the task very complex. For simplifying this process, Exchange admins can use Stellar Migrator for Exchange, which provides several benefits (as mentioned above). Using this Exchange migration tool, the folder structure is maintained, which means the users receive their mailbox in the new tenant just as they had it in the old tenant.