Les scénarios de migration inter-entreprise Microsoft 365 impliquent des workloads variés et interdépendants : Exchange Online, OneDrive for Business, SharePoint Online et Microsoft Teams doivent être traités de manière coordonnée pour éviter toute rupture de service. La gestion des identités via Azure AD / Entra ID et la configuration des paramètres cross-tenant access settings ajoutent une couche de complexité supplémentaire que les équipes IT doivent anticiper. Pour approfondir ces enjeux, consultez notre guide sur les meilleures pratiques de migration tenant-to-tenant Microsoft 365. Cet article détaille les outils natifs proposés par Microsoft — notamment le Microsoft 365 Migration Orchestrator — pour piloter une migration M365 native de manière maîtrisée, en comparaison avec les approches reposant sur des solutions tierces.
À retenir :
- La migration tenant à tenant de Microsoft 365 permet de transférer des données entre environnements sans solutions tierces, essentielle lors de fusions
- Le processus implique des charges de travail comme Exchange Online, OneDrive, SharePoint et Teams, nécessitant une coordination pour éviter les interruptions
- Le Microsoft 365 Migration Orchestrator gère les transferts, coordonne des phases et réduit les dépendances à des solutions manuelles
- Une bonne compréhension de la gestion des identités et des licences est cruciale pour une migration fluide et réussie
- Les migrations SharePoint et Teams présentent des limites, notamment la non-capture des historiques de chat et certaines configurations et permissions qui nécessitent une attention particulière
- La sécurité et la gouvernance doivent être intégrées dès le début, avec une mise en œuvre soignée des accès inter-tenant pour éviter les failles
Comprendre les fondations de la migration native Microsoft 365 tenant à tenant
Un tenant Microsoft 365 est une instance dédiée et isolée des services Microsoft, rattachée à une organisation via Azure AD / Entra ID. Chaque migration locataire Microsoft 365 commence par la maîtrise de cette unité fondamentale avant d’engager tout transfert de données ou d’identités.
Le tenant Microsoft 365 et son ancrage dans Entra ID
Un tenant représente l’environnement souverain d’une organisation au sein de l’écosystème Microsoft : il regroupe les identités, les licences, les boîtes Exchange Online, les sites SharePoint et les équipes Teams. Dans Azure AD / Entra ID, chaque tenant possède son propre annuaire d’objets (utilisateurs, groupes, applications). Lors d’une fusion, d’une cession ou d’une restructuration, les données doivent migrer d’un tenant source vers un tenant cible sans rupture de service. C’est précisément ce contexte qui justifie l’existence d’un outillage natif dédié. Pour approfondir le choix de la solution adaptée à votre contexte, consultez notre comparatif outils migration Microsoft 365 tenant à tenant.
Ce que permet le Microsoft 365 Migration Orchestrator
Selon Microsoft, le Microsoft 365 Migration Orchestrator permet aux organisations de déplacer les données utilisateur et les charges de travail entre des locataires distincts. (Source : Microsoft — 2025-12-15). Cet outil natif orchestre les transferts via la Microsoft Graph API, en coordonnant les phases de consentement, de provisionnement des identités cibles et de copie des données. Il offre une visibilité centralisée sur l’avancement des lots d’utilisateurs et réduit la dépendance aux scripts manuels ou aux solutions tierces.
Les modèles de migration disponibles
Le migration orchestrator Microsoft 365 prend en charge plusieurs modèles de migration, chacun adapté à un scénario organisationnel différent :
| Modèle | Cas d’usage typique | Caractéristique principale |
|---|---|---|
| Single-event | Fusion rapide ou basculement unique | Tous les utilisateurs migrent en une seule vague |
| Phased | Restructuration progressive par département | Migration par lots successifs sur plusieurs semaines |
| Tenant move / split | Cession d’une filiale ou scission d’entité | Déplacement ou séparation d’un périmètre délimité |
Le choix du modèle influence directement la planification des coupures de service, la gestion des coexistences de messagerie et la communication aux utilisateurs finaux.
Prérequis en licences pour une migration tenant Microsoft 365 native
La mise en œuvre des pré-requis migration native M365 inclut un volet licences souvent sous-estimé. Les utilisateurs concernés doivent disposer d’une licence Microsoft 365 E3 ou E5 sur le tenant source. Certaines fonctionnalités avancées du migration orchestrator, notamment la migration cross-tenant de boîtes Exchange Online et de contenus OneDrive, nécessitent des add-ons spécifiques de migration cross-tenant, distincts des licences de base. Il convient de valider ce périmètre en amont avec son gestionnaire de compte Microsoft ou son partenaire afin d’éviter tout blocage en phase d’exécution.
La compréhension de ces fondations techniques — tenant, orchestrateur, modèles et licences — conditionne la réussite de chaque étape opérationnelle, que nous allons détailler dans les chapitres suivants.
Gérer la migration des principales charges de travail (Exchange, OneDrive, SharePoint, Teams)
Chaque service Microsoft 365 suit une logique de migration distincte : Exchange Online, OneDrive for Business, SharePoint Online et Microsoft Teams nécessitent chacun des outils, des prérequis et des précautions spécifiques pour une migration tenant à tenant réussie.
Exchange Online : boîtes aux lettres, règles et délégations
La migration Exchange Microsoft 365 native repose sur des étapes bien balisées. Les boîtes aux lettres sont transférées via des lots de migration (migration batches) configurés depuis le Centre d’administration Exchange. Au-delà du contenu des boîtes, il est impératif d’exporter et de recréer manuellement les règles de transport, les délégations et les autorisations spécifiques : ces éléments ne sont pas portés automatiquement d’un tenant à l’autre. Selon Microsoft, la vérification de domaine implique une propagation DNS qui peut prendre jusqu’à 72 heures, ce qui oblige à anticiper les délais lors de la planification du basculement de messagerie (Source : Microsoft — 2024-05-20). Des licences appropriées doivent être attribuées dans le tenant cible avant le début du transfert.
OneDrive for Business : fichiers, partages et gestion des conflits
La migration OneDrive inter-tenant s’appuie sur la fonctionnalité Cross-Tenant User Data Migration, disponible depuis le Centre d’administration Microsoft 365. Cette approche permet de transférer le contenu des bibliothèques personnelles tout en préservant les métadonnées de base. Toutefois, les liens de partage existants sont invalidés lors du transfert : les utilisateurs doivent recréer leurs partages dans le tenant destination. Les conflits de noms de fichiers sont gérés par écrasement ou conservation selon le paramétrage choisi, et les fichiers OneNote peuvent nécessiter un traitement particulier. Une planification par vagues, en commençant par des utilisateurs pilotes, permet de détecter et corriger ces cas en amont.
SharePoint Online : SPMT comme outil de référence
Pour la migration SharePoint entre locataires, l’outil SharePoint Migration Tool (SPMT) constitue la solution native principale. Il prend en charge la migration de sites, de bibliothèques et de listes, avec un rapport détaillé des erreurs et des avertissements. SPMT supporte les sources on-premises (SharePoint Server 2010 à 2019) ainsi que les environnements SharePoint Online. Pour les scénarios complexes, Migration Manager complète SPMT en orchestrant les migrations à grande échelle depuis une interface centralisée. Il convient de noter que les permissions granulaires et les workflows SharePoint Designer ne sont pas migrés automatiquement.
Microsoft Teams : les limites des migrations natives
La migration Microsoft Teams représente le chantier le plus contraint dans un projet cross-tenant. Les outils natifs ne permettent pas de migrer l’historique des chats privés, les messages de canaux, ni les applications tierces installées dans les équipes. Seule la structure des équipes et des canaux peut être recréée, et les fichiers associés doivent transiter par SharePoint ou OneDrive. Les enregistrements de réunions stockés dans OneDrive ou SharePoint suivent le flux de migration des fichiers, mais les métadonnées de réunion restent perdues.
| Service | Outil natif principal | Éléments non migrés automatiquement |
|---|---|---|
| Exchange Online | Migration batches / EAC | Règles, délégations, signatures |
| OneDrive for Business | Cross-Tenant User Data Migration | Liens de partage, accès externes |
| SharePoint Online | SPMT / Migration Manager | Permissions granulaires, workflows |
| Microsoft Teams | Aucun outil complet natif | Historique chats, apps, messages canaux |
Après avoir passé en revue les capacités et les limites propres à chaque charge de travail, il est essentiel d’examiner comment la gouvernance et la sécurité doivent être intégrées dès la conception du projet pour éviter toute rupture de conformité lors du transfert entre tenants.
Architecture, sécurité et gouvernance dans les migrations cross-tenant
Réussir une migration tenant à tenant ne se limite pas au déplacement des données : la gouvernance cross-tenant M365 et la sécurité migration native Microsoft 365 doivent être intégrées dès la phase de conception. Identités, accès, audit et conformité constituent les quatre piliers d’une architecture de migration maîtrisée.
Gestion des identités avec Entra ID et synchronisation cross-tenant
Azure AD / Entra ID est le socle de toute migration cross-tenant. La fonctionnalité de cross-tenant synchronization permet de provisionner automatiquement les utilisateurs du tenant source dans le tenant cible, en maintenant la cohérence des attributs d’annuaire. Cette synchronisation bidirectionnelle facilite la coexistence temporaire des deux environnements et réduit les ruptures de service pour les utilisateurs finaux. Il convient de définir précisément les objets à synchroniser — utilisateurs, groupes, contacts — et de cartographier les attributs avant tout démarrage. Selon Microsoft, les licences Microsoft 365 E3/E5 ou équivalentes sont requises pour les locataires source et cible, y compris les add-ons spécifiques à la migration cross-tenant (Source : Microsoft — 2025-12-15).
Configuration des cross-tenant access settings et implications de sécurité
Les cross-tenant access settings dans Entra ID permettent de contrôler finement les flux d’authentification entre tenants : accès entrant (inbound), accès sortant (outbound), et confiance accordée aux revendications MFA ou à la conformité des appareils. Une mauvaise configuration de ces paramètres expose l’organisation à des accès non maîtrisés pendant la fenêtre de coexistence. Il est recommandé d’appliquer le principe du moindre privilège : n’autoriser que les utilisateurs, groupes et applications strictement nécessaires à la migration, puis révoquer ces autorisations dès la fin de la phase de transition.
| Paramètre | Portée | Recommandation |
|---|---|---|
| Accès entrant (Inbound) | Utilisateurs du tenant source accédant au tenant cible | Restreindre aux comptes de migration uniquement |
| Accès sortant (Outbound) | Utilisateurs du tenant cible accédant aux ressources source | Limiter à la durée de coexistence |
| Confiance MFA | Reconnaissance de la MFA inter-tenant | Activer pour fluidifier l’expérience utilisateur |
| Conformité des appareils | Confiance accordée aux politiques Intune du tenant source | Évaluer selon la politique de sécurité cible |
Surveillance et journalisation avec Azure Monitor et Log Analytics
La sécurité dans migration tenant à tenant repose sur une traçabilité exhaustive. Azure Monitor et Log Analytics permettent de centraliser les journaux d’activité liés aux synchronisations d’identités, aux connexions inter-tenant et aux opérations de migration. La création de tableaux de bord dédiés facilite la détection d’anomalies en temps réel. Il est conseillé de configurer des alertes sur les échecs de provisioning et les tentatives d’accès inhabituelles dès le lancement du projet.
Conformité et eDiscovery pendant la migration
Le Centre de conformité Microsoft Purview joue un rôle central dans l’audit et conformité migration cross-tenant. Les stratégies de rétention, les conservations légales (Legal Hold) et les requêtes eDiscovery doivent être reconfigurées dans le tenant cible avant la bascule définitive. Négliger cette étape peut entraîner des lacunes dans la chaîne de conservation des preuves, avec des implications juridiques et réglementaires significatives. Le chapitre suivant détaille les étapes opérationnelles et les outils natifs permettant d’orchestrer concrètement ces migrations.
Limites, bonnes pratiques et perspectives d’évolution des migrations natives
Les outils natifs Microsoft 365 couvrent efficacement les scénarios principaux de migration tenant à tenant, mais présentent des lacunes précises qu’il convient d’anticiper pour sécuriser chaque projet. Comprendre ces limites permet d’adopter les stratégies de contournement adaptées.
Cas non couverts par les outils natifs
Parmi les limites migration native Microsoft 365 les plus significatives, on note l’absence de prise en charge du Teams Chat historique : les conversations individuelles et de groupe ne sont pas migrées nativement entre tenants. De même, les applications tierces intégrées à Teams ou SharePoint (connecteurs, webhooks, solutions Power Platform personnalisées) nécessitent une reconfiguration manuelle dans le tenant cible. Les permissions complexes — notamment les partages externes granulaires sur SharePoint ou les groupes imbriqués dans Azure Active Directory — doivent être documentées et recréées, car elles ne sont pas transposées automatiquement. Enfin, certains objets Exchange, comme les dossiers publics ou les règles de transport avancées, peuvent exiger des scripts PowerShell dédiés pour compléter la migration.
Stratégies de coexistence et modèles de staged migration
Pour les projets de grande envergure, la coexistence entre tenants constitue une étape incontournable. Elle repose sur la mise en place d’un routage hybride des e-mails, d’une fédération de domaines et d’une synchronisation d’annuaires entre les deux environnements, le temps que la migration progresse par vagues. Selon Microsoft, les organisations peuvent choisir parmi plusieurs modèles : Single-Event Migration, Phased Migration ou Tenant Move/Split (Source : Microsoft — 2025-12-15). La staged migration Microsoft s’impose lorsque le volume de données ou la criticité métier imposent une transition progressive, permettant de valider chaque lot avant de poursuivre.
| Modèle | Cas d’usage | Complexité |
|---|---|---|
| Single-Event | Petit tenant, faible volumétrie | Faible |
| Phased Migration | Grande organisation, migration par vagues | Moyenne à élevée |
| Tenant Move/Split | Restructuration ou scission d’entités | Élevée |
Monitoring et validation post-migration
Le suivi de la migration ne s’arrête pas au transfert des données. Azure Monitor permet de centraliser les journaux d’activité et d’alerter sur les anomalies constatées dans le tenant cible. La validation post-migration doit inclure des tests fonctionnels par échantillon d’utilisateurs, la vérification de l’intégrité des permissions, la confirmation de la disponibilité des services Teams et SharePoint, ainsi que la conformité des stratégies de rétention. Des rapports issus de Microsoft Graph API peuvent automatiser la collecte de métriques clés pour objectiver cette phase de contrôle.
Perspectives d’évolution du Migration Orchestrator et des API Graph
Le Microsoft 365 Migration Orchestrator évolue régulièrement pour étendre sa couverture fonctionnelle, avec des améliorations attendues sur la gestion des identités et l’intégration d’autres charges de travail. Les API Microsoft Graph pour migration ouvrent des possibilités croissantes d’automatisation et de personnalisation des pipelines, renforçant les perspectives migration tenant-to-tenant pour les ESN et les grandes entreprises. Ces évolutions invitent à anticiper dès aujourd’hui une architecture de migration modulaire et extensible.
Conclusion
Les outils natifs Microsoft 365 offrent aujourd’hui un socle solide pour orchestrer une migration tenant-to-tenant sans recourir systématiquement à des solutions tierces. Maîtriser ce plan de migration Microsoft 365 repose sur trois piliers indissociables : une préparation rigoureuse de l’Azure AD / Entra ID source et cible, un licensing adapté à chaque phase, et un suivi continu des opérations via le Microsoft 365 Migration Orchestrator.
Selon Microsoft, un locataire représente l’organisation et son instance dédiée dans Microsoft Entra ID, ce qui en fait la fondation de toute migration cross-tenant sécurisée (Source : Microsoft — 2025-03-04). Ignorer cette réalité structurelle expose le projet à des erreurs de configuration difficiles à corriger a posteriori.
Pour les organisations confrontées à des scénarios complexes — fusions, cessions, réorganisations multisites —, s’appuyer sur un partenaire expert comme Eliadis permet de sécuriser chaque étape, du cadrage technique à la conduite du changement. Explorez nos comparatifs et guides sur les meilleures pratiques migration Microsoft 365 pour affiner votre stratégie et aborder votre projet avec méthode.
