Tenant-to-Tenant Migration: The Domain Cutover That Keeps Downtime Under 30 Minutes

Mergers and acquisitions force tenant consolidation, and the moment you try to add the acquired company's domain to the surviving tenant, Office 365 stops you: the domain already exists in another Microsoft account. That constraint is what makes a same-domain tenant-to-tenant migration a downtime event rather than a background sync. The whole job is sequencing the work so the bulk of the data moves ahead of time and the actual outage stays around 30 minutes. This walks the full BitTitan sequence, with every PowerShell script.

Take the example of parent company A acquiring child company B. If you try to add company B's domain into parent company A, you get an error saying it already exists in another Microsoft account. So you must remove the primary domain from one tenant and recreate it in the other. Done correctly, downtime is limited to 30 minutes.

This is a high-level overview of the migration steps using BitTitan. For a complete step-by-step guide with screenshots, follow this BitTitan playbook (Office 365 to Office 365) (opens in new tab). While the guide is specific to BitTitan, the same concepts apply with any tool.

Set up the destination environment#

Provision users in the destination tenant#

They will be provisioned with the .onmicrosoft.com domain in this account. Options:

• Add one at a time
• Bulk upload via PowerShell
• Bulk upload via CSV
• Assign licenses

Stage the domain (do not verify it yet)#

In the 365 Admin Center, go to Setup > Domains > Add Domains. Note: this is where you will add the domain and verify with a TXT record after you remove it from the source tenant. For now, users keep the .onmicrosoft.com address as their primary SMTP.

Bulk import users with passwords via PowerShell#

Import-Csv -Path 'FilePath' | foreach {New-MsolUser -UserPrincipalName $_.UserPrincipalName -FirstName $_.FirstName -LastName $_.LastName -DisplayName $_.DisplayName -Password $_.Password -ForceChangePassword $False}

Set impersonation rights for the admin user#

Connect to Exchange Online with PowerShell and run:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

Prepare source and destination for BitTitan#

Set impersonation rights on both tenants#

Note: you have to connect to the source 365 tenancy and destination 365 tenancy separately in PowerShell and run these commands in each session. Connect to Exchange Online with PowerShell and run:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

Raise the message size limit to 150 MB#

Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB

Set up a BitTitan account#

Create a login#

Create a BitTitan username and password at bittitan.com (opens in new tab).

Create a customer#

Enter the primary domain name and customer name.

Send out the agent to reconfigure Outlook profiles#

Note: BitTitan includes a tool called Deployment Pro that reconfigures Outlook profiles after the migration. You can push it out by GPO or email.

Choose the delivery method#

Decide whether to send the agent via GPO or email.

• GPO instructions (opens in new tab)
• Email instructions (opens in new tab)

Track users with the agent installed#

Devices register and match a user's email address to a computer in a one-to-one relationship. Each computer has a heartbeat.

Prepare migration endpoints#

Set up source and destination endpoints#

• The source endpoint is found under Office 365.
• The destination is Office 365.
• Provide admin credentials for each endpoint.

Autodiscover users#

• Clean up the user list as needed.
• Remediate UPN issues by clicking the pencil icon next to users.
• The source should contain the .com address; the destination should contain the .onmicrosoft.com address.

Verify credentials#

• This tells you if there are errors.
• The most typical errors are insufficient impersonation rights or wrong admin credentials.
• It shows "Completed Verification" on success.

Subscribe users#

• Select all users, then click the last icon on the top toolbar with three lines.
• "Apply User Migration Bundle."
• Takes 3 to 5 minutes to propagate.

Start the migration#

Run a prestage pass#

Bring mail from the source tenant to Office 365 before removing the domain.

• This brings over the bulk of the data before the domain is removed.
• It only makes copies of the mail.
• Set it prior to 60 days.
• Any user whose status changes to "Failed" is almost 100% due to a server timeout; simply rerun those users.

Run a full pass#

Bring over the remaining mail, calendars, contacts, notes, and rules.

• Start once the prestage pass has completed.
• You can run up to 10 delta passes.
• Make sure everyone reaches a "Completed" status.

Remove the domain from the source tenant#

This is the start of the downtime window.

Bulk-update all user UPNs to .onmicrosoft.com#

To remove the domain, it must be removed from all records in the portal.

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber
$testpath = test-path c:\temp; If ($testpath -eq $false) {new-item -type directory c:\temp}; $dataout = @();
Get-MsolUser -All | ? {$_.UserPrincipalName -match "domain.com"} | % {Set-MsolUserPrincipalName -ObjectId $_.objectId -NewUserPrincipalName ($_.UserPrincipalName.Split("@")[0] + "@domain.onmicrosoft.com"); $dataout += "$($_.UserPrincipalName)" ; $_.UserPrincipalName };$dataout | out-file c:\temp\UPNChangeOutput.txt

Remove all aliases with the domain#

$Records = Get-mailbox -ResultSize Unlimited| where {$_.emailaddresses -like "smtp:*@domain.com"} | Select-Object DisplayName,@{Name="EmailAddresses";Expression={$_.EmailAddresses |Where-Object {$_ -like "smtp:*domain.com"}}}
foreach ($record in $Records)
{
    write-host "Removing Alias" $record.EmailAddresses "for" $record.DisplayName
    Set-Mailbox $record.DisplayName -EmailAddresses @{Remove=$record.EmailAddresses}
}

Remove all groups with the domain#

Get-MsolGroup -all | ?{$_.emailaddress -match "domain.com"} | Remove-MsolGroup -force

Remove the domain#

• The portal notifies you if any users or groups still have the domain attached.
• Work with GoDaddy if you need additional assistance.

Recreate the domain in the destination tenant#

These steps are basically the reverse of what you just performed in the source tenant.

Add the domain#

• In the destination 365 Admin Center, go to Setup > Domains > Add Domains.
• Add the domain and verify with a TXT record (can take about 5 minutes before you can recreate).

Bulk-update all user UPNs back to .com#

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber
$testpath = test-path c:\temp; If ($testpath -eq $false) {new-item -type directory c:\temp}; $dataout = @();
Get-MsolUser -All | ? {$_.UserPrincipalName -match "domain.onmicrosoft.com"} | % {Set-MsolUserPrincipalName -ObjectId $_.objectId -NewUserPrincipalName ($_.UserPrincipalName.Split("@")[0] + "@domain.com"); $dataout += "$($_.UserPrincipalName)" ; $_.UserPrincipalName };$dataout | out-file c:\temp\UPNChangeOutput.txt

Bulk-upload distribution lists#

Create two CSVs:

• One with the distribution group name and primary SMTP address.
• One with the group name and the members of that group.

Import-Csv -Path 'File Path' | foreach {New-Distributiongroup -Name $_.Name -PrimarySmtpAddress $_.Address }
Import-Csv 'File Path' | foreach {Add-DistributionGroupMember -Identity $_.DL -Member $_.Alias}

Post-migration cleanup#

Confirm the DMA agent ran#

• DMA status goes to "Completed" after successful authentication by the end user.
• Any user who fails authentication three times goes into an "error" status.
• Reschedule those users and make sure they have the correct 365 password.

Give mobile users reconfiguration guides#

Mobile users can set up their mailbox on their phone with these guides:

• iPhone (opens in new tab)
• Android (opens in new tab)

The sequence is what protects the clock: prestage the bulk of the mail, run deltas until everyone is current, and only then open the downtime window for the domain swap. The consolidated tenant that comes out the other side has twice the users, twice the groups, and twice the chances that something got misconfigured under deadline pressure, which is the right moment to set a clean baseline rather than assume one.