Ce guide pas à pas explique comment transférer toutes les données d’un utilisateur Microsoft 365 d’un tenant A vers un tenant B sans coupure : boîtes aux lettres, OneDrive/SharePoint, Teams, règles/paramètres et autorisations, ainsi que les bonnes pratiques licences, sécurité et DNS.
Vue d’ensemble de la question
Vous devez déplacer un utilisateur (ou un petit groupe) d’un tenant Microsoft 365 A vers un tenant B, en maintenant la continuité de service et l’intégrité des données. Le périmètre couvre la messagerie (mails, calendrier, contacts), les fichiers OneDrive/SharePoint, les artefacts Teams, les paramètres Outlook (règles, signatures), ainsi que la gestion des licences, des autorisations et des enregistrements DNS. Ci‑dessous, vous trouverez le parcours recommandé, les options outillées par Microsoft et les précautions concrètes pour réussir ce transfert « tenant‑to‑tenant » avec un minimum d’interruption.
Réponse & solutions
Objectif | Solution(s) recommandée(s) | Points clés / précautions |
---|---|---|
Migrer la boîte aux lettres (mails + contacts + calendrier) | Assistant de migration (Centre d’administration Microsoft 365 → Configuration › Migration des données) : • Sélectionner Exchange comme source. • Suivre l’assistant (« Migration IMAP » ou « Cross‑tenant mailbox migration »). | • Vous devez être administrateur global ou Exchange Admin sur les deux tenants. • Assurez‑vous qu’une licence Exchange Online est attribuée dans le tenant B avant la migration. • Le cross‑tenant natif gère les attributs de boîte, les règles, l’Archivage Online et les Alias. |
Paramètres Outlook, règles, signatures | La migration cross‑tenant conserve la plupart des règles. Pour les signatures et paramètres locaux, prévoir : • Exportation via Outlook (Options › Courrier › Signatures…). • Outils tiers (ex. CodeTwo, BitTitan) si besoin d’automatisation. | Tester sur un compte pilote pour vérifier que les règles se réappliquent correctement. |
OneDrive, SharePoint, Teams | • Utiliser SharePoint Migration Tool ou Migration Manager pour OneDrive/SharePoint. • Pour Teams : script PowerShell Move‑CsUser (selon disponibilité) ou solutions tierces. | Planifier les migrations hors des heures de pointe ; vérifier la rétention et la conformité (eDiscovery, Legal Hold) avant déplacement. |
Permissions et délégations | Recréer manuellement ou via scripts PowerShell (Add‑MailboxPermission ) dans le tenant B. | Documenter les accès actuels ; prévoir une période de coexistence ou redirection. |
Licences | • Retirer la licence du tenant A une fois les données validées. • Attribuer les licences nécessaires (Exchange, OneDrive, Teams…) dans le tenant B. | Vérifier les quotas (archivage illimité, stockage OneDrive). |
Support Microsoft | • Pour < 500 licences, support standard + communauté FastTrack. • ≥ 500 licences : programme FastTrack accompagne gratuitement la migration. | Contacter FastTrack en amont pour le planning et la validation du plan de migration. |
Architecture de bout en bout
Le succès du transfert repose sur une succession maîtrisée d’étapes :
- Préparer le tenant B : créer l’utilisateur cible, attribuer les licences, définir les stratégies (sécurité, rétention, DLP), préparer OneDrive et l’espace Teams.
- Configurer la coexistence : activer les relais/redirects temporaires, préparer la migration Exchange (assistant ou batch cross‑tenant), réduire la TTL DNS.
- Exécuter la migration initiale : lancer les jobs (mailbox, OneDrive/SharePoint), valider les deltas, contrôler les permissions.
- Basculer : gel des modifications, synchronisation finale, bascule MX/Autodiscover si le domaine suit, bascule des appareils mobiles.
- Stabiliser & valider : tests fonctionnels, réapplication des délégations, mise à jour des signatures/outils locaux, déprovisionnement dans A.
Pré‑requis & gouvernance
Thème | Décisions / actions | Conseils |
---|---|---|
Rôles & accès | Au minimum : Global Administrator ou Exchange Administrator dans les deux tenants. Accès SharePoint/Teams admin pour les fichiers. | Utiliser des comptes d’administration dédiés avec MFA. Journaliser toutes les actions. |
Licences | Attribuer Exchange Online + OneDrive/SharePoint + Teams sur le tenant B avant le move. | Vérifier l’archivage Online (In‑Place Archive) et les limites. |
Conformité | Cartographier les politiques de rétention, labels de confidentialité, eDiscovery/Legal Hold. | Lever les verrous ou planifier le transfert des politiques équivalentes côté B. |
Domaine & DNS | Décider si le domaine personnalisé (vanity) suit l’utilisateur. | Si le domaine bouge : baisser TTL (ex. 300 s) J‑2, prévoir une brève fenêtre d’indisponibilité au changement de propriétaire. |
Étapes détaillées
Préparer le tenant cible (B)
- Créer l’utilisateur avec l’UPN/alias souhaité (temporairement sur
tenantB.onmicrosoft.com
si le domaine doit être déplacé). - Attribuer les licences (Exchange Online Plan x, OneDrive/SharePoint, Teams, Archivage si requis).
- Initialiser la boîte aux lettres et OneDrive (connexion initiale via Outlook Web et OneDrive Web accélère l’initialisation).
- Définir les stratégies : rétention, DLP, MFA/Conditional Access, Safe Links/Safe Attachments.
- Si vous utilisez la migration cross‑tenant native, préparer l’identité liée (MEU ou compte cible) et les autorisations d’accès inter‑tenant nécessaires.
Préparer le tenant source (A)
- Inventorier la boîte aux lettres : taille, archive, compartiments, règles de boîte, délégations (SendAs, FullAccess, SendOnBehalf).
- Identifier les rétentions/Legal Hold : décider de lever temporairement ou de reproduire l’équivalent côté B.
- Relever les paramètres Outlook côté poste : signatures (
%APPDATA%\Microsoft\Signatures
), modèles (NormalEmail.dotm
), Quick Parts, Quick Steps, catégories, listes d’expéditeurs sûrs. - Planifier la coexistence du flux mail (transfert, transport rule ou redirection) pendant la période de bascule.
- Réduire la TTL des enregistrements DNS (MX, Autodiscover) 48 h avant si le domaine doit migrer.
Migrer la boîte aux lettres Exchange Online
Option A — Assistant de migration (simple, unitaire)
- Dans le centre d’administration Microsoft 365 : Configuration › Migration des données.
- Choisir Exchange comme source.
- Saisir les informations du tenant A (compte administratif, point de terminaison). L’assistant proposera l’IMAP ou, selon votre environnement, la migration cross‑tenant.
- Sélectionner l’utilisateur à migrer vers la boîte aux lettres cible du tenant B.
- Lancer la migration initiale ; attendre la synchro delta avant bascule.
Option B — Cross‑tenant Exchange mailbox migration (native, contrôlée)
Cette approche utilise le service de déplacement MRS entre tenants. À haut niveau :
- Trust entre tenants : configurer l’accès croisé requis pour permettre au service de migration du tenant B de lire les données du tenant A.
- Pré‑provisionnement : créer l’utilisateur cible (ou un mail‑enabled user) dans B et attribuer la licence Exchange.
- Point de terminaison : créer un Migration Endpoint dans B pointant vers
outlook.office365.com
. - Lot de migration : créer un Migration Batch avec la boîte aux lettres source et choisir StartAutomatically pour l’initialisation, CompleteManually pour maîtriser la bascule.
- Coexistence : garder un transfert/redirect côté A jusqu’à la finalisation.
- Bascule : Complete le lot à un créneau de faible activité puis vérifier l’accès dans B.
Bon à savoir : l’archive en ligne, les règles et la plupart des attributs sont pris en charge. Les éléments clients (signatures locales, modèles Word/Outlook) ne bougent pas d’eux‑mêmes, d’où la section suivante.
Paramètres Outlook, signatures et éléments côté poste
- Signatures : exporter depuis Outlook (Options › Courrier › Signatures) puis importer dans le profil du tenant B, ou automatiser via un outil tiers pour homogénéiser la charte.
- Règles Outlook : la migration native conserve généralement les règles côté serveur. Vérifier sur un pilote et corriger les dossiers cibles si les chemins changent.
- Cache de saisie semi‑automatique (AutoComplete) : il se reconstruit avec l’usage. Pour un transfert immédiat, exporter/importer les contacts récents.
- Modèles & Quick Parts : copier
NormalEmail.dotm
et les modèles personnels si besoin.
OneDrive et SharePoint
- Dans le centre d’administration SharePoint, utiliser Migration Manager ou SharePoint Migration Tool pour copier le contenu OneDrive de A vers B.
- Conserver la hiérarchie et les métadonnées si possible ; documenter les liens partagés et rétablir le partage côté B.
- Pour les sites d’équipe liés à Teams, traiter les bibliothèques SharePoint associées (et les onglets « Fichiers » dans Teams).
Astuce : prévenir les utilisateurs qu’un gel d’activité sur OneDrive (création/déplacement de fichiers) sera demandé juste avant la bascule.
Teams
Le déplacement de conversations, canaux et paramètres Teams entre tenants est limité côté natif. Deux approches :
- Re‑création ciblée : reconstruire équipes, canaux et appartenances dans B (scripts Graph/PowerShell), puis basculer l’utilisateur. Les messages historiques ne sont pas déplacés, mais les fichiers le sont via SharePoint.
- Outils SaaS : solutions tierces (BitTitan, Quest, etc.) pour transférer messages, canaux privés et wikis selon leurs capacités.
Pour la téléphonie Teams (Phone System), l’applet Move‑CsUser
est parfois disponible selon scénario ; valider sa faisabilité et l’impact sur numérotation/plan d’appel avant d’envisager un mouvement cross‑tenant.
Permissions et délégations
Exporter les délégations dans A, puis les rejouer dans B. Exemple Exchange :
# Connexion EXO
Connect-ExchangeOnline
# Exporter permissions de la boîte
Get-MailboxPermission [userA@tenantA.com](mailto:userA@tenantA.com) |
Where-Object { $*.AccessRights -match 'FullAccess' -and -not $*.IsInherited } |
Select-Object Identity, User, AccessRights > .\mbx_perms.csv
Get-RecipientPermission [userA@tenantA.com](mailto:userA@tenantA.com) |
Select-Object Identity, Trustee, AccessRights >> .\mbx_sendas.csv
# Dans B, rejouer selon la nouvelle identité :
Add-MailboxPermission [userB@tenantB.com](mailto:userB@tenantB.com) -User collè[gue@tenantB.com](mailto:gue@tenantB.com) -AccessRights FullAccess -AutoMapping $true
Add-RecipientPermission [userB@tenantB.com](mailto:userB@tenantB.com) -Trustee collè[gue@tenantB.com](mailto:gue@tenantB.com) -AccessRights SendAs
Pour les autorisations de dossiers (calendar editor, etc.), utilisez Get/Add‑MailboxFolderPermission
de la même manière.
DNS, MX et Autodiscover
Si le domaine suit l’utilisateur :
- J‑2 : abaisser TTL (ex. 300 s) sur MX et Autodiscover.
- J‑1 : s’assurer que tous les objets du tenant A ont été détachés du domaine (UPN, alias, groupes, applications). Prévoir une fenêtre pour remove domain côté A et add/verify domain côté B.
- Jour J : déplacer les enregistrements MX/Autodiscover du DNS public vers B. Lancer la synchro finale de la boîte et compléter la migration.
- J+1 : surveiller les NDR, ajuster les connecteurs, vérifier l’autodiscover et les profils Outlook.
Si le domaine ne suit pas : conserver le domaine source côté A, créer un alias dans B et activer un transfert pour éviter la perte de messages pendant la coexistence.
Continuité de service
- Configurer un transfert de courrier ou une règle de transport dans A vers l’adresse B durant la fenêtre.
- Communiquer un gel des changements (règles, dossiers, signatures) juste avant la bascule.
- Sur les mobiles, prévoir la suppression/recréation du compte (Authenticator/Outlook) pour limiter les prompts MFA post‑bascule.
Intune (si applicable)
- Si les appareils sont gérés par Intune du tenant A, définir la stratégie de réinscription côté B (autopilote, profils de configuration).
- Documenter les apps, profils et certificats à reproduire.
Validation et déprovisionnement
- Tests de réception/envoi, calendriers partagés, accès OneDrive/SharePoint, accès Teams, délégations.
- Une fois validé, supprimer les transferts temporaires, retirer la licence Exchange du tenant A, puis désactiver/désallouer le compte source selon politique.
Informations complémentaires utiles
Plan de bascule (cut‑over)
- Créez le compte cible, attribuez‑lui la licence, puis démarrez la réplication.
- Lorsque la synchronisation initiale est terminée, planifiez la bascule finale : arrêter l’envoi sur l’ancien compte, exécuter une dernière synchronisation delta, puis modifier les enregistrements MX et Autodiscover.
Continuité de service
- Activez un transfert de courrier ou un partage d’alias entre tenants pendant la phase de coexistence pour éviter la perte de messages.
- Communiquez aux utilisateurs une période de gel des changements (règles, dossiers) juste avant la bascule.
Sécurité & conformité
- Vérifiez que les stratégies de rétention, les labels de confidentialité et les éventuelles affaires d’eDiscovery sont réappliqués ou clôturés avant la migration.
- Documentez toute clé de chiffrement (Customer Key, BYOK) si utilisée.
Outils alternatifs
- PST export/import via Outlook pour un seul utilisateur ; simple mais manuel et non automatisé.
- Solutions SaaS tierces (CodeTwo, BitTitan, Quest) : utiles pour projets multi‑utilisateurs ou scénarios hybrides complexes.
Checklists prêtes à l’emploi
Avant migration
- Rôles admin validés sur A et B, MFA activé.
- Licence Exchange/OneDrive/Teams attribuée à l’utilisateur dans B.
- Inventaire : taille boîte et archive, délégations, règles, ressources partagées.
- OneDrive analysé : volumes, liens partagés critiques, fichiers verrouillés.
- Teams : équipes essentielles à recréer ou à migrer via outil tiers.
- Conformité : rétention/hold cartographiés, plan de re‑création dans B.
- DNS : stratégie domaine décidée, TTL abaissé si transfert.
- Communication planifiée (email J‑5, rappel J‑1, pas‑à‑pas utilisateur).
Pendant migration
- Lancer la migration Exchange (assistant ou batch cross‑tenant) en mode « CompleteManually ».
- Démarrer la copie OneDrive/SharePoint (Migration Manager/SPMT), suivre l’avancement et corriger les erreurs.
- Recréer/attribuer les délégations nécessaires dans B.
- Configurer transfert/redirect côté A pour la coexistence.
Basculer
- Arrêt des changements côté utilisateur (règles, réorganisation dossiers).
- Synchro delta finale Exchange, complétion du lot.
- Si applicable, changement DNS (MX/Autodiscover) vers B.
- Reconnexion Outlook/Teams, re‑inscription mobiles si besoin.
Après migration
- Tests bout‑en‑bout : envoi/réception, calendriers partagés, accès OneDrive/SharePoint, Teams, délégations.
- Restauration des signatures, modèles, Quick Steps.
- Retrait des redirections temporaires, nettoyage des objets dans A.
- Archivage des rapports de migration et clôture de projet.
Modèles de communication
Annonce J‑5 : « Votre compte Microsoft 365 sera transféré vers un nouveau tenant le <date> entre <heure> et <heure>. Vos mails, contacts, calendrier et fichiers seront déplacés. Pendant la bascule, merci de ne pas modifier vos règles ou déplacer de gros volumes de mails/fichiers. »
Rappel J‑1 : « Demain, nous effectuons la bascule. Pensez à fermer Outlook/Teams au début de la fenêtre. Un guide de reconnexion vous sera envoyé dès la fin. »
Message de fin : « La migration est terminée. Ouvrez Outlook / Teams, reconnectez‑vous si demandé. Si une signature est manquante, importez le fichier transmis. En cas d’anomalie, contactez le support avec l’objet <Migration Tenant>. »
Dépannage ciblé
Symptôme | Cause probable | Remède |
---|---|---|
Erreur à la complétion du lot | Rétention/Legal Hold bloquant, élément corrompu, boîte non provisionnée | Lever/adapter la politique, relancer un delta, vérifier la licence B et le statut de la boîte |
NDR après bascule | MX/Autodiscover incohérents, TTL non expiré | Vérifier la zone DNS publique, patienter la propagation, réessayer |
Règles Outlook manquantes | Règles côté client non migrées | Recréer les règles locales, privilégier les règles côté serveur |
Permissions perdues | Délégations non rejouées dans B | Rejouer les CSV d’export via PowerShell (Add‑MailboxPermission , Add‑MailboxFolderPermission ) |
Synchronisation mobile échouée | Profil Exchange de l’ancien tenant en cache | Supprimer et recréer le compte dans Outlook mobile / Intune Company Portal |
Quand choisir chaque approche
Approche | Avantages | Limites | Idéale pour |
---|---|---|---|
Assistant de migration (admin center) | Simple, guidée, peu de scripts | Moins de contrôle fin, rapports basiques | Un à quelques utilisateurs |
Cross‑tenant mailbox migration (native) | Contrôle du timing, préservation étendue | Préparation plus technique | Environnements réglementés, exigences de traçabilité |
PST export/import | Sans dépendance admin, offline | Manuel, perte de métadonnées possibles | Cas isolé, urgence |
Outils SaaS tiers | Transfert Teams, tableaux de bord, automation | Coût, gouvernance des accès | Projets multi‑utilisateurs, scénarios complexes |
Bonnes pratiques pour éviter l’interruption
- Planifier la bascule en heures creuses et limiter la fenêtre (60–120 min typiquement pour un utilisateur).
- Pré‑provisionner la boîte B et effectuer une migration initiale + plusieurs deltas avant le cut‑over.
- Mettre en place un catch‑all temporaire ou un redirect dans A pour capter les messages résiduels.
- Informer précisément l’utilisateur et les éventuels délégués (assistants, boîtes partagées liées).
- Conserver un plan de retour arrière : si la complétion échoue, garder le compte A opérationnel et le redirect actif.
Exemples de scripts utiles
Export des permissions de dossier Calendrier
# Exporter permissions du calendrier
$calendar = "userA@tenantA.com:\Calendar"
Get-MailboxFolderPermission $calendar |
Where-Object { $_.User -notmatch "Default|Anonymous" } |
Select-Object Identity, User, AccessRights |
Export-Csv .\calendar_perms.csv -NoTypeInformation
# Dans B, rejouer (adapter l'UPN)
Import-Csv .\calendar_perms.csv | %{
Add-MailboxFolderPermission "[userB@tenantB.com](mailto:userB@tenantB.com):\Calendar" -User $*.User -AccessRights $*.AccessRights
}
Liste des boîtes partagées où l’utilisateur a des droits
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
ForEach-Object {
$mbx = $_.PrimarySmtpAddress
$perms = Get-MailboxPermission $_.Identity | Where-Object { $_.User -like "userA@tenantA.com" -and -not $_.IsInherited }
if ($perms) { [PSCustomObject]@{ SharedMailbox = $mbx; Rights = ($perms.AccessRights -join ",") } }
} | Export-Csv .\sharedmbx_rights.csv -NoTypeInformation
FAQ
Combien de temps dure la bascule ?
La phase visible pour l’utilisateur se limite à la complétion du lot et à la reconnexion des applications. La majorité des données est copiée en amont grâce aux synchronisations delta, ce qui réduit l’interruption à la fenêtre planifiée.
Les archives en ligne et les catégories de couleurs sont‑elles conservées ?
Les archives en ligne Exchange sont prises en charge côté natif. Les catégories Outlook et signatures locales pouvant être propres au poste, prévoyez une réimportation.
Quid des boîtes partagées et des ressources ?
Si elles restent dans le tenant A, recréez les délégations sur l’utilisateur B. Si elles suivent dans B, planifiez leur migration en cohérence, idéalement avant le cut‑over de l’utilisateur.
Peut‑on faire coexister les deux comptes pendant une période ?
Oui, via un redirect/transfert de mails et la duplication des accès. Limitez cette période pour éviter les divergences de données.
Résumé exécutable
- Préparer B : compte+licences, politiques sécurité/conformité, OneDrive initialisé.
- Coexister : redirect A→B, TTL abaissé si transfert domaine.
- Migrer Exchange (assistant ou cross‑tenant), copier OneDrive/SharePoint, préparer Teams.
- Basculer : delta final, Complete batch, MX/Autodiscover si applicable.
- Finaliser : rejouer délégations, importer signatures, déprovisionner A.
En suivant ce parcours — préparation des comptes, attribution des licences, utilisation de l’assistant de migration (ou d’un outil tiers) et reconfiguration des permissions — vous pouvez transférer l’intégralité des données d’un utilisateur vers un nouveau tenant sans interruption notable et en conservant l’intégrité des informations.