Migrating Microsoft Teams between tenants: a technical guide

What it means to preserve a team’s work in a new tenant

When migrating Microsoft Teams between tenants, the scope is defined by the experience required for each team. Retaining files, accessing past conversations, and maintaining continuity for meetings are related requirements, yet they rely on different components and methods. The proposal must specify what will remain available within the Teams interface, what will need to be rebuilt, and what will be preserved solely for reference or archival purposes.

Consider, for example, a project team that includes a standard channel, a private channel for management, and a tab displaying an internal application. A test that only copies documents from the standard channel fails to verify the permissions for the private channel or the connectivity of the application. The inventory must account for these distinctions, and the team owner should be involved in the pilot phase, as they are the only ones who can confirm whether the resulting environment supports their actual work needs.

Compliance-related data should not be conflated with the conversations visible to users. The existence of a data copy—intended for search or retention purposes—does not mean that the full history has been reconstructed as an active chat within the target tenant. To prevent any misalignment of expectations, it is advisable to demonstrate during the pilot where each type of content can be accessed and to document any agreed-upon differences.

How to assess Teams beyond just counting files

Functional testing begins with identities. An internal member, an owner, and a guest must test their access using their respective target accounts. The process verifies that they can open the intended channels and that they cannot view information belonging to other teams. This review uncovers issues that a migration report might miss—such as a guest with no corresponding account, or a group that grants access to more individuals than intended.

Next, the team’s typical activities are tested: opening and editing documents, reviewing conversations, using tabs, and joining meetings. Future meetings require a specific review of organizers and meeting links. If a function needs to be recreated or a meeting rescheduled, the person in charge must be notified before the cutover so they can communicate the change to both internal and external participants.

The acceptance record must link each test to a specific team and data set. File-related errors are referred to the appropriate SharePoint or OneDrive component, while access issues are investigated using the identity and permissions map. Documenting results in this way minimizes unnecessary re-testing and helps determine which issues are “blockers” for the transition and which can be resolved during the post-migration support phase.

What migrating Microsoft Teams between tenants really entails

A Microsoft Teams tenant-to-tenant migration This involves moving or rebuilding an existing Microsoft Teams collaboration environment within a different tenant. While the definition may seem straightforward, the actual scope can vary significantly. For one company, migrating Teams might simply mean recreating 30 teams, retaining their members, and moving the documents. For another organization, it may be essential to also preserve years of conversation history, private channels, Planner boards, guest access, 1:1 chats, future meetings, and integrated applications.

Consequently, the scope should be broken down element by element.

Do not use the term “full migration” without defining what it entails. The term can create unrealistic expectations. It is more precise to state, for example: “Migration of Teams structure, standard and private channels, memberships, SharePoint files, and channel conversations. Private chats will be handled via a separate process. Third-party apps and certain Planner elements will be evaluated during the assessment.”

In this way, the scope can be technically verified and functionally accepted.

Why Microsoft Teams is more complex than other workloads

Teams functions as a collaboration layer over various Microsoft 365 components. Consequently, a migration cannot be treated as a simple database transfer.

A simple example. Let’s imagine a Team called Financial Management. It contains: two standard channels, one private channel for management, documents with multiple versions, a Planner, a Power BI tab, three external guests, historical conversations, a OneNote, and members who have left the company. Migrating only the Microsoft 365 Group and the documents does not truly replicate the Teams experience.

Where Microsoft Teams stores its data

Channel files. Documents stored in Teams channels depend on SharePoint Online. This means that an issue such as: “the document does not appear in Teams” may actually originate from: SharePoint, permissions, the library, mapping, or document migration. Private and shared channels. These channels use a specific SharePoint architecture and should not be considered merely as additional folders within the main Team site.

For this reason, they must be explicitly included in the discovery phase. Files shared in chats. When a person shares a document in a Teams chat, that file typically resides in the OneDrive of the user who shared it. This has significant implications for a tenant-to-tenant migration. We might successfully migrate: “Take a look at this budget” but lose access to the file that accompanied the message if the OneDrive and its permissions have not been handled correctly.

