Office 365 Tenant to Tenant Migration: Step-by-Step Guide 2026

  

Published By Ashwani Tiwari

Approved By Tej Pratap Shukla

Published On September 1st, 2026

Reading Time 25 Minutes Reading

Do you know that, according to enterprise IT data, nearly 80% of enterprise migration projects fail or experience critical delays? Yes, and the primary reason behind them is poor planning. And a fundamental misunderstanding of cloud infrastructure.

The most common mistake IT admins make when performing an Office 365 cross-tenant migration is to interpret it as a basic “lift-and-shift”. It is not just about moving data. It’s about preserving metadata, version history, and user permissions without disturbing business continuity.

And since Microsoft 365 is a unified ecosystem, transferring workloads (Exchange, SharePoint, Teams) can be a high-stakes, intensive task. Seasoned IT professionals would agree on this.

So, be it mergers and acquisitions (M&A), divestitures, or corporate rebranding, check out this O365 tenant to tenant migration checklist. And conclude a secure Office 365 cross-tenant migration NOW!

What are the Types of Microsoft 365 Migrations?

Migrating Microsoft 365 from one tenant to another is not a uniform execution. Therefore, at an architectural level, tenant migrations are primarily of two execution types: Cutover and Phased.

The Cutover Migration:

A cutover migration refers to the process of moving the complete organization. Every mailbox, SharePoint site, and Teams channel is moved in a single, high-intensity event. It is an ideal solution for rapid spin-offs (Divestitures). Including small business acquisitions or rebranding efforts (low user count) to prevent Microsoft’s strict data throttling limits.

Technical Configurations:

• Extract the custom domain from all the objects in the source tenant. Also, remove it from the Source Microsoft 365 Admin Center. Validate it in the Target tenant within a 48-hour window.
• To force Outlook client profile rebuilds throughout the endpoints at the same time via Intune or Group Policy requires a large, automated script.

The Phased (Staged) Migration: 

A phased migration splits the user base into logical batches and moves them over several weeks or months. It is non-negotiable for enterprise M&A because consolidating a large number of users into a parent tenant over a single weekend is impossible. Due to the sheer volume of SharePoint and OneDrive data.

Technical Configurations:

• Execute an initial background sync. Move 90% of data (emails older than 30 days, orphaned OneDrive files) weeks before the user cuts over.
• To grant FreeBusyAccessLevel LimitedDetails and display calendar across the two environments, manually run the New-OrganizationRelationship PowerShell cmdlet in both tenants.
• The Target users are temporarily assigned the parent tenant’s default *.onmicrosoft.com routing address. This will continue until the final batch is finished. And the legacy domain can then be fully cut from the source.

Secondary Scenario Types to Consider:

• The M&A Consolidation:

• • Requires Entra ID mapping.
  • Matching parent company’s naming convention changes assigned users’ UPN (Unique Principal Name).
  • For mapping, rely on the source ObjectGUID or ExchangeGUID instead of the email address.

• The Divestiture (Carve-Out):

• • Complex migration.
  • Native Microsoft tools cannot split a shared Teams Channel or SharePoint Site Collection.
  • Use third-party tools such as PCVITA or SysTools to perform meticulous item-level migrations.

• Tenant Re-architecture (internal Rebranding): 

• • It is not a “lift and shift”.
  • Requires deploying strict Microsoft Purview data lifecycle policies (in the source tenant to remove redundant data before the sync starts).

Lastly, enterprise migrations do not fail because of poor tools. They failed because the wrong migration topology was implemented for the business requirement.

Manual vs. Native vs. Third-Party: Choose Your Migration Path

Choosing the right migration path (that aligns with the organizational needs and IT budget) is the most imperative architectural decision. And since IT admins are no longer restricted to just PowerShell scripts, they can choose native and third-party tools to transfer Office 365 tenants to another company.

Here is the side-by-side architecture comparison:

The Workload-by-Workload Strategy 

Microsoft 365 is not a single database. It is a complex network of interconnected workloads. Many IT admins skip this critical aspect of an Office 365 tenant to tenant migration and continue with a basic “lift and shift” approach at the enterprise level. Leading to migration failure.

Enterprise IT data reveals that over 1.83 million users were moved across 216 major M&A tenant migrations between 2023 and 2025 alone. And all the successful M365 cross-tenant migrations used a phased, workload-by-workload strategy. It prioritised identity mapping first, followed by isolated data transitions.

