Seamless Microsoft 365 Tenant to Tenant Migration for SMBs: An Implementation Guide

Step 1: Strategic Planning & Target Tenant Preparation

Before any technical work begins, comprehensive planning is paramount. This initial phase involves defining the migration scope, establishing key timelines, acquiring necessary licensing, and preparing the foundational administrative structure in your target tenant. This proactive preparation ensures that the new environment is ready to receive migrated data and users.

# Connect to the Target Microsoft 365 tenant (Azure AD PowerShell)
Connect-MsolService

# Connect to the Target Exchange Online tenant (Exchange Online PowerShell)
Connect-ExchangeOnline -UserPrincipalName admin@target.onmicrosoft.com -ShowProgress $true

• Connect-MsolService: Establishes a connection to the Azure Active Directory service for user and domain management in the target tenant.
• Connect-ExchangeOnline: Connects to Exchange Online, allowing you to manage mailboxes, groups, and other email-related settings. The -UserPrincipalName specifies the administrator account for connection, and -ShowProgress $true provides connection status updates.

Portal alternative: Log into the Microsoft 365 admin center (admin.microsoft.com) for your target tenant, then navigate to Billing > Your products to verify license availability. Access the Exchange admin center (admin.exchange.microsoft.com) and Azure Active Directory admin center (aad.portal.azure.com) to familiarize yourself with the target environment.

Run this to verify: Confirm successful connections by running simple commands.

(Get-MsolAccountSku).ActiveUnits # Verify active licenses
Get-OrganizationConfig | Select-Object Name # Verify Exchange Online connection

Step 2: Domain Verification for Migration

A crucial step in a Microsoft 365 tenant to tenant migration is preparing your custom domain (e.g., source.com) for transfer. This involves adding the domain to your target tenant and beginning the verification process. Importantly, the verification will initially fail because the domain is still active in the source tenant, but this pre-verification ensures a faster cutover later.

# Connect to the Target Microsoft 365 tenant (Azure AD PowerShell)
Connect-MsolService

# Add the custom domain to the target tenant
New-MsolDomain -Name "source.com"

# Retrieve the DNS TXT record for domain verification
Get-MsolDomainVerificationDns -DomainName "source.com" -Mode DnsTxtRecord

• New-MsolDomain -Name "source.com": Initiates the process of adding your custom domain to the target tenant. This command tells Azure AD that you intend to use this domain.
• Get-MsolDomainVerificationDns -DomainName "source.com" -Mode DnsTxtRecord: Retrieves the specific TXT record value you need to create in your public DNS. This record proves domain ownership to Microsoft. Keep this value handy.

Portal alternative: In the Microsoft 365 admin center for the target tenant, navigate to Settings > Domains > Add domain. Enter source.com and follow the wizard to generate the TXT record for verification. You'll need to publish this TXT record with your domain registrar/DNS host. Do NOT remove the domain from the source tenant yet!

Run this to verify: After publishing the TXT record (this can take 5-15 minutes to propagate globally), check the verification status. It will likely show as 'Unverified' initially, which is expected.

Get-MsolDomain -DomainName "source.com"

Step 3: User, Group, and Resource Pre-Provisioning

To ensure a seamless transition, user accounts, security groups, distribution lists, and resource mailboxes (rooms, equipment) must be created in the target tenant before mailbox data is moved. For SMBs with 10-200 users, bulk creation via PowerShell or CSV import is often the most efficient method, as full Active Directory Domain Services (AD DS) consolidation might be overkill if not already in place. The initial User Principal Name (UPN) for these objects will use the .onmicrosoft.com domain, which will be updated post-domain transfer.

# Connect to the Target Microsoft 365 tenant (Azure AD PowerShell)
Connect-MsolService

# Example: Create a new user from a CSV (replace with your actual CSV path and fields)
# Assuming users.csv has columns: DisplayName, FirstName, LastName, UPN (e.g., user@target.onmicrosoft.com), Password
# (Note: For security, manage passwords carefully. Consider setting 'UsageLocation' for license assignment.)