Meetings and calendar. Meetings are linked to Teams, but also to Exchange Online and the organizer’s calendar. For this reason, Microsoft coordinates Exchange and Teams Meetings within its native user migration procedures. Messaging and compliance. Teams content may also have implications for: retention, eDiscovery, Legal Hold, Microsoft Purview, investigations, and regulatory requirements. Migrating operational Teams content and preserving evidence for compliance are related needs, but they should not be considered equivalent without conducting a specific analysis.

How to properly define the scope of a Teams migration

Before comparing Quest, Microsoft, BitTitan, or any other solution, it is advisable to complete a scope matrix.

Distinguish between “must-haves” and “nice-to-haves.” Not all components require the same level of fidelity. For example, a company might determine that: files and members are critical, conversations from the last 12 months are important, and older historical data only needs to be kept for reference. This decision can completely change the choice of tool, the cost, and the duration of the project.

What to inventory before migrating Microsoft Teams

The discovery phase should not end with a figure like: “We have 325 Teams.” That figure says very little about the actual complexity.

The inventory should serve as a basis for decision-making. The ultimate goal is not to generate an Excel file filled with data. Rather, it is to be able to classify each Team as one of the following: migrate, merge, archive, rebuild, or exclude.

Not all Teams should be moved to the new tenant

A corporate reorganization is often a good opportunity to reduce Microsoft Teams sprawl. Over time, the following can accumulate: Teams from completed projects, test environments, duplicates, Teams without an owner, inactive spaces, Teams created for a single meeting, guests who no longer collaborate, and applications that no one uses.

Migrating less can improve the project. Reduces: time, cost, volume, incidents, and obsolete objects in the destination environment.

Identity and user mapping

An identity map links each person and group in the source tenant to their corresponding object in the destination tenant. Simply comparing display names is not enough: two accounts might share the same name but represent different people, while a single individual might have changed their address during an organizational restructuring. The mapping file must rely on verified identifiers and include a designated person responsible for approving any exceptions.

This mapping affects members, owners, and permissions, and can also influence how content is assigned, depending on the migration method used. Before copying a Team, you must decide how to handle deleted users, employees who are not being migrated, and external guests. If an object lacks a valid match, you need to know how the migration tool will handle it and what alternative approach will be used for any associated content.

In the case of an acquisition, for example, the same person might have an account in both tenants. The project team must determine which account the user will continue to use, avoiding the automatic creation of a redundant account. The Team owner reviews the necessary access, while the administrator verifies the technical mapping. This coordination helps reduce duplicate permissions and prevents documents from being assigned to an identity that will ultimately go unused.

The pilot phase should include members, owners, and at least one relevant external user scenario. These accounts are used to verify access to the Team, its files, and any channels with unique permission settings. Once the testing is complete, the identity map used is retained alongside the migration report. If a permissions error occurs, this evidence allows for investigating the specific issue without having to repeat the entire copy process.

Standard, private, and shared channels

The three channel types should not be grouped together in the same project column. Standard channels. These use the general Team membership, and their files are stored within the associated SharePoint site. They are typically the simplest scenario. Private channels. These have their own distinct membership. A user might belong to the Team but not to a specific private channel. Therefore, after migration, we must verify at least the following: Channel, members, owners, files, SharePoint, and conversations.

Shared channels. Shared channels are designed for collaborating with individuals without necessarily adding them to the entire Team; they can also facilitate cross-organizational relationships via Microsoft Entra B2B Direct Connect. In tenant-to-tenant scenarios, they require particularly careful review.

API support does not equate to a complete migration. Microsoft Graph currently allows for the import of historical messages into standard, private, and shared channels. This means an API exists for the messaging component. It does not automatically mean that: structure, SharePoint, membership, external collaboration, tabs, apps are migrated simply by using that API.

Channel files: SharePoint is part of a Teams migration

