Migration Microsoft Teams, sans les complications.

La fonctionnalité Copier Teams de ShareGate permet de migrer des Teams entre des locataires ou de déplacer des canaux entre des Teams. Vous vous connectez aux locataires source et destination, sélectionnez les Teams ou canaux que vous souhaitez migrer, puis choisissez ce que vous voulez inclure : les messages des canaux, les fichiers, les onglets, les applications, Planner et les membres.

Vous pouvez exécuter la migration immédiatement ou la planifier, et les copies incrémentielles sont prises en charge.

ShareGate migre les équipes standard, les canaux standard et privés, les conversations des canaux (publications et réponses), les fichiers dans les canaux Teams, les onglets et applications, les plans Planner, ainsi que les membres des équipes.

Ce qui n'est pas migré : les conversations de groupe, les conversations en tête-à-tête (la prise en charge est limitée et souvent réservée à PowerShell), les canaux partagés, ainsi que certains éléments de conversation tels que les réactions, les balises, les aperçus, les enregistrements et les artefacts de réunion.

ShareGate ne migre pas les comptes utilisateurs entre les locataires. Les utilisateurs doivent déjà exister dans le locataire de destination. ShareGate associe ensuite les utilisateurs sources aux utilisateurs de destination afin de préserver l'appartenance aux équipes Teams, les autorisations et les métadonnées liées aux utilisateurs.

Il recherche automatiquement les utilisateurs correspondants dans la destination en utilisant le nom de compte, l'adresse e-mail, le nom d'affichage et d'autres propriétés. Si la correspondance automatique ne trouve pas la bonne association ou si vous souhaitez un contrôle total, vous pouvez créer un fichier de mappage d'utilisateurs explicite (CSV ou SGUM) et le réutiliser pour plusieurs migrations.

Si un site SharePoint est connecté à une équipe Teams, ne le migrez pas séparément. Lorsque vous migrez une équipe Teams avec ShareGate, le site SharePoint associé et le groupe Microsoft 365 sont automatiquement inclus.
Migrer le site séparément revient à effectuer le travail deux fois.

Ne migrez les sites SharePoint séparément que s'ils ne sont pas connectés à Teams, comme les sites classiques ou les sites de groupe autonomes.

ShareGate migre les applications depuis le Teams App Store, mais les applications personnalisées ne sont pas prises en charge. Le comportement des onglets dépend du type. Certains onglets (comme Wiki et Flow) ne sont pas pris en charge ou nécessitent une reconfiguration après la migration. Les onglets Microsoft tels que Yammer, Power BI, Stream, Forms et Whiteboard fonctionnent uniquement lors d'une migration au sein du même tenant.

Les onglets tiers sont généralement copiés, mais les utilisateurs doivent habituellement se reconnecter et ajuster les paramètres. L'ordre des onglets et certains dossiers de stockage cloud de l'onglet Fichiers ne peuvent pas être conservés lors de la migration.

Les réunions Teams associées au calendrier de l'équipe ne sont pas migrées et doivent être recréées. Les appartenances aux groupes dynamiques sont converties en groupes statiques, ce qui nécessite une reconfiguration des règles dynamiques. Les paramètres propres aux utilisateurs, tels que les favoris, les photos de profil, le statut et les messages enregistrés, ne sont pas conservés.

De nombreux onglets et applications ne sont pas migrés ou nécessitent une reconnexion. Les onglets Flow/Power Automate, les onglets tiers et les applications personnalisées requièrent une reconfiguration manuelle. Les éléments de conversation tels que les réactions, les mentions « J'aime », les balises et les aperçus de messages ne sont pas non plus migrés.

La vitesse de migration dépend de plus que la taille des fichiers. Les facteurs les plus importants sont la limitation de Microsoft 365 et le volume d'appels API, qui sont davantage déterminés par le nombre d'éléments et la complexité des métadonnées que par les Go bruts. Le matériel, la latence réseau et l'emplacement de la machine ont également leur importance. Les caractéristiques du contenu aussi, comme les autorisations personnalisées, la gestion des versions, et les listes ou bibliothèques volumineuses.

Le compte utilisé pour exécuter la migration Teams doit être un administrateur général, ou combiner les rôles d'administrateur SharePoint et d'administrateur Teams. Il doit également détenir une licence Teams et s'être connecté à Teams au moins une fois — si le compte ne s'est jamais connecté, ShareGate ne pourra pas voir ni accéder au contenu Teams avec ce compte. Une étape supplémentaire importante est à noter : même en utilisant la combinaison administrateur SharePoint + administrateur Teams plutôt qu'un administrateur général, un administrateur général doit tout de même accorder son consentement à l'application Azure ShareGate sur le tenant. Il s'agit d'une étape unique, distincte des autorisations propres au compte de migration, qui doit être effectuée sur les tenants source et destination. Les utilisateurs de destination doivent simplement exister dans le tenant cible avec leur attribution M365 standard.

Canaux privés : oui, entièrement pris en charge. ShareGate migre les canaux privés ainsi que leur collection de sites SharePoint associée, les membres, les fichiers et les conversations. Canaux partagés (Microsoft Teams Connect) : non pris en charge. Si une équipe contient des canaux partagés, ces canaux sont ignorés lors de la migration — ils ne génèrent pas d'erreur, mais ils ne sont pas migrés non plus. Si les canaux partagés sont essentiels à votre migration, vous devrez les recréer manuellement à la destination et reconnecter les locataires externes concernés. Il s'agit d'une lacune connue et de l'un des obstacles les plus fréquents pour les organisations qui dépendent fortement de la collaboration entre locataires.

La migration incrémentielle de Teams vous permet d'effectuer un passage de suivi pour récupérer les modifications survenues depuis votre migration initiale — nouveaux messages, fichiers mis à jour, changements d'appartenance. Vous la déclenchez depuis l'écran du rapport de migration plutôt que de définir un mode en amont. Une limitation importante est à noter : les nouveaux canaux ajoutés à une équipe après la migration initiale ne seront pas récupérés automatiquement lors de la migration incrémentielle. Vous devez migrer ces nouveaux canaux en tant qu'opération autonome, puis les ajouter à l'équipe de destination. Il est également utile de savoir que, pour les équipes volumineuses avec des autorisations complexes au niveau des éléments, certains clients trouvent plus rapide d'effectuer une nouvelle migration sélective de contenu spécifique plutôt que d'exécuter une migration incrémentielle complète sur l'ensemble de l'équipe.

Pas pour le moment — les conversations privées et les échanges individuels entre utilisateurs sont hors périmètre. Les conversations de canaux (publications et réponses dans un canal d'équipe) sont bien migrées.

ShareGate a précédemment mené une version bêta pour la migration des conversations privées, mais y a mis fin car les API de Microsoft pour ce type d'opération sont trop limitées pour garantir une migration fiable et de haute intégrité — les contournements nécessaires pour la faire fonctionner n'étaient pas suffisamment robustes pour être proposés aux clients. La fonctionnalité figure dans la feuille de route et est en cours de reconstruction maintenant que l'API Microsoft Graph offre de meilleures options, mais aucune date de publication n'est confirmée.

Si la conservation de l'historique des conversations privées est une exigence absolue, prévoyez qu'elle soit hors périmètre et signalez-le aux parties prenantes dès le début du projet.

Un modèle utile tiré du terrain : excluez l'appartenance aux équipes de la migration initiale, puis incluez-la uniquement lors du dernier passage incrémentiel au moment du basculement. La raison est pratique — lorsque ShareGate ajoute des utilisateurs à l'équipe migrée, Microsoft envoie immédiatement des notifications à tous ces membres. Si le basculement est encore à plusieurs semaines, les utilisateurs finaux commencent à recevoir des alertes d'accès pour un tenant qu'ils ne devraient pas encore utiliser, ce qui crée de la confusion et peut parfois causer des problèmes. En reportant l'appartenance aux équipes à la migration de basculement, les notifications se déclenchent au bon moment et les utilisateurs arrivent proprement dans le nouvel environnement.