So, let’s see the architecture differences across Exchange, OneDrive, SharePoint, and Teams.

Phase 1: Identity & Entra ID. 

Identity is the cornerstone of the entire Office 365 tenant to tenant migration. When a user’s Entra ID identity is not mapped accurately, all workloads fail to transfer permissions. Resulting in orphaned files and bounced emails. 

Technical Requirement: 

• Every user, security group, and Microsoft 365 Group must be pre-created. And mapped one-to-one.
• Stamp the target users with the source user’s exact ExchangeGuid and ArchiveGuid.
• Avoid applying for a Microsoft 365 E3/E5 license until the cutover. Otherwise, it will prematurely provision an empty mailbox. And break the sync pipeline.

The Strategy: Before merging two Office 365 tenants, use Cross-Tenant Identity Mapping (CTIM). Also, must create target MailUser objects in the destination tenant.

Phase 2: Exchange Online (Mailboxes & Calendars)

Being the most critical workload, Exchange is migrated as the first active workload. The native cross-tenant mailbox migration runs inside the Microsoft cloud. In simple words, the data never uses the public internet.

Technical Requirement: 

• Requires the Cross-Tenant User Data Migration add-on license.
• Microsoft’s FastTrack cross-tenant migration preview asks for a minimum of 150 licenses for onboarding.
• Native tools don’t move publicDelegates. IT admins have to utilize Exchange Online PowerShell to manually restamp ‘Send on Behalf of and Full Access permissions (in the target tenant post-migration).

The Strategy: Use a pre-stage sync to transfer and move 90% of mailbox data in the background. Followed by a delta sync over the cutover weekend.

Phase 3: OneDrive for Business (Personal Content) 

To ensure shared links operate flawlessly for end users, OneDrive migrations natively drop a redirect URL in the source tenant. 

Technical Requirements:

• A single OneDrive account cannot exceed 5 TB of storage or 1,000,000 items (including files, versions, and folders). 
• The combined source file path, including the URL, cannot exceed 400 characters. Touching these strict limits causes silent migration failures.

The Strategy: Migrate OneDrive in batches of up to 4,000 accounts concurrently. And since OneDrive migrations are a “one-and-done” activity, incremental delta passes are not supported natively.

Phase 4: Shared Content (SharePoint & Teams)

SharePoint migrations are comparatively more intense than OneDrive. This is because they involve deeply integrated permission structures, metadata, and custom site templates.

Technical Requirement: 

• Migrating SharePoint natively mandates the Cross-Tenant Shared Data Migration License.
• It is sold per 100 GB of data and restricted primarily to Enterprise Agreement customers.
• Merging a source site into an existing target site natively is not allowed. 
• If the Service Encryption with Microsoft Pureview Customer key is active on the source tenant, the SharePoint migration will be hard-blocked.

The Strategy: To establish an organizational trust, run the Set-SPOCrossTenantRelationship cmdlet. Followed by Add-SPOTenantIdentityMap to confirm guest and external users retain access.

Phase 5: Platform & Endpoints

Microsoft Teams architecture is split into two distinct parts. The chat interface is a layer for data stored across Exchange (1:1 chats) and SharePoint (Channel files).

Technical Requirement:

• A full-fidelity Teams migration requires professional third-party tooling via Microsoft Graph API (such as PCVITA, SysTools, or BitTitan).

The Strategy: Migrate Teams in two different streams. Because the Microsoft 365 Migration Orchestrator can now manage 1:1 Teams chats. But it does not support migrating Teams Channels, Tabs, Planner Boards, or Apps.

Also Check Out: How to Export Emails from Office 365 to Excel?

Get-Mailbox -ResultSize Unlimited | Select-Object ExchangeGUID, ArchiveGUID, LegacyExchangeDN, UserPrincipalName, PrimarySMTPAddress, DisplayName | Export-Csv -Path "C:\SourceUsers.csv" -NoTypeInformation

Set-MailUser "user@targetdomain.com" -ExchangeGuid  -ArchiveGuid  -EmailAddresses @{Add="x500:"}

$AppId = ""
$Secret = ConvertTo-SecureString "" -AsPlainText -Force
Credential=New-ObjectSystem.Management.Automation.PSCredential(AppId, $Secret)
New-MigrationEndpoint -Name "CrossTenantEndpoint" -RemoteServer outlook.office.com -RemoteTenant "sourcedomain.onmicrosoft.com" -Credentials Credential-ExchangeRemoteMove:true -ApplicationId $AppId