If we want a Team to remain useful, we typically need its documents. Validation should go beyond just counting files.

Native SharePoint and Teams are two different things. Microsoft currently offers native cross-tenant migration for SharePoint. This may be relevant for certain sites associated with Teams. However, moving the SharePoint site does not automatically move: the Team, channels, conversations, apps, or chats.

Chat files: don’t forget OneDrive

This is one of the most common mistakes. The conversation may be preserved, but the associated document might not function as the user expects. Example. At the source: Ana: “Here is the updated contract.” File: contract.docx. The message belongs to the chat. The file may depend on Ana’s OneDrive. If we only migrate the conversation, we might end up with: Ana: “Here is the updated contract.”

File: Access denied. Migration order. When the technology used requires it, it may be necessary to migrate OneDrive before the chat so that links can be correctly reconstructed. Validate from within Teams. It is not enough to simply verify that: contract.docx exists in the destination OneDrive. You must also verify that the user can open it from within the context of the migrated conversation, if that is part of the expected user experience.

Migrating channel conversations

Channel posts are arguably one of the elements where Microsoft Graph has evolved the most. What is important to preserve.

Do not confuse “retained information” with “identical appearance.” Essential content may remain available even if certain visual or interactive components do not appear exactly the same. Such differences should be verified during the pilot phase and communicated prior to a mass migration.

Microsoft Graph Migration APIs in 2026

Microsoft has made significant advancements in the APIs designed for importing Teams history. Migration mode. A chat or channel can be temporarily placed into a specific “migration mode” to allow for the controlled import of history. The conceptual workflow is: startMigration → importMessage → completeMigration. Application ownership of the session. The application that initiates “migration mode” must maintain control of the session until it is complete. This is not a process where multiple tools can simultaneously import data into the same thread.

Permission. The application uses the following application permission: Teamwork.Migrate.All …along with any additional permissions required to create or manage the corresponding structures. Channels supported by migration mode.

Chats supported.

Existing channels and chats. A significant improvement over the current architecture is the ability to import historical content into specific, pre-existing chats and channels, provided that the conditions for “migration mode” are met. Original author. Microsoft allows you to define the author of an imported message. The represented user must be correctly associated with the tenant where the import is taking place, which makes identity mapping critical.

Historical timestamp. It is also possible to set a createdDateTime timestamp for historical data, subject to the conditions defined by the API. Among other restrictions, the timestamp must comply with the temporal and uniqueness rules established by Microsoft. What can be imported. Current APIs support various rich conversation elements, such as replies, mentions, emojis, certain visual elements, and reactions. However, API support only defines what is technically feasible.

The final experience ultimately depends on: what the tool implements, how it handles mapping, which exceptions it manages, and the specific object being migrated. Official reference: Microsoft Graph – Import messages into Teams chats and channels.

1:1 private chats and group chats

Private chats should be treated as a distinct workload within the project. Distinctions must be made between: internal 1:1 chats, internal group chats, deleted users, non-migrated users, external users, federated users, files, images, and meeting chats. A single user can have thousands of messages spread across many conversations. For this reason, the volume of chats can have a very different impact compared to the number of Teams.

A company with 20 Teams and 500 users may have a significantly higher chat volume than one with 100 Teams and 50 people. Active chats vs. archived history. Some tools allow for different strategies: Interactive history within Teams, with older history archived for reference. This can be useful when maintaining every message as an active thread is not a business requirement.

Deleted users. Chats containing deleted employees require specific validation. Not all tools can reconstruct the exact original membership or represent the historical user in the same way.

Meeting chats are a unique case

It is advisable not to automatically include these in “group chats.” Migration mode APIs for 1:1 and group chats do not function the same way as they do for meeting chats. If preserving conversations linked to meetings is a requirement, this must be explicitly addressed in the assessment of the technology being used.

What happens to Teams meetings