Import-Csv -Path "C:\Temp\users.csv" | ForEach-Object {
    $upn = $_.UPN
    $firstName = $_.FirstName
    $lastName = $_.LastName
    $displayName = $_.DisplayName
    $password = $_.Password

    Write-Host "Creating user: $displayName"
    New-MsolUser -DisplayName $displayName -FirstName $firstName -LastName $lastName -UserPrincipalName $upn `
                 -Password $password -UsageLocation "CA" -ForceChangePassword $true
}

# Example: Create a new security group
New-MsolGroup -DisplayName "Sales Team" -Description "Sales Department Security Group" -GroupType Security

# Example: Create a new distribution group (requires Exchange Online connection)
# Connect to Exchange Online if not already connected
Connect-ExchangeOnline -UserPrincipalName admin@target.onmicrosoft.com -ShowProgress $true
New-DistributionGroup -Name "All Company" -DisplayName "All Company" -Alias "allcompany" -PrimarySmtpAddress "allcompany@target.onmicrosoft.com"

• Import-Csv and ForEach-Object: This pattern allows you to automate user creation from a structured CSV file, which is highly recommended for more than a handful of users.
• New-MsolUser: Creates a new user object in Azure AD. Key parameters include -DisplayName, -UserPrincipalName (initially using .onmicrosoft.com), and -Password. -UsageLocation is critical for assigning licenses later, and -ForceChangePassword $true ensures users set a strong password on first login.
• New-MsolGroup: Creates security groups.
• New-DistributionGroup: Creates distribution lists directly in Exchange Online.

Portal alternative: In the Microsoft 365 admin center, navigate to Users > Active users > Add multiple users to import users from a CSV file. For groups, go to Teams & groups > Active teams & groups > Add a group.

Run this to verify: Check if users and groups have been provisioned in the target tenant.

Get-MsolUser -All | Select-Object DisplayName, UserPrincipalName
Get-MsolGroup -All | Select-Object DisplayName, GroupType

Step 4: Preparing for Mailbox Data Transfer

This is where the actual migration of mailbox data is enabled. Microsoft currently offers a Public Preview of native Cross-tenant mailbox migration. For SMBs, evaluating the readiness and stability of a public preview for production is critical. Alternatively, Microsoft often recommends specialized third-party migration tools for complex scenarios or larger data volumes (typically >500 users or large SharePoint data). The preparation steps detailed below are generally applicable, regardless of the migration tool chosen, as they establish the necessary administrative access and relationships between tenants.

# Connect to the Source Microsoft 365 tenant (Exchange Online PowerShell)
Connect-ExchangeOnline -UserPrincipalName admin@source.com -ShowProgress $true

# Connect to the Target Microsoft 365 tenant (Exchange Online PowerShell)
Connect-ExchangeOnline -UserPrincipalName admin@target.onmicrosoft.com -ShowProgress $true

# Create a MailUser in the target tenant for each mailbox to be migrated (if not done in Step 3 already for user accounts)
# This is a conceptual step. If using native migration, specific cmdlets will be part of the preview process.
# If using a third-party tool, this step might involve creating target endpoints and giving permissions.
# As the source documentation points to a Public Preview URL for native tools and mentions third-party tools,
# specific cross-tenant migration cmdlets are not detailed in the provided materials.
# Always consult the latest Microsoft Learn documentation for the native cross-tenant migration preview.

• This step primarily involves ensuring both source and target Exchange Online environments are accessible by the migration administrators.
• Specific commands for configuring the *native* cross-tenant migration are part of the Public Preview feature and should be consulted directly from the official Microsoft Learn documentation linked in the source (https://aka.ms/CrossTenantMailboxMigration).
• For *third-party migration tools*, you would typically configure source and target connectors or endpoints, granting the necessary impersonation or application permissions as required by the tool. This often involves creating a migration administrative user with specific management roles in both tenants.

Portal alternative: For native preview configuration, follow instructions provided at the Public Preview documentation. For third-party tools, their respective administrative portals will guide you through setting up source and target connections and permissions.

Run this to verify: Confirm the administrative accounts have the required roles in both tenants.

# Connect to Source Exchange Online and check roles for the migration admin
Get-ManagementRoleAssignment -Role "ApplicationImpersonation" -GetEffectiveUsers -ErrorAction SilentlyContinue | Where-Object {$_.EffectiveUserName -eq "migrationadmin@source.com"}

# Repeat for Target Exchange Online
Get-ManagementRoleAssignment -Role "ApplicationImpersonation" -GetEffectiveUsers -ErrorAction SilentlyContinue | Where-Object {$_.EffectiveUserName -eq "migrationadmin@target.onmicrosoft.com"}

Step 5: Initiating Mailbox Data Transfer

Once the preparatory steps are complete, and the chosen migration method (native preview or third-party tool) is configured, the actual mailbox data transfer can begin. This often involves batching users, scheduling migration windows, and continuously monitoring progress. After data syncs, the critical domain cutover takes place, moving your custom domain from the source tenant to the target, and updating user UPNs and primary email addresses.

# Connect to the Source Microsoft 365 tenant (Azure AD PowerShell)
Connect-MsolService

# Remove the custom domain from the source tenant (THIS IS THE DOMAIN CUTOVER - PERFORM ONLY DURING PLANNED DOWNTIME)
# This action will temporarily disrupt mail flow to source mailboxes.
Remove-MsolDomain -DomainName "source.com" -Force

# Connect to the Target Microsoft 365 tenant (Azure AD PowerShell)
Connect-MsolService

# Complete domain verification in the target tenant
Confirm-MsolDomain -DomainName "source.com"

# Update User Principal Names (UPNs) and Primary SMTP addresses for migrated users in the target tenant
# Assuming you have a CSV with 'OldUPN' (user@target.onmicrosoft.com) and 'NewUPN' (user@source.com)
Import-Csv -Path "C:\Temp\user_upn_map.csv" | ForEach-Object {
    $oldUPN = $_.OldUPN
    $newUPN = $_.NewUPN
    $primarySMTP = $_.PrimarySMTPAddress # e.g., user@source.com

    Write-Host "Updating UPN for $oldUPN to $newUPN"
    Set-MsolUserPrincipalName -UserPrincipalName $oldUPN -NewUserPrincipalName $newUPN

    Write-Host "Updating Primary SMTP for $newUPN to $primarySMTP"
    Set-Mailbox -Identity $newUPN -PrimarySmtpAddress $primarySMTP
}

• Remove-MsolDomain -DomainName "source.com" -Force: This command is the critical step for releasing your custom domain from the source tenant. Execute this only after all mailboxes are synced and during a pre-planned downtime window. This action will cause a temporary interruption of services reliant on this domain.
• Confirm-MsolDomain -DomainName "source.com": Finalizes the domain verification in the target tenant once it's released from the source.
• Set-MsolUserPrincipalName: Changes the UPN of users in the target tenant from their initial .onmicrosoft.com UPN to the new custom domain UPN (e.g., user@source.com).
• Set-Mailbox -PrimarySmtpAddress: Assigns the correct primary email address to the migrated mailboxes in the target tenant.

Portal alternative: In the Microsoft 365 admin center for the source tenant, navigate to Settings > Domains, select source.com, and choose 'Remove domain'. In the target tenant, after the domain is removed from source, go to Settings > Domains, select source.com, and click 'Complete setup'. For user UPNs and primary email addresses, you can edit them individually via Users > Active users, but PowerShell is recommended for bulk changes.

Run this to verify: Confirm the domain is active in the target tenant and user UPNs/SMTP addresses are updated.

Get-MsolDomain -DomainName "source.com" # Should show status as 'Verified'
Get-MsolUser -UserPrincipalName user@source.com | Select-Object UserPrincipalName, ProxyAddresses # Check UPN and email addresses

Step 6: Post-Migration Client Configuration & Refinements

After the migration and domain cutover, users will need to reconfigure their Outlook clients and address other service-specific changes. This step focuses on communicating these changes and guiding users through the necessary client updates to ensure they can access their migrated data in the new tenant.

# Connect to the Target Microsoft 365 tenant (Exchange Online PowerShell)
Connect-ExchangeOnline -UserPrincipalName admin@target.onmicrosoft.com -ShowProgress $true

# (Optional) Verify mailbox sizes to confirm data integrity post-migration
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select-Object DisplayName, TotalItemSize

# (No direct PowerShell for client-side configuration, but useful for tenant-wide settings)
# For example, ensure AutoDiscover DNS records are correctly pointing to the new tenant's M365 services.

• The majority of this step involves user communication and client-side actions.
• Outlook clients (2010 and above) typically require users to remove their existing Outlook profile and create a new one. AutoDiscover will then configure the client for the new tenant.
• Users should be instructed on how to clear their Auto-Complete List (nickname cache) in Outlook, as old entries may point to the previous tenant.
• Skype for Business (if still in use) will require users to re-add contacts as a new profile is created.
• Educate users on accessing Outlook on the web (formerly OWA) with their new credentials.

Portal alternative: No direct portal steps for client configuration. Focus on creating clear, concise end-user communication guides and FAQs.

Run this to verify: User feedback and successful access to their mailboxes and other services in the target tenant.

Step 7: SharePoint Content Modernization (Optional)

If your source tenant had classic SharePoint sites, especially those with wiki, web part, blog, or publishing pages, consider modernizing them in your new target tenant. Modern SharePoint pages offer enhanced user experiences, better performance, and tighter integration with other Microsoft 365 services. The SharePoint PnP Modernization framework, accessed via PowerShell, is the recommended approach for bulk page transformation.

# Install PnP PowerShell module (if not already installed)
Install-Module -Name PnP.PowerShell

# Connect to the SharePoint Online Admin Center of your Target tenant
Connect-PnPOnline -Url "https://target-admin.sharepoint.com" -Interactive

# Identify a classic site collection in your target tenant (e.g., after content migration)
$siteUrl = "https://target.sharepoint.com/sites/YourClassicSite"

# Connect to the specific classic site collection
Connect-PnPOnline -Url $siteUrl -Interactive

# Transform a single classic page to a modern page
# Example: Convert a wiki page named 'HomePage.aspx' in 'SitePages' library
ConvertTo-PnPClientSidePage -Identity "SitePages/HomePage.aspx" -Overwrite

# To transform multiple pages across a site, iterate through them (example conceptual)
# Get-PnPListItem -List "Site Pages" -Query "WikiPage" |
# ForEach-Object {
#     Write-Host "Transforming: $($_.FieldValues.FileRef)"
#     ConvertTo-PnPClientSidePage -Identity $($_.FieldValues.FileRef) -Overwrite
# }

• Install-Module -Name PnP.PowerShell: Ensures you have the necessary module.
• Connect-PnPOnline: Establishes a connection to your SharePoint Online environment. You'll typically connect to the admin center first, then to specific site collections for transformation.
• ConvertTo-PnPClientSidePage: This is the core cmdlet for transforming classic pages. -Identity specifies the page to transform, and -Overwrite replaces the classic page with its modern equivalent. For larger transformations, script iteration over multiple pages or lists is required.

Portal alternative: While page transformation itself is largely a PowerShell-driven process for bulk operations, you can manually create modern pages in SharePoint Online by navigating to a site, clicking 'New > Page', and rebuilding content. However, this is not feasible for large-scale modernization.

Run this to verify: Navigate to the transformed page in your browser. It should now render with the modern SharePoint user interface.