Test-MigrationServerAvailability -Endpoint "CrossTenantEndpoint" -TestMailbox "user@targetdomain.com" 

New-MigrationBatch -Name "M&A_Batch_01" -SourceEndpoint "CrossTenantEndpoint" -CSVData ([System.IO.File]::ReadAllBytes("C:\MigrationBatch.csv")) -TargetDeliveryDomain "targetdomain.onmicrosoft.com" -AutoStart

Complete-MigrationBatch -Identity "M&A_Batch_01

The Ultimate Solution For a Fast & Secure Office 365 Tenant to Tenant Migration

Microsoft native tools are advancing, but it still comes with rigid limitations. Especially regarding bulk scaling, advanced data filtering, and comprehensive workload support. To deal with this, IT experts frequently advocate for a third-party, professional migration tool.

And currently, the PCVITA Office 365 to Office 365 Migration tool stands as the industry’s top migration utility. It is specifically designed to bypass the architectural limitations of native Microsoft tools. It promises a high-fidelity and highly automated bridge between Microsoft 365 tenants.

Download Now Purchase Now

Q.1: Can I move dozens of mailboxes simultaneously using PCVITA?

Yes, using its advanced Concurrent Migration, you can migrate up to 200 mailboxes simultaneously. Simply bypassing Microsoft’s strict data throttling.

Q.2: Does it have the ability to migrate only the newly arrived items?

Yes, it introduces an intelligent Delta Migration feature. This allows you to run an initial pre-stage sync, moving 90% of the historical data a week in advance. And scans the source tenant and migrates only newly arrived emails, calendar invites, and documents. 

Q.3: Can it re-run the failed items?

Absolutely yes! Unlike native tools that often fail a batch silently, PCVITA allows you to specifically re-run only the items that failed without duplicating existing data.

Q.4: Does PCVITA provide selective migration?

Indeed! It integrates Date-based and Category-based filters in this interface. You can use it to migrate only emails and documents created between specific dates. Or exclude complete categories (such as moving Emails and Contacts but leaving Tasks and Calendars behind).

Q.5: Can it fail to map users correctly?

No, this tool eliminates the manual GUID mapping and offers automatic user mapping. You can use the Fetch users feature to automatically fetch the Active Directory list from the source environment. Also, you can upload hard-coded CSV mapping files for intense rebranding scenarios (such as target UPN differs from the source).

Q.6: Does this migration tool preserve metadata and permissions?

Yes, it keeps the crucial metadata intact. Including the Read, Write, and Comment permissions on migrated documents.

So, stop replying to the complex PowerShell scripts. And choose the PCVITA ultimate tool for a secure Office 365 tenant to tenant migration in 2026.

Must Explore: Learn to Migrate Mail from cPanel to Office 365 Step by Step

Steps to Use PCVITA Software for Office 365 Tenant to Tenant Migration

Step 1. Run the software and select Office 365 as a source and destination from the main screen.

Step 2. Select items that you want to migrate from the Workload selection, such as emails, contacts, calendars, tasks, and documents. Including SharePoint Sites, Teams, and Groups. You can also use the Date filter option for selective data transfer. Also, enable the Migrate documents permission. Use the group mapping option for bulk user migration. Select the option according to your requirements. Then click on Next.

Step 3. Now, enter the source Admin Email and Application ID, then click the Validate button to validate permissions in order to perform Office 365 tenant to tenant migration step by step.

Step 4. Once the software validates the permissions. Then, Click on Next.

Step 5. Now, enter the destination Admin ID and Application ID, then click on Next.

Step 6. After the permission validation, click on the Next button.

Step 7. We have to create a mapping between Office 365 source users and destination users, to do this, the tool provides three options – Fetch users, Import users, and Download template. Select any of these options to perform tenant to tenant migration in Office 365.

Step 8. Now, mapping is successfully done. Click on the Validate button and proceed to the next step.

Step 9. After permission validation, click on the Start Migration button to perform tenant to tenant migration in O365 step by step.

As migration is completed, you can log in to the destination Office 365 tenant to access old tenant data.

Post Migration Checklist and Testing

Do you know what confirms a successful Office 365 tenant to tenant migration? A Post-Migration Checklist.