Future meetings are one of the components with the greatest impact on the user. Why they are different. A meeting is associated with: An organizer, an Exchange calendar, Teams, attendees, a tenant, and a link. The event and the link are not equivalent concepts. Retaining a calendar item does not automatically guarantee that an existing meeting will behave exactly like a new meeting organized from the identity of the target tenant.

Migration Orchestrator. Microsoft currently offers a specific workload for Teams Meetings within Migration Orchestrator. Microsoft coordinates this workload with Exchange, which further demonstrates the dependency between the two services. What to test.

Microsoft Migration Orchestrator: what it actually migrates

Microsoft provides Migration Orchestrator to coordinate certain user workloads during tenant-to-tenant migrations.

What it does NOT mean. This table should not be interpreted as: “Microsoft is already migrating entire Teams from one tenant to another.” Data shared outside the user scope. Microsoft documents items outside of this scope—such as shared Teams, channels, and SharePoint sites—under “Cross-Tenant User Data Migration.” Therefore, we need to consider two perspectives:

There are no native OneDrive deltas in this model. Native cross-tenant OneDrive migration functions as a “move” operation and does not support traditional incremental passes. This may impact the overall project design. Experience after migrating chats. Microsoft warns that changes to the participant list may occur, and in certain scenarios, duplicate threads may appear between the source and destination.

Following the move, the user should work using their destination identity, in accordance with the established procedure. Official reference: Microsoft – Migration Orchestrator.

Native cross-tenant SharePoint migration

Microsoft also provides a separate feature for moving SharePoint sites between tenants. This may be relevant because Teams files rely specifically on SharePoint. However, this does not constitute a full migration of Teams. We can move the content of the associated site, but that alone does not recreate the Team, channels, conversations, chats, Planner, tabs, or apps. Identity mapping.

A native SharePoint migration also requires mapping source identities to their corresponding identities in the destination environment. One-and-done. Much like the native cross-tenant model for OneDrive, this should not be approached as a traditional migration process involving pre-migrations and delta syncs. Official reference: Microsoft – Cross-tenant SharePoint migration.

Planner, OneNote, Forms, and Power Platform

A Teams migration might seem straightforward—until you start looking at the tabs.

Planner warrants special attention. Just because a tool indicates “Planner migration,” it does not necessarily mean that all its fields and metadata will be preserved exactly as they were. During the pilot phase, it is advisable to verify: tasks, assignments, labels, checklists, attachments, comments, and dates. Power Platform has its own architecture. A Power App tab within Teams does not mean that the application itself is stored inside the Team. Migrating the Team does not automatically transfer the entire Power Platform environment.

Tabs, apps, and bots

An inventory of Teams should include installed applications. Common types include: Microsoft apps, apps from the Teams Store, custom apps, bots, webhooks, connectors, website tabs, and LOB (line-of-business) apps. What might change when moving between tenants. An application may depend on: App registration, enterprise application, consent, secrets, Graph permissions, URLs, APIs, and databases. Simply recreating the tab is not enough. The tab might appear to be present, yet the application may fail to function because: the new tenant lacks the necessary consent, the user does not have a license, or the backend expects a different tenant ID.

Guests and collaboration external

Guest accounts should be reviewed before migration. There is little value in migrating hundreds of guest accounts associated with projects that ended years ago. For each guest: Ask: Do they still require access? If they do, keep them. Review:

Shared channels require special attention. A B2B Direct Connect relationship with another organization may exist. Moving a Team to a new tenant changes one of the endpoints of that relationship and may require additional configuration with the external organization.

What tools are available for migrating Teams between tenants?

As of 2026, there are native Microsoft capabilities as well as various specialized solutions available. The choice should be made following a discovery phase. There is no single tool that is universally the best for every tenant.

Quest On Demand Migration

Quest On Demand Migration It is specifically geared toward Microsoft 365 tenant-to-tenant projects and allows for the handling of multiple workloads from a single platform. For Teams. Quest provides processes for: discovery of Teams and Groups, assessment, mapping, provisioning, Teams migration, re-migration, and the migration of chats and related content. Chats. Quest enables the discovery and migration of chats between correctly matched users. This makes user matching a fundamental requirement once again.

OneDrive and chat files. Quest explicitly states that images, documents, and certain items linked within chats depend on OneDrive. Therefore, the project design must coordinate both OneDrive and chat migration. An advantage for multi-workload projects. This can be particularly relevant when Teams is not the only component involved, and the project also includes: Exchange, OneDrive, SharePoint, Groups, Teams, and chats. However, an assessment is still required.

No platform eliminates the need to review the following: apps, Planner, deleted users, external users, special channels, recordings, and unsupported items. Official documentation: Quest – On Demand Migration User Guide.

BitTitan MigrationWiz

MigrationWiz Offers a “Teams-to-Teams” solution and currently handles certain private chat scenarios as a separate, specific project type. Why it matters. We should not assume that: “we have a Teams Migration license” automatically includes: Teams, channels, files, and private chats. Private chat. BitTitan maintains specific documentation for Teams private chat projects. Concurrency limits, migration apps, endpoints, and requirements have recently changed; therefore, they must be verified against the current documentation before starting the project.

Official documentation:

• BitTitan – Microsoft Teams Migration Guide
• BitTitan – Teams Private Chat Migration Guide

Cloudiway

Cloudiway Provides a SaaS-based solution for tenant-to-tenant Microsoft Teams migration. Depending on the configuration and component, its documentation covers: Teams, channels, memberships, channel conversations, files, Planner, permissions, and private channels. Teams Import APIs. Cloudiway uses Microsoft Teams/Graph APIs to inject specific conversations while preserving available metadata. Preprocessing. The procedure includes a preliminary phase designed to prepare the destination Teams and channels before the actual transfer begins.

Delta. Cloudiway provides delta mechanisms for certain items; however, behavior may vary depending on whether the Team has been closed and which metadata is to be preserved. Private chats. 1:1 chats are handled via a specific process separate from the main Team migration. Always consult the current documentation. Cloudiway offers various technical and product-related pages, and the scope of its capabilities has evolved over time.

Before providing a quote for a specific feature, it is advisable to check the latest guide and conduct a pilot. Official documentation: Cloudiway – Cross-Tenant Microsoft Teams Migration Guide.

ShareGate

ShareGate It has a particularly strong focus on SharePoint and Teams, enabling the copying of Teams and channels between environments. Currently, it covers: Includes, among other elements: Teams, standard channels, private channels, channel conversations, files, tabs, compatible apps, Planner, memberships, and associated SharePoint sites. Incremental copy. ShareGate allows for certain incremental migrations for Teams that have already been migrated using compatible versions of their product. Shared channels. A particularly significant limitation noted in their current documentation is that shared channels are not supported by ShareGate Migrate.

If these are critical to the project, we will need to consider recreating them or using a different technology. 1:1 and group chats. Furthermore, the channel conversations that ShareGate can handle should not be confused with the overall history of users’ private chats. Official documentation:

• ShareGate – Microsoft Teams Migration
• ShareGate – Copy Teams limitations

Practical comparison of tools

The following table is not intended to replace a technical review of the current version of each product. It serves to illustrate why the choice depends on the project scope.

Don’t make your choice based solely on a checklist. Two different vendors might both state: “Conversations: Supported” …yet offer very different experiences. One tool might migrate: author, date, replies, and reactions, while another might only preserve: text and author, or archive part of the history outside of Teams. The ultimate test is a pilot. Using your company’s actual content.

Which strategy to choose

Recommended process for migrating Microsoft Teams between tenants

1. Discovery. Discover: Teams, Groups, channels, owners, members, guests, files, conversations, apps, Planner, activity. 2. Classification. Decide: migrate, merge, archive, exclude. 3. Scope. Explicitly define what happens with: Standard, private, and shared channels, conversations, chats, meetings, apps, and Planner. 4. Identity mapping. Link source and destination accounts. 5. Tool selection. Only after understanding the content. 6. Prepare the destination tenant. Create or configure: users, licenses, domains, policies, migration apps, consents, and guests, where applicable.

7. Pilot. Use representative Teams. 8. Correct the design. Document: errors, limitations, expected differences, actual timelines. 9. Premigration. Where the tool allows, migrate content in advance that does not need to wait for the cutover. 10. Waves. Group users and Teams based on logical relationships. 11. Delta. Where supported by the chosen method, incorporate changes that occurred after the pre-migration phase. 12. Cutover. Coordinate with: identity, Exchange, OneDrive, domain, users.

13. Validation. Perform technical and functional verification. 14. Hypercare. Maintain enhanced support during the agreed-upon post-migration period. 15. Closure. Remove: migration apps, temporary permissions, coexistence configurations, and licenses that are no longer needed.

How to design an effective Teams pilot

A pilot consisting of only one Team with two channels and ten documents has little value. It must reflect the actual complexity.

The pilot must be functional. It is not enough for IT to confirm: “all jobs are green.” An owner should open the Team and verify how it actually functions.

Pre-migrations and deltas: be careful when mixing tools

Not all methods allow for the same pattern. Specialized tools. Many allow for: initial copy → incremental → final pass. Microsoft cross-tenant OneDrive. Does not support traditional delta passes. Microsoft cross-tenant SharePoint. This should also be treated as a move, rather than following the traditional pre-migration model. Microsoft Graph migration mode. Its behavior depends on the migration session for the channel or chat. Do not design the schedule before choosing the technology.

Saying: “We will perform a pre-migration one month in advance, followed by three delta syncs,” without having decided on the technology, can result in an unfeasible plan.

Phased migration and coexistence

In large organizations, we likely will not migrate everyone on the same day. Group users who collaborate with one another. A migration wave based solely on the organizational chart can be problematic. For example: The Sales team works continuously with Pre-sales and Marketing. Migrating only the Sales team may create more friction than migrating all three related groups together. During the coexistence phase. We may need: external access, B2B, shared channels, SharePoint access, mail routing, and free/busy availability.

Coexistence is not the same as migration. Allowing a user from tenant A to collaborate with a user from tenant B does not move their Teams. There must be an end date. If the goal is to consolidate into a single tenant, it is best to avoid a permanent state of: duplicate users, guest accounts, cross-tenant dependencies, double licensing, and fragmented Teams.

The Teams cutover

Teams must be coordinated with the rest of the user experience. In a comprehensive project, this may coincide with: a UPN change, domain migration, Exchange mailbox move, OneDrive, a new Teams setup, a new tenant, an Office session change, and Intune or device-related changes. Users do not think in terms of “workloads.” A user is not going to say: “I have a SharePoint migration issue related to a Teams interface.”

They will say: “I can’t open the file in my channel.” Support teams must be prepared to diagnose the underlying service.

How to validate Teams after migration

Validation should include three levels. 1. Quantitative.

2. Technical. Check: errors, warnings, permissions, mapping, version history, links, external users, and apps. 3. Functional.

A “Completed” job does not constitute acceptance. It means the tool has finished the requested process. It does not necessarily mean that the user has the exact experience defined in the scope.

Communicating the change to users

Teams is a highly visible product. Communication must explain the differences that the individual will actually perceive. Before the change. Inform the user about: the date, the new tenant, which chats will be retained, which Teams will be migrated, which Teams will be archived, what happens to meetings, what happens to guests, and what the user needs to do. After. Explain: how to access the correct tenant, where to look for Teams, what to do if a Team is missing, what to do if a link does not work, and where to request support.

Do not hide known limitations. It is better to communicate: “Certain applications will need to be re-authorized” before the change, rather than letting the user discover it during an important meeting.

Common mistakes when migrating Microsoft Teams

Checklist for a tenant-to-tenant Teams migration

Frequently asked questions about migrating Microsoft Teams between tenants

Does migrating Teams files mean the entire team has been migrated?

