Fusion, scission, rachat, séparation : la migration tenant-to-tenant Microsoft 365 est un exercice à risque. Méthode éprouvée, points de vigilance et retour terrain sur un projet de 4 000 utilisateurs.
Quand une migration tenant-to-tenant devient inévitable
La migration tenant-to-tenant Microsoft 365 n'est jamais un projet qu'on lance par envie : c'est presque toujours une conséquence d'un événement d'entreprise. Fusion, acquisition, scission, sortie d'un groupe, restructuration, rebranding majeur, ou consolidation après plusieurs années de croissance par acquisition.
Contrairement à une migration on-premise vers M365 - où l'outillage Microsoft est mature et bien documenté - la migration entre deux tenants Microsoft 365 reste un exercice à risque. Microsoft ne fournit pas d'outil natif complet : il faut combiner plusieurs solutions tierces et accepter des compromis sur certaines fonctionnalités (Teams chat history, OneNote shared notebooks, certaines métadonnées SharePoint).
Les 6 phases d'une migration tenant-to-tenant réussie
Quelle que soit la taille du projet - de 50 à 50 000 utilisateurs - nous structurons systématiquement la migration en six phases. Sauter une phase, c'est garantir un incident majeur.
- Phase 1 - Cadrage et inventaire (2 à 4 semaines) : audit des deux tenants, cartographie des objets à migrer (boîtes aux lettres, sites SharePoint, équipes Teams, OneDrives, groupes de sécurité, comptes de service, applications enregistrées).
- Phase 2 - Architecture cible et choix d'outils (1 à 2 semaines) : décision sur l'identité (cohabitation, fusion AD, AD Connect cible), choix de l'outil de migration principal (BitTitan MigrationWiz, Quest On Demand Migration, ShareGate, Avepoint Fly), définition du calendrier de bascule DNS.
- Phase 3 - Coexistence et pilote (2 à 4 semaines) : mise en place du free/busy cross-tenant, du routage SMTP partagé, du domaine de routage intermédiaire, migration pilote sur 20 à 50 utilisateurs représentatifs.
- Phase 4 - Vague principale (2 à 8 semaines selon la taille) : migration par vagues de 100 à 500 utilisateurs, généralement pendant les fins de semaine. Bascule des MX records une fois la dernière vague terminée.
- Phase 5 - Cleanup et hand-over (2 à 3 semaines) : suppression des objets source, suppression des partages cross-tenant, sécurisation finale du nouveau tenant, transfert documentaire.
- Phase 6 - Support post-migration (4 à 6 semaines) : helpdesk renforcé, accompagnement des cas edge, résolution des items non migrés (souvent 1 à 3 % du volume).
Les outils et leurs limites
Aucun outil ne fait tout. Voici la combinaison que nous utilisons selon le contexte :
BitTitan MigrationWiz est notre choix par défaut pour les boîtes aux lettres Exchange et OneDrive : robuste, scriptable, bonne gestion des erreurs. Faiblesse : Teams et SharePoint.
Quest On Demand Migration ou ShareGate sont supérieurs pour SharePoint avec préservation des métadonnées, versions, permissions héritées. ShareGate est aussi plus accessible budgétairement pour les PME.
AvePoint Fly couvre Teams de bout en bout, y compris l'historique de chat (limité aux 30 derniers jours côté Microsoft API) et les onglets.
Pour l'identité, AD Connect cible doit être planifié dès la phase 2. Si fusion AD on-premise, prévoir 4 à 8 semaines supplémentaires pour le forest restructure (ADMT, Quest Migration Manager).
Les points de vigilance critiques
Sur 30 projets tenant-to-tenant menés ces 4 dernières années, voici les pièges récurrents :
- DNS et coexistence email : un mauvais MX record pendant 4 heures, c'est plusieurs milliers de courriels perdus. Toujours prévoir un domaine de routage temporaire (ex: contoso-mig.onmicrosoft.com).
- Comptes de service et applications enregistrées (Azure AD App Registrations) : souvent oubliés. Toute intégration tierce (CRM, ERP, signature électronique) doit être ré-autorisée dans le tenant cible.
- Teams Phone (Direct Routing, Calling Plans) : exige une re-souscription complète, parfois une re-acquisition des numéros via l'opérateur. Délai 2 à 6 semaines selon le carrier.
- Sensitivity Labels Purview : ne migrent pas. Doivent être recréés dans le tenant cible avant le début de la migration documentaire, sinon les fichiers se retrouvent sans étiquette.
- Stream classique (deprecation 2024) et Yammer/Viva Engage : exercices spécifiques, planifier séparément.
- Licences : double-paiement inévitable pendant 4 à 12 semaines (les deux tenants actifs simultanément). Le budget doit l'anticiper.
Retour terrain : 4 000 utilisateurs en 12 semaines
Un mandat récent illustre bien la mécanique. Un groupe québécois qui consolidait trois entités (4 000 utilisateurs au total) vers un tenant unique. Trois sources, un cible. Volumétrie : 18 To de OneDrive, 240 sites SharePoint, 380 équipes Teams, 4 200 boîtes aux lettres.
Calendrier : 4 semaines de cadrage et architecture, 2 semaines de pilote sur 80 utilisateurs, 4 vagues de bascule de 1 000 utilisateurs réparties sur 4 fins de semaine consécutives, 2 semaines de cleanup et support renforcé. Total : 12 semaines.
Taux d'incident utilisateur post-migration : 2,8 % (résolus en moyenne sous 48 heures). Zéro perte de données documentaires. Trois boîtes aux lettres à re-migrer manuellement pour cause de corruption Exchange source.
Combien ça coûte vraiment
Pour une PME de 100 utilisateurs : entre 25 000 $ et 60 000 $ tout compris (licences outils, services-conseils, double-paiement temporaire).
Pour une grande entreprise de 1 000 utilisateurs : entre 180 000 $ et 350 000 $.
Pour 4 000+ utilisateurs avec scénarios complexes (Teams Phone, Power Platform, intégrations Dynamics) : 500 000 $ à 1,2 M$.
Les facteurs qui font exploser la facture : nombre d'applications tierces intégrées, volume Teams Phone, complexité des permissions SharePoint legacy, et qualité de l'inventaire initial. Un cadrage sous-dimensionné de 5 jours peut coûter 80 000 $ en dépassement plus tard.
Vous voulez en parler ?
Échangeons 30 minutes sur votre situation.
Diagnostic gratuit avec un architecte io4. Sans engagement, sans script commercial.
Réserver mon diagnostic