The respective phase holds utter significance because this is where IT administrators are required to manually rebuild the architectural dependencies. Ensuring that it does not traverse the Microsoft 365 cross-tenant migration tunnel.

And if these configurations are not addressed accurately, users in your organisation will encounter broken reply chains, missing calendar delegations, and Outlook profile corruption. 

#1: Migration Verification and Identity True-Up 

Verifying the migration is the first Office 365 tenant to tenant migration step. When the migration batch displays the Complete status, the Microsoft Orchestration engine cuts the connection to the source tenant. It automatically converts the target MailUser object into a fully licensed Mailbox. To audit the cross-tenant migration: 

Validate Move Request Success:

It is critical to confirm that the move request is completed without hidden data loss or skipped items. To identify success, run the following Exchange Online PowerShell command in the target tenant:

Get-MoveRequest -BatchName "CTM-Phase1" | Get-MoveRequestStatistics -DiagnosticInfo "verbose,showfailures" | Format-List DisplayName, Status, PercentComplete, BadItemsEncountered, LargeItemsEncountered

Also, you have to manually review the missing corrupt data if any mailbox has a BadItemsEncountered count higher than your approved threshold (usually 0-10).

License Reassignment

Whether it’s on-premises to cloud or cloud to cloud migration, migrating target users required the Cross-Tenant User Data Migration add-on license. However, you can remove this add-on to reclaim costs once the cutover is completed. It will strip the respective add-on and leave only the standard Microsoft 365 E3/E5 or Exchange Online Plan 2 license active.

#2: Mail Routing and DNS Validation

Email routing is probably the most visible part of a failure post-migration. So, you have to validate that external, internal, and legacy emails route correctly as MX Records are pointed to the target tenant.

Check Legacy X.500 Reply-ability:

To ensure the users in your organization do not receive a 5.1.1 NDR (Non-Delivery Report), test legacy X.500 Reply-ability. Usually, this issue occurs when the migrator or IT admin fails to map in the pre-migration phase, so that Outlook uses the LegacyExchangeDn attribute instead of the standard SMTP address. Resulting in triggering NDR when users reply to old internal emails.

To fix this, send a test email by replying to a thread created before the migration window in the source tenant.

DNS Propagation Check:

Confirm that your updated DNS records have completely propagated to the new tenant. To check that, open a command prompt and query the domain:

nslookup -type=mx targetdomain.com
nslookup -type=txt targetdomain.com

Also, make sure that the TXT records include the SPF string (v=spf1 include:spf.protection.outlook.com -all). It prevents outbound emails from being tagged as spam by external servers.

#3: Permission and Delegation Re-Stamping

As an IT administrator, you are required to manually restamp all the Shared Mailbox access, calendar delegations, and Send-As permissions. Because the native Microsoft cross-tenant migration engine does not migrate mail store permissions. Execute the following scripts in PowerShell:

#Re-apply Full Access Permissions:

Add-RecipientPermission -Identity "sharedmailbox@targetdomain.com" -Trustee "user@targetdomain.com" -AccessRights SendAs

#Re-apply Send-as Permissions:

Add-RecipientPermission -Identity "sharedmailbox@targetdomain.com" -Trustee "user@targetdomain.com" -AccessRights SendAs

#Re-apply Send on Behalf Of:

Set-Mailbox -Identity "executive@targetdomain.com" -GrantSendOnBehalfTo "assistant@targetdomain.com"

#4: Security and Compliance Alignment

If certain mailboxes are under an Office 365 Litigation Hold or Purview Retention Policy, they are likely excluded. Or have their holds temporarily bypassed to let the native migration proceed (as active holds restrict cross-tenant moves).

So, if a user is part of an active litigation, you must re-apply the hold in the target environment. For that, use this script in the target tenant Exchange Online PowerShell:

Set-Mailbox "user@targetdomain.com" -LitigationHoldEnabled $true -LitigationHoldDuration Unlimited

Also, if device management is also being migrated, instruct users to unjoin their Windows devices from the source Entra ID and re-enroll in the target Entra ID. And make sure your Conditional Access Policies (such as forcing MFA for off-network logins) are enabled for the newly populated user groups.

#5: End-User Client Reconfiguration 

Now that the tenant identity (GUID) has fundamentally transformed, the native Microsoft applications will fail to connect. Until they are removed from their old cache and reconfigured.

Outlook Profile Re-creation:

The newly created tenant can’t be identified by Outlook Desktop clients. Hence, you must force Outlook to drop the old Autodiscover cache and rebuild the profile. To initiate this, Instruct users to:

• Open the Windows Control Panel.
• Go to Mail (Microsoft Outlook).
• Click Show Profiles
• Create a net-new profile.

Additionally, to force this for enterprise environments, push the following  Registry Key using Intune or Group Policy: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles

Remove Microsoft Teams Cache: 

Users are often stuck in a login loop when trying to authenticate the old, now-decommissioned source tenant in Teams. To prevent this, direct the users to sign out of Teams completely. Clean the modern cache by deleting the contents of: %userprofile%\appdata\local\packages\msteams_8wekyb3d8bbwe. Lastly, relaunch and authenticate with the target environment credentials.

#6: Source Tenant Decommissioning

Decommissioning the source environment is the critical step for the organization. This ensures zero security vulnerabilities and duplicate billing post-migration. 

So, once the mail is flowing perfectly, permissions are restamped, and users are successfully working in the target tenant, interpret this as a signal to decommission. To execute this successfully:

• Remove the Custom Domain: Extract the custom domain (@company.com) from all remaining objects in the source tenant. Including resetting them to the default *.onmicrosoft.com routing address.
• Delete the Domain: Remove the domain completely from the Source Microsoft 365 Admin Center 
• Cancel Subscriptions: Cancel all source tenant licenses and start the data deletion process with Microsoft.

Common Challenges and Expert Solutions

It is a common phenomenon for IT administrators to encounter high-impact migration challenges during a Microsoft 365 cross-tenant migration -from Microsoft throttling limits, broken calendar visibility, and strict compliance barriers.

So, let’s check these issues in detail and the expert solutions to resolve them for a secure Microsoft 365 tenant to tenant migration.

#1: Microsoft Data Throttling (EWS & Graph API Limits)

Microsoft Throttling is a system-protection measure that deliberately limits the number of incoming API requests an app or user can make in a specific timeframe. Including connections and compute operations. This security framework is used by Microsoft to safeguard server health.

So when massive mailboxes or SharePoint sites are migrated from one tenant to another, Microsoft’s backend detects the jump in bandwidth. Resulting in throttling the migration service. This eventually slows down migration batches or fails completely with 429 Too Many Requests or 503 Server Too Busy errors.

The Expert Solution: Request a temporary lift of Exchange Web Services (EWS) throttling limits. To do so, you require a specific diagnostic workflow located in the Microsoft 365 Admin Center.

Important Note: When performing an Office 365 tenant to tenant migration, request it on both the source and target tenants. 

• Log in to Microsoft 365 Admin Center (as a Global Administrator).
• Click the Help & Support widget (green question mark) in the bottom right corner.
• Type the given diagnostic phrase in the search box: Increase EWS Throttling Policy
• Run the automated Throttling Policy.
• In the form, select the duration for the exception (usually 30, 60, or 90 days) >> Submit.
• Lastly, wait for 15 mins for the grant approval. Once activated, it will allow the migration tools to function at maximum throughput.

#2: Broken Cross-Tenant Free/Busy Calendar Visibility

Broken cross-tenant free/busy calendar visibility is a common challenge that IT admins come across when moving Office 365 to a new tenant. This issue typically occurs during the coexistence phase (the week when some users are in the target tenant and the rest in the source environment). Basically, users lose the ability to see colleagues’ availability (Free/Busy status) when scheduling messages. 

The Expert Solution: Establish a two-way Exchange Organization Relationship (using the Exchange Online PowerShell). Doing this will safely bridge the free/busy query feature across the two disparate tenants. So, use the given configuration in both tenants and swap the remote domain variables accordingly:

# Create the relationship pointing to the external tenant

New-OrganizationRelationship -Name "CrossTenant Coexistence" -DomainNames "targetdomain.com" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails

# Verify the relationship is active

Get-OrganizationRelationship | Format-List Name, FreeBusyAccessEnabled, FreeBusyAccessLevel

The setting –FreeBusyAccessLevel LimitedDetails will make sure that users can see the time, subject, and location of meetings. It clones the internal functionality without surfacing full meeting descriptions.

#3: Legal Holds Blocking Mailbox Migrations

If certain mailboxes and OneDrive accounts are subjected to an active Office 365 Litigation Hold or Purview Retention Policy, the native Microsoft Migration Orchestrator will completely block them from migrating to another tenant. The batch will immediately fail for those particular users.

