Pourquoi une migration tenant to tenant demande une méthode à part
Fusions, build-up, cessions : un calendrier fixé par le deal
Chaque build-up rapproche deux entreprises, et souvent deux tenants Microsoft 365. Dès le closing, vos équipes veulent échanger, partager des fichiers et se retrouver dans le même annuaire.
La migration tenant to tenant démarre donc avec une date imposée. Le calendrier juridique du deal la fixe, et la DSI construit son planning à partir de cette échéance. Pendant tout le projet, les deux tenants restent en production : les commerciaux vendent, la comptabilité clôture, le support répond.
Vous devez aussi rapprocher deux cultures IT. Chaque entité arrive avec ses politiques de sécurité, ses conventions de nommage et ses habitudes dans Teams ou SharePoint. Une cession pose la même question dans l’autre sens. Il faut alors extraire une partie des utilisateurs et de leurs données vers un tenant indépendant, tout en préservant l’activité de ceux qui restent.
Ce que les outils natifs Microsoft laissent de côté
Lundi matin, première vague migrée. Une commerciale ouvre Outlook : impossible de se connecter. Son collègue cherche sa signature. Le lien de la réunion d’équipe renvoie une erreur.
Ces situations ont une cause commune. La migration native de Microsoft transfère le contenu des boîtes aux lettres et de OneDrive. Une partie de l’environnement de travail reste à reconstruire.
Trier les données avant de les déplacer
Le tri commence par un inventaire des deux tenants : sites, bibliothèques, équipes Teams, boîtes partagées, volumes OneDrive. Pour ce travail, ShareGate propose une analyse avant migration, et l’éditeur met en avant le nettoyage du contenu redondant parmi ses fonctions tenant to tenant.
Vient ensuite la décision, élément par élément :
- vous migrez ce qui sert au quotidien ;
- vous archivez ce que vous devez conserver pour des raisons légales ;
- vous supprimez le reste, avec l’accord des propriétaires.
Moins de volume, ce sont des vagues plus courtes et une migration tenant to tenant plus lisible pour vos équipes. Ce tri prolonge une démarche de nettoyage des données. Il prépare aussi une gouvernance des données durable dans le nouveau tenant.
Structurer la GED et les espaces collaboratifs dans la cible
Après un rachat, deux arborescences cohabitent. L’une classe les contrats par client, l’autre par année. Les uns créent une équipe Teams par projet, les autres une par service. La migration offre le bon moment pour trancher.
Dans SharePoint, la GED repose sur quelques choix structurants :
- des bibliothèques organisées par usage métier ;
- des métadonnées communes pour retrouver un document en quelques secondes ;
- une gestion des versions activée sur les contenus sensibles ;
- des droits attribués par groupe plutôt que par personne.
Ajoutez des conventions de nommage partagées et des règles claires : qui crée une équipe, qui en est propriétaire, quand on l’archive. Vous évitez ainsi de reproduire dans la cible le désordre des deux sources.
Bertrand Franchise a relevé un défi proche. L’entité réunit les fonctions support du Groupe Bertrand au service de plusieurs enseignes de restauration, dont Burger King. Avec BSD, elle a fiabilisé ses référentiels et déployé des intranets d’enseigne sur Microsoft 365, devenus des outils du quotidien au siège comme en restaurant. Voir le témoignage Bertrand Franchise
Une migration tenant to tenant pose la même question : comment offrir un espace commun à plusieurs entités, sans effacer leurs spécificités ?
Vous voulez structurer vos espaces collaboratifs avant la bascule ?
Identités, domaines et licences
Tout part du mappage des identités. Chaque compte source correspond à un compte cible unique. Dans la cible, l’identifiant de connexion (UPN) et l’adresse principale reprennent le domaine de la nouvelle entreprise. Microsoft prépare un mappage d’identité inter-locataires pour automatiser une partie de ce travail, encore en préversion.
Le domaine impose son propre calendrier. Un nom de domaine appartient à un seul tenant à la fois. Vous travaillez donc avec un domaine temporaire dans la cible, puis vous transférez le domaine d’origine au moment de la bascule finale.
Les licences du tenant source restent attachées à ce tenant. Votre migration tenant to tenant devient l’occasion de revoir vos contrats et d’harmoniser les offres entre entités. Notre analyse de Microsoft 365 E7 peut vous aider à arbitrer. Pour la gestion des comptes et des droits, retrouvez nos articles sur Microsoft Entra ID et la gestion des accès en entreprise.
Ce que ShareGate migre d’un tenant à l’autre
Reprenez le tableau des outils natifs. Groupes Microsoft 365, conversations Teams, plans Planner : ces éléments demandaient un outil tiers. ShareGate les prend en charge dans une même interface.
| Workload | Contenus pris en charge par ShareGate | |
| Exchange Online | Boîtes principales, boîtes de groupes Microsoft 365, archives en ligne<br>Boîtes partagées, salles et équipements | |
| Microsoft Teams | Historique des conversations, membres, fichiers, onglets, plans Planner<br>Déplacement de canaux entre équipes, ou d’équipes entières depuis un autre tenant | |
| SharePoint | Documents, collections de sites, étiquettes de confidentialité Purview | |
| OneDrive | Fichiers, avec un outil dédié à la migration entre tenants | |
Deux fonctions changent le quotidien de vos équipes projet :
- ShareGate associe automatiquement les boîtes source et cible, et produit un rapport pour chaque boîte migrée.
- Les migrations incrémentales ne recopient que ce qui a changé depuis le premier passage. Vous lancez la copie principale plusieurs jours avant la bascule, puis vous rattrapez les écarts la veille.
Pour une migration tenant to tenant, la couverture de l’outil compte autant que sa vitesse. Moins vous jonglez entre plusieurs outils, plus votre planning reste lisible.
ShareGate ou outils natifs : le comparatif
Votre DSI compte deux administrateurs Microsoft 365, déjà mobilisés sur le quotidien. Faut-il leur confier des scripts PowerShell ou un outil graphique ? La réponse dépend de votre périmètre.
Les deux approches se combinent. Certaines équipes migrent les boîtes aux lettres avec l’outil natif, puis confient SharePoint, OneDrive et Teams à ShareGate. D’autres centralisent toute la migration tenant to tenant dans ShareGate pour garder un seul tableau de bord.
Trois questions vous aident à trancher :
- Quels workloads devez-vous migrer ?
- Quelles compétences PowerShell avez-vous en interne ?
- Quel niveau de reporting attendent votre direction et le juridique ?
Comment BSD pilote une migration avec ShareGate
Un outil ne fait pas un projet. Chez BSD, ShareGate s’insère dans une méthode en cinq étapes, la même que pour toute migration Microsoft 365.
1. Conception. Nous étudions la faisabilité technique et organisationnelle, puis nous définissons l’architecture du tenant cible. Les règles de mappage des utilisateurs, des groupes et des boîtes partagées se fixent à ce stade dans ShareGate.
2. Pilote. Nous migrons un premier lot représentatif : quelques utilisateurs par métier, une équipe Teams active, un site SharePoint volumineux. Les temps mesurés servent à dimensionner les vagues suivantes.
3. Mise en œuvre. Nous paramétrons le tenant cible et les dispositifs de coexistence entre les deux environnements.
4. Migration. La copie principale démarre plusieurs jours avant chaque bascule. Les passes incrémentales de ShareGate rattrapent ensuite les modifications jusqu’à la veille. Après chaque vague, les rapports de l’outil servent de preuve de complétude, boîte par boîte et site par site.
5. Adoption. Nous accompagnons vos équipes dans le nouvel environnement, avec un support et une formation ciblée.
Cette méthode donne un cadre lisible à votre migration tenant to tenant. Votre direction sait à chaque étape ce qui est migré, ce qui reste à faire et quand intervient la prochaine vague.
Vous préparez une consolidation de tenants ?
Recenser ce qui tourne réellement sur le tenant source
Les applications métier se cachent souvent dans les sites et les équipes. Votre inventaire doit couvrir :
- les applications et listes SharePoint personnalisées ;
- les Power Apps et leurs sources de données ;
- les flux Power Automate, avec les connexions rattachées au compte de leur créateur ;
- les connecteurs vers vos logiciels métier (ERP, CRM, paie) ;
- les applications tierces inscrites dans Microsoft Entra ID ;
- les développements spécifiques et les portails.
Pour chaque élément, notez son propriétaire, ses utilisateurs et sa criticité.
Ensuite, classez-le dans l’une des trois catégories suivantes :
| Décision | Quand la retenir | Exemple | |
| Migrer | L’application reste utile et fonctionne une fois ses connexions mises à jour | Une liste de suivi des congés | |
| Reconstruire | Elle repose sur des comptes ou des services propres au tenant source | Un flux qui interroge l’ERP de l’entité rachetée | |
| Abandonner | Un outil équivalent existe déjà dans le tenant cible | Deux intranets RH qui font doublon | |
Faites valider ce classement par les utilisateurs métier. Eux seuls savent quelle application fait tourner la clôture mensuelle. Dans une migration tenant to tenant, cet inventaire sécurise le lendemain de la bascule.
Migrer ou reconstruire une application métier
Une application métier a souvent une histoire plus longue que le tenant qui l’héberge. Elle a survécu à des changements d’outils, de prestataires et d’équipes. La migration doit lui assurer la même continuité.
BSD a accompagné un grand groupe de l’énergie dans ce type de transition. Ce client utilisait Lotus Notes/Domino comme système de messagerie et de collaboration. Dans le cadre de sa migration vers Microsoft 365, il souhaitait transférer une application métier existante vers SharePoint Online.
Voir le cas client
La source change d’un projet à l’autre, mais la démarche reste la même :
- vous analysez les fonctions réellement utilisées ;
- vous choisissez entre transfert et reconstruction ;
- vous reconfigurez les flux Power Platform pour qu’ils pointent vers les comptes et les sources du tenant cible ;
- vous testez chaque scénario avec les utilisateurs métier avant la mise en production.
Après la bascule, l’application continue d’évoluer. La TMA applicative de BSD prend le relais sur SharePoint Online, la Power Platform et vos développements spécifiques, avec une maintenance corrective et évolutive et un pilotage par comités réguliers.
Besoin d’assurer la continuité de vos applications après la migration ?
Le jour J côté utilisateurs
Lundi, 8 h 30 : Outlook affiche une erreur. Anticipez quatre actions :
- reconstruire le profil Outlook ;
- replanifier les réunions Teams ;
- recréer les signatures ;
- réattribuer le droit « Envoyer de la part de ».
Envoyez un mode opératoire court à chaque vague. Votre migration tenant to tenant se juge ce matin-là, au poste de chaque collaborateur. Côté données personnelles, consultez nos repères sur les obligations RGPD.
Adoption et exploitation du nouveau tenant
Accompagner les utilisateurs
Trois semaines après la bascule, le directeur commercial cherche encore ses fichiers dans l’ancien dossier partagé. La migration technique a réussi, et l’adoption commence tout juste.
Quatre leviers accélèrent la prise en main :
– des ambassadeurs par service, qui relaient les consignes ;
– la formation Microsoft 365 de BSD, sur Teams, SharePoint et OneDrive ;
– un support renforcé les premières semaines ;
– des indicateurs d’usage suivis chaque semaine.
Exploiter le tenant dans la durée
La dernière vague a basculé. Gardez le tenant source quelques semaines, copiez les boîtes utiles au juridique, puis supprimez les accès de migration et résiliez les anciennes licences.
Les services managés de BSD prennent ensuite le relais : maintien en conditions opérationnelles, support de niveau 1 à 3, administration des identités et des accès. Les équipes BSD réalisent toutes les prestations, sans offshore ni nearshore. Une collectivité de 4 250 agents bénéficie de ce dispositif depuis 2020.
Confiez l’exploitation de votre nouveau tenant à une équipe dédiée
À retenir sur la migration tenant to tenant Microsoft 365
aucun
Qu’est-ce qu’une migration tenant to tenant Microsoft 365 ?
Une migration tenant to tenant consiste à déplacer des utilisateurs, des données et des applications d’un tenant Microsoft 365 vers un autre, dans le cadre d’une fusion, d’un build-up ou d’une cession. Elle se distingue d’une migration classique par sa complexité : les deux tenants restent en production pendant tout le projet, le calendrier est imposé par le deal juridique, et deux cultures IT doivent être rapprochées.
Comment gérer les applications métier lors d’une migration tenant to tenant ?
Commencez par un inventaire exhaustif : Power Apps, flux Power Automate, connecteurs vers l’ERP ou le CRM, applications SharePoint personnalisées et portails. Classez chaque élément en trois catégories — migrer, reconstruire ou abandonner et faites valider ce classement par les utilisateurs métier, qui seuls savent quelle application pilote la clôture mensuelle. Les flux Power Platform doivent être reconfigurés pour pointer vers les comptes et les sources du tenant cible.
Quelles sont les étapes clés d’une migration tenant to tenant réussie ?
Cinq étapes structurent le projet : conception de l’architecture cible et définition des règles de mappage des identités, pilote sur un lot représentatif pour calibrer les vagues, paramétrage du tenant cible et de la coexistence entre les deux environnements, migration avec passes incrémentales jusqu’à la veille de chaque bascule, et accompagnement à l’adoption avec support renforcé les premières semaines. L’adoption commence là où la migration technique s’arrête.
Qu’est-ce que la disponibilité opérationnelle d’un système d’information ?
La disponibilité opérationnelle mesure la part du temps où un service fonctionne normalement, sans interruption perceptible par les utilisateurs. Elle se pilote avec trois indicateurs complémentaires : le taux de disponibilité cible fixé dans le contrat, le MTBF (temps moyen entre deux pannes) et le MTTR (temps moyen de rétablissement après incident). Ces engagements sont formalisés dans un SLA et suivis en comité de pilotage.
