Microsoft Teams Migration, without the drama.

ShareGate's Copy Teams feature migrates Teams between tenants or moves channels between Teams. You connect to source and destination tenants, select the Teams or channels you want to migrate, then choose what to include: channel messages, files, tabs, apps, Planner, and membership.

You can run the migration immediately or schedule it, and incremental copies are supported.

ShareGate migrates standard teams, standard and private channels, channel conversations (posts and replies), files in Teams channels, tabs and apps, Planner plans, and team membership.

What doesn't migrate: group chats, one-to-one chats (support is limited and often PowerShell-only), shared channels, and conversation elements like reactions, tags, previews, recordings, and meeting artifacts.

ShareGate doesn't migrate user accounts between tenants. Users need to already exist in the destination tenant. ShareGate then maps source users to destination users to preserve Teams membership, permissions, and user-related metadata.

It automatically searches for matching users in the destination using account name, email, display name, and other properties. If automatic mapping doesn't find the right match or you want full control, you can create an explicit user mapping file (CSV or SGUM) and reuse it across migrations.

If a SharePoint site is connected to a Team, don't migrate it separately. When you migrate a Team with ShareGate, the associated SharePoint site and Microsoft 365 Group come with it automatically.
Migrating the site separately means doing the work twice.

Only migrate SharePoint sites separately if they're not connected to Teams, like classic sites or standalone group sites.

ShareGate migrates apps from the Teams App Store, but custom apps aren't supported. Tab behavior depends on the type. Some tabs (like Wiki and Flow) aren't supported or need reconfiguration after migration. Microsoft tabs like Yammer, Power BI, Stream, Forms, and Whiteboard only work when migrating within the same tenant.

Third-party tabs typically copy over, but users usually need to reconnect and adjust settings. Tab order and some Files tab cloud storage folders can't be preserved during migration.

Teams meetings tied to the Team calendar don't migrate and need to be recreated. Dynamic group memberships convert to static, so you'll need to reconfigure dynamic rules. User-specific settings like favorites, profile pictures, status, and saved messages aren't preserved.

Many tabs and apps either don't migrate or need reconnection. Flow/Power Automate tabs, third-party tabs, and custom apps require manual reconfiguration. Conversation elements like reactions, likes, tags, and message previews don't migrate either.

Migration speed depends on more than file size. The biggest factors are Microsoft 365 throttling and API call volume, which is driven more by item count and metadata complexity than raw GB. Hardware, network latency, and where the machine is located all matter too. So do content characteristics like custom permissions, versioning, and large lists or libraries.

The account running the Teams migration needs to be a Global Admin, or have both SharePoint Admin and Teams Admin roles combined. It also needs to hold a Teams license and must have signed into Teams at least once - if the account hasn't signed in before, ShareGate won't be able to see or access Teams content with that account. One important additional step: even when using the SharePoint Admin + Teams Admin combo instead of Global Admin, a Global Admin still needs to grant consent to the ShareGate Azure app on the tenant. This is a one-time step, separate from the migration account's own permissions, and needs to happen on both the source and destination tenants. Destination users just need to exist in the target tenant with their standard M365 assignment.

Private channels: yes, fully supported. ShareGate migrates private channels along with their associated SharePoint site collection, membership, files, and conversations. Shared channels (Microsoft Teams Connect): not supported. If a team contains shared channels, those channels are skipped during migration - they won't error out, but they won't come over either. If shared channels are business-critical for your migration, you'll need to recreate them manually at the destination and reconnect the relevant external tenants. This is a known gap and one of the more common blockers for organizations that rely heavily on cross-tenant collaboration.

Teams incremental migration lets you run a follow-up pass to pick up changes since your initial migration - new posts, updated files, membership changes. You trigger it from the migration report screen rather than setting a mode upfront. One important limitation: new channels added to a team after the initial migration won't be picked up automatically in the incremental. You need to migrate those new channels as a standalone operation, then add them to the destination team. Also worth knowing: for large teams with complex item-level permissions, some customers find it faster to do a fresh selective migration of specific content rather than running a full incremental across the whole team.

Not currently - private chats and 1:1 conversations between users are out of scope. Channel conversations (posts and replies within a team channel) do migrate.

ShareGate previously ran a beta for private chat migration but retired it because Microsoft's APIs for this type of operation are too limited to support a reliable, high-integrity migration - the workarounds required to make it work weren't good enough to ship to customers. The feature is on the roadmap and is being rebuilt now that Microsoft Graph API offers better options, but there's no committed release date.

If private chat history is a hard requirement, plan for it to be out of scope and flag it with stakeholders early.

A useful pattern from the field: exclude membership from the initial migration, then include it only in the final incremental pass at cutover. The reason is practical - when ShareGate adds users to the migrated team, Microsoft sends notifications to all those members immediately. If cutover is still weeks away, end users start receiving access alerts for a tenant they shouldn't be using yet, which creates confusion and sometimes breaks things. By deferring membership to the cutover migration, notifications fire at the right moment and users land cleanly in the new environment.