The Expert Solution: Partner with the legal/compliance department and temporarily suspend the hold. Migrate the user and immediately restamp the hold in the target tenant. Keep in mind, you cannot force a migration through an active legal hold using native tools.

#Identify the Hold in the Source Tenant:

Get-Mailbox -Identity "user@sourcedomain.com" | Select-Object LitigationHoldEnabled, InPlaceHolds

Remove the Hold (Source):

Set-Mailbox -Identity "user@sourcedomain.com" -LitigationHoldEnabled $false

Next, allow the mailbox to sync and finalize to the target tenant. And re-apply the Hold (Target)immediately upon cutover to maintain compliance. To do so, run the given command:

Set-Mailbox -Identity "user@targetdomain.com" -LitigationHoldEnabled $true -LitigationHoldDuration Unlimited

#4: Orphaned Permissions and Unresolved SIDs

Do you know that if users are not perfectly mapped during the initial identity synchronization, they can lose access to shared files? Yes! This is because when moving SharePoint sites and OneDrive files, file permissions (who has access to a specific folder) are mapped using the user’s Unique ID. 

And when a user fails to map correctly during the initial synchronisation, they will lose access to shared files. And the file permissions will appear as a raw, unresolved SID (a string of numbers) instead of a username.

The Expert Solution: Avoid depending on UPNs (User Principal Names) to map file permissions. Because UPNs frequently change during rebranding migrations. Use Cross-Tenant Identity Mapping (CITM) and confirm that the target Entra ID objects are stamped with the source user’s exact ObjectGuid. 

Additionally, when executing a third-party tool (such as PCVITA, SysTools, or BitTitan) for Office 365 cross-tenant migration, always upload a hard-coded CSV mapping file before initiating a SharePoint or OneDrive data pass. The respective CSV file must link the source user@old.com to the target user@new.com.

And if permissions break post-migration, simply force a Delta Pass using the hard-coded identity map to overwrite the broken SIDs.

Final Words

Office 365 migration between tenants can be pretty tedious work if we use the conventional manual approach. Not everyone has enough technical knowledge to execute PowerShell scripts to perform the same. However, it can become an easy task if we use the right approach for it.

Hence, understanding the challenges faced by users, we have come up with a smart solution to perform data migration easily in O365. Using the above-mentioned tool, one can easily perform Office 365 tenant to tenant migration step by step, with 100% data security and integrity throughout the process.

People Also Find Helpful:

• How to Export Office 365 User List? – Simple Methods Revealed
• Migrate Public Folders to Office 365 Using the Best Solution
• How to Save Email from Office 365 Webmail to Desktop? Step-By-Step Guide
• How to Migrate from Rackspace to Office 365 (Microsoft 365)?
• Learn How to Export Office 365 Mailbox to PST Using Top 4 Solutions

FAQs (Frequently Asked Questions)

Q.1: Does Microsoft have a native tenant-to-tenant migration tool? 

Yes, Microsoft does provide a built-in Office 365 tenant to tenant migration tool called Microsoft Orchestrator. It can migrate Exchange mailboxes, OneDrive, and Teams chats. However, this native tool mandates a Cross-Tenant User Data Migration add-on license. It does not support moving SharePoint sites or Teams channels.

Q.2: How long does a tenant-to-tenant migration take? 

It entirely depends on the data volume. Typically, a Microsoft 365 tenant to tenant migration takes between 3 and 9 months. However, the actual data transfer varies. For example, migrating a 50GB mailbox takes roughly 1 to 2 days (under normal Microsoft throttling limits).

Q.3: What blocks a mailbox from migrating in Office 365? 

Mailboxes subjected to any type of Legal Hold or active Retention Policy block a mailbox from migrating in Office365. So, before migrating one Office 365 tenant to another, remediate the hold (with your legal department).

Q.4: Do SharePoint sites and Teams channels move automatically? 

Unfortunately, no! The SharePoint sites and Teams channels don’t move automatically and stay in the source tenant. Because the native tools handle individual OneDrive files and 1:1 Teams chats.

  

By Ashwani Tiwari

I am an Expert Technical Analyst, specialized in assisting users with complex technological challenges. Through my blogs and articles, I offer expert guidance to help tackle these technical issues effectively. My true passion lies in providing valuable insights and simplifying complicated technicalities, enhancing user understanding and confidence.

View all of Ashwani Tiwari's posts.