No. Files reside in SharePoint or OneDrive, depending on the context, while conversations, members, channels, apps, and meetings have different requirements. The scope must outline each component and how it will be made available. Testing with a team owner helps verify whether the migrated set is sufficient for continuing work.

Are chats and conversations preserved exactly as they were in the source?

This depends on the workload, the method used, and the capabilities supported by the tool. Before committing to or executing the project, you should verify how the history will appear in the destination and what limitations may affect accessing it. An archival file or a compliance copy is not necessarily the same as a chat reconstructed within the user interface.

Why is it necessary to review external guests?

Guests require a valid identity and permission structure in the destination environment. Simply copying documents does not guarantee that they will be able to access them using the expected account. The pilot phase must include the external use cases relevant to the company, while also verifying that access is not granted to more content than is strictly necessary. Pending invitations and communications are part of the change management plan.

What should the acceptance process for a Teams migration include?

Access, members, owners, channels, files, and all in-scope features—along with any agreed-upon exceptions—must be verified. It is advisable to test relevant meetings and applications with the target users. The acceptance record should document the team being reviewed, the testing performed, the results, and the person responsible for addressing any issues; this ensures that acceptance is not based solely on the technical completion of the data copy process.

Final recommendations: migrating Teams means coordinating its entire ecosystem

The migration of Microsoft Teams between tenants is more feasible today than it was a few years ago. Microsoft has expanded the capabilities of Microsoft Graph to allow for the import of chat and channel history—including standard, private, and shared channels—as well as 1:1 and group chats. Furthermore, Migration Orchestrator provides a native layer for coordinating personal user data, such as Exchange, OneDrive, Teams chats, and Teams meetings.

However, none of these advancements turn Teams into a single, easily portable unit. Teams and channels remain distinct from a user’s private chats. Documents rely on SharePoint and OneDrive, while meetings depend on Exchange. Shared channels may involve cross-organizational relationships. Planner and OneNote are independent services, and applications may rely on app registrations, specific permissions, and external services.

Therefore, the first decision in a project should not be: “We will use Quest, BitTitan, ShareGate, or Microsoft.” It should be: “This is exactly what exists, and this is exactly what we need to preserve.” From there, we can determine which technology is the right fit. For some projects, simply moving structures and files may suffice. In others, chat history is critical. For some organizations, Planner is essential. In others, the main challenges involve private channels, guests, or applications.

The most robust procedure typically follows a clear sequence: discovery → cleanup → scope definition → mapping → tool selection → pilot → pre-migration → waves → cutover → validation → hypercare. And there is one final, particularly important point: A migration should not be considered complete the moment the tool finishes copying the data. It is complete only when users can log into the new tenant, locate their workspaces, access the documents they need, review the historical data included in the scope, use the required applications, and continue collaborating with the right people.

That should be the true criterion for success.

Recommended official documentation

Microsoft 365 tenant-to-tenant.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator overview
• Microsoft – Running a Migration with Migration Orchestrator

Microsoft Teams and Graph Migration APIs.

• Microsoft Graph – Import messages into Teams chats and channels
• Microsoft Graph – channel: startMigration
• Microsoft Graph – channel: completeMigration
• Microsoft Graph – chat: startMigration
• Microsoft Graph – chat: completeMigration
• Microsoft – Import external messages to Teams

Teams, SharePoint, and OneDrive.

• Microsoft – File storage in Microsoft Teams
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Microsoft Purview and Teams.

• Microsoft Purview – Find Teams content with eDiscovery

Quest On Demand Migration.

• Quest – Microsoft Teams Migration
• Quest – On Demand Migration User Guide

BitTitan MigrationWiz.

• BitTitan – Microsoft Teams Migration Guide
• BitTitan – Teams Private Chat Migration Guide

Cloudiway.

• Cloudiway – Cross-Tenant Microsoft Teams Migration Guide
• Cloudiway – Teams 1:1 Chat Migration

ShareGate.

• ShareGate – Microsoft Teams Migration
• ShareGate – Copy Teams limitations