Ce type de projet, aussi appelé migration cross-tenant Microsoft 365, combine des enjeux business — maintien de la productivité des équipes, respect des délais contractuels — et des défis techniques liés à la configuration d’Azure AD, du Centre d’administration Exchange et des règles de routage. Une migration Microsoft 365 tenant-to-tenant sans interruption de service repose sur une séquence précise de tâches, depuis l’audit de l’environnement source jusqu’à la bascule finale des enregistrements DNS. Le rôle d’un intégrateur expert comme Eliadis, partenaire Microsoft spécialisé dans les environnements collaboratifs depuis 2001, est déterminant pour sécuriser chaque étape du transfert de messagerie Microsoft 365 et assurer une reprise de messagerie cloud à cloud sans friction.
À retenir :
- La migration des boîtes aux lettres Exchange Online entre tenants Microsoft 365 nécessite une préparation méticuleuse pour éviter interruptions et pertes de données
- Un plan structuré inclut l’inventaire des boîtes, la configuration des licences et la gestion des identités Azure AD dans le tenant cible
- La réussite repose sur l’utilisation de PowerShell et du service MRS pour orchestrer les migrations sans interrompre les services.
- La coexistence des deux environnements doit être rigoureusement planifiée pour maintenir la visibilité des disponibilités (free/busy) des utilisateurs.
- Des tests post-migration stricts garantissent le bon fonctionnement des boîtes aux lettres et la conformité avec les réglementations telles que le RGPD.
- Une approche coordonnée, soutenue par des partenaires spécialisés comme Eliadis, est essentielle pour assurer une migration en douceur et sans friction.
Préparer le plan de migration des boîtes aux lettres Exchange Online entre tenants
Un plan de migration Exchange Online structuré conditionne directement le succès d’un projet tenant-to-tenant. Avant d’exécuter la moindre commande, l’inventaire technique et la configuration initiale tenant-to-tenant doivent être finalisés.
Identifier les types de boîtes aux lettres et estimer les volumes
La première étape consiste à cartographier l’ensemble des boîtes aux lettres présentes dans le tenant source. Il ne s’agit pas uniquement des boîtes utilisateur : la migration des boîtes partagées et des ressources (salles de réunion, équipements) représente souvent une complexité sous-estimée. Chaque catégorie obéit à des règles spécifiques en termes de licence, de conversion et de traitement post-migration. Un inventaire précis, réalisable via Exchange Online PowerShell avec la commande Get-Mailbox -ResultSize Unlimited, permet d’estimer les volumes réels, d’anticiper les durées de synchronisation et de dimensionner les ressources humaines et techniques nécessaires.
| Type de boîte | Licence requise côté cible | Point d’attention |
|---|---|---|
| Boîte utilisateur | Microsoft 365 E3/E5 ou Exchange Online Plan 2 | Profil complet à recréer dans Azure AD |
| Boîte partagée | Aucune (jusqu’à 50 Go) ou Exchange Online Plan 1 | Conversion possible depuis boîte utilisateur |
| Boîte ressource (salle) | Licence ressource ou Exchange Online Plan 1 | Paramètres de réservation à reconfigurer |
| Boîte ressource (équipement) | Licence ressource ou Exchange Online Plan 1 | Attributs spécifiques à exporter manuellement |
Lister les licences nécessaires et les prérequis Azure AD
La synchronisation des identités Azure AD pour la messagerie constitue un prérequis incontournable. Dans le tenant cible, chaque objet destinataire doit exister en tant qu’utilisateur à extension messagerie (mail-enabled user) avant le démarrage effectif de la migration. Cela suppose une synchronisation préalable ou une création manuelle des comptes dans Azure AD, assortie de l’attribution des Microsoft 365 Licences adéquates. Sans licence Exchange Online active dans le tenant cible, la migration échoue systématiquement au moment de la création de la boîte de destination. Il est donc conseillé d’allouer les licences en amont et de vérifier leur disponibilité via le Centre d’administration Microsoft 365, ou de s’appuyer sur un partenaire spécialisé comme Eliadis pour sécuriser également la migration SharePoint Online et OneDrive dans une approche globale Digital Workplace.
Créer les comptes administrateurs et établir les relations organisationnelles
La configuration des droits d’administration est une condition bloquante documentée par Microsoft. Selon Microsoft Learn, il est impératif de créer des comptes Administrateur dans les tenants source et cible afin d’autoriser les opérations de migration (Source : Microsoft Learn — 2024-05-20). Ces comptes doivent disposer du rôle Organization Management dans Exchange Online et d’autorisations Global Admin ou Exchange Admin dans Azure AD. L’étape suivante consiste à établir la relation organisationnelle entre les deux tenants, en configurant les points de terminaison de migration via Exchange Online PowerShell. Pour les projets de grande envergure, des outils tiers comme ceux présentés sur Petri permettent d’automatiser et d’orchestrer ces étapes. Une fois ces fondations posées, il devient possible d’aborder la phase d’exécution de la migration à proprement parler.
Exécuter la migration des boîtes aux lettres Exchange Online
La migration des boîtes aux lettres Exchange Online entre tenants repose sur une séquence d’opérations précises : préparer les objets cibles, lancer les lots de migration via PowerShell, puis orchestrer la bascule finale. Chaque étape conditionne la réussite du déplacement de boîtes aux lettres Microsoft 365 sans interruption de service.
Orchestrer la migration avec PowerShell et MRS
Le Mailbox Replication Service (MRS) est le moteur sous-jacent qui prend en charge chaque déplacement inter-tenants. C’est lui qui synchronise les données de messagerie entre les deux environnements, en arrière-plan, sans perturber l’activité des utilisateurs. Pour piloter ce service, les équipes techniques s’appuient sur PowerShell Exchange Online et, plus précisément, sur la commande New-MigrationBatch. Selon Microsoft Learn, les administrateurs peuvent utiliser l’applet de commande New-MigrationBatch pour effectuer des déplacements entre locataires Exchange Online (Source : Microsoft Learn — 2025-02-28). Cette commande permet de regrouper plusieurs boîtes aux lettres dans un lot unique, de définir un point de notification et de paramétrer le seuil d’erreurs acceptable avant l’arrêt automatique du processus. La stratégie de migration par lots Exchange est particulièrement adaptée aux projets de grande envergure : elle limite les pics de charge réseau et facilite le suivi opérationnel depuis le Centre d’administration Exchange.
Vérifier les attributs MailUser dans l’organisation cible
Avant le lancement de tout lot, l’objet MailUser correspondant à chaque boîte aux lettres migrée doit exister dans le tenant cible avec les attributs requis. Les propriétés critiques incluent l’ExternalEmailAddress, le LegacyExchangeDN et les alias SMTP. Une absence ou une erreur sur ces valeurs entraîne un échec de la migration, souvent difficile à diagnostiquer. Il convient donc de systématiquement valider ces attributs via PowerShell avant de soumettre le fichier CSV au batch. Le Migration Orchestrator Microsoft 365 peut automatiser une partie de ces vérifications et réduire le risque d’erreur humaine sur les projets comportant des centaines de boîtes aux lettres.
Définir la fenêtre de bascule et synchroniser les GALs
La bascule des comptes de messagerie entre tenants constitue la phase la plus sensible. Elle doit être planifiée pendant une plage horaire à faible activité et précédée d’une dernière synchronisation des listes d’adresses globales (GAL). Sans cette synchronisation, les utilisateurs migrés peuvent apparaître en doublon ou être introuvables dans l’annuaire du tenant cible.
| Étape | Outil recommandé | Risque si ignorée |
|---|---|---|
| Création du lot de migration | PowerShell — New-MigrationBatch |
Migration non initialisée |
| Vérification des attributs MailUser | PowerShell Exchange Online | Échec de synchronisation MRS |
| Synchronisation des GALs | Centre d’administration Exchange | Doublons dans l’annuaire cible |
| Bascule finale (cutover) | Migration Orchestrator / PowerShell | Interruption des flux de messagerie |
Une fois la bascule validée, il reste à sécuriser la gouvernance du nouvel environnement et à accompagner les utilisateurs dans la prise en main de leurs nouvelles boîtes aux lettres Exchange Online — ce que nous aborderons dans le chapitre suivant.
Gérer la coexistence et la bascule pendant la migration tenant-to-tenant
Pour assurer la continuité du service email lors d’une migration Exchange Online entre tenants, la coexistence des deux environnements doit être rigoureusement orchestrée dès les premières étapes. Chaque flux de messagerie, chaque délégation et chaque enregistrement DNS doit être planifié avant toute bascule.
Mettre en place une stratégie de coexistence pour la disponibilité free/busy
La coexistence entre deux tenants Microsoft 365 implique de maintenir la visibilité des disponibilités des utilisateurs (free/busy) pendant toute la durée de la migration. Sans cette visibilité croisée, la planification des réunions entre collaborateurs des deux organisations devient impossible, générant des blocages opérationnels majeurs. Pour y remédier, il est nécessaire de configurer une relation d’organisation (Organization Relationship) dans Exchange Online, permettant le partage des informations de calendrier entre les deux tenants. Les Groupes Microsoft 365 doivent également être pris en compte, car leurs calendriers partagés nécessitent une attention particulière lors de la synchronisation. Dans le cadre d’une coexistence messagerie cloud, l’utilisation d’un outil comme le Microsoft 365 Tenant-to-Tenant Migration Orchestrator peut faciliter la coordination des phases de transition et réduire les risques d’interruption.
Adapter le routage des messages (MX, SPF, Autodiscover)
La gestion du routage mail tenant-to-tenant repose sur une mise à jour progressive et coordonnée des enregistrements DNS. Les enregistrements MX, SPF, DKIM et Autodiscover doivent être modifiés dans un ordre précis pour éviter les rejets de messages ou les boucles de routage. Pendant la coexistence Exchange entre deux tenants, il est conseillé de maintenir les enregistrements MX pointant vers le tenant source jusqu’à ce que la totalité des boîtes aux lettres concernées ait migré. La redirection du flux SMTP via des connecteurs (connectors) Exchange Online permet alors d’acheminer les messages entrants vers le tenant cible pour les utilisateurs déjà migrés. L’enregistrement Autodiscover doit quant à lui être basculé au moment précis où les clients Outlook se reconnectent, afin d’éviter des profils mal configurés.
| Enregistrement DNS | Rôle | Moment de bascule recommandé |
|---|---|---|
| MX | Routage des messages entrants | Après migration complète des boîtes aux lettres |
| SPF | Authentification des expéditeurs | Simultané à la bascule MX |
| DKIM | Signature cryptographique des messages | Avant la bascule MX |
| Autodiscover | Configuration automatique des clients | Au moment de la reconnexion Outlook |
Gérer les délégations et droits d’accès (Full Access, Send As)
Les délégations de boîtes aux lettres constituent l’un des aspects les plus complexes de la coexistence Exchange entre deux tenants. Les permissions Full Access et Send As ne se migrent pas automatiquement : elles doivent être recréées manuellement dans le tenant cible après chaque déplacement de boîte aux lettres. Selon Microsoft Learn, les utilisateurs doivent être présents dans le système Exchange Online cible en tant que MailUser pour autoriser les déplacements inter-locataires (Source : Microsoft Learn — 2025-02-28). Cette condition préalable s’applique également aux objets bénéficiant de délégations : si la boîte déléguée n’existe pas encore comme MailUser dans le tenant cible, les permissions ne pourront pas être restaurées. Azure AD Connect joue ici un rôle central pour synchroniser les objets contacts et MailUser entre les deux annuaires, garantissant ainsi la cohérence des droits d’accès tout au long de la migration.
La maîtrise de ces trois leviers — coexistence calendrier, routage DNS et gestion des délégations — conditionne directement la qualité de l’expérience utilisateur pendant la migration. La section suivante détaille les étapes post-migration nécessaires pour valider la bonne finalisation de chaque boîte aux lettres déplacée.
Tests, validation et nettoyage post-migration
Un contrôle post-migration Exchange Online rigoureux permet de confirmer que chaque boîte aux lettres est opérationnelle et conforme avant de clôturer le projet. Ce plan de tests et validation post-migration doit couvrir aussi bien les flux fonctionnels que les exigences réglementaires.
Tests d’envoi, de réception et d’accès mobile
Dès la fin de la migration, chaque utilisateur doit effectuer un test d’envoi et de réception depuis Outlook, en vérifiant que les messages internes et externes transitent correctement. Les équipes IT doivent parallèlement contrôler l’accès mobile via Outlook pour iOS et Android, ainsi que la synchronisation du calendrier et des contacts. La validation des règles de transport et boîtes aux lettres constitue une étape critique : chaque règle personnalisée (redirections, disclaimers, restrictions d’expéditeur) doit être recréée dans le tenant cible et testée individuellement. Un tableau de suivi permet de centraliser ces vérifications :
| Élément testé | Client testé | Statut | Responsable |
|---|---|---|---|
| Envoi/réception interne | Outlook Desktop | À valider | IT Ops |
| Envoi/réception externe | Outlook Web App | À valider | IT Ops |
| Accès mobile | Outlook iOS / Android | À valider | Support |
| Règles de transport | Exchange Admin Center | À valider | Messagerie |
| Synchronisation calendrier | Outlook Desktop | À valider | Support |
Suppression des boîtes sources obsolètes
Une fois les tests concluants, la question du nettoyage des boîtes sources doit être traitée avec méthode. Selon Microsoft Learn, après une migration réussie, la boîte aux lettres source est supprimée et n’est plus accessible dans le locataire d’origine (Source : Microsoft Learn — 2025-02-28). Cette suppression automatique doit être documentée dans le dossier de migration afin de garantir la traçabilité des opérations et d’éviter toute confusion sur la disponibilité des données. Les licences associées aux comptes sources peuvent alors être libérées, réduisant ainsi les coûts de l’abonnement Microsoft 365.
Audit de conformité : DLP, RGPD et Microsoft Purview
La phase de sécurisation des données de messagerie pendant la migration ne s’achève pas avec le transfert des boîtes : un audit complet dans le Compliance Center s’impose. Microsoft Purview permet de vérifier que les politiques de prévention des pertes de données (DLP) sont bien actives dans le nouveau tenant et que les étiquettes de sensibilité restent appliquées aux messages migrés. Au regard du RGPD, il convient de confirmer que les journaux d’audit ont enregistré l’ensemble des opérations de transfert et que les données personnelles n’ont pas transité par des espaces non conformes. Pour des retours d’expérience complémentaires sur les outils d’orchestration inter-tenants, la ressource publiée par Petri sur le Microsoft 365 Tenant-to-Tenant Migration Orchestrator offre un éclairage pratique utile. Ces contrôles réglementaires constituent le socle du reporting final, que la prochaine étape, dédiée à la communication et à la conduite du changement, s’appuiera pour accompagner les utilisateurs dans leur nouvel environnement.
Conclusion
Réussir la migration tenant-to-tenant des boîtes aux lettres Exchange Online repose sur une planification rigoureuse et l’application de meilleures pratiques migration Exchange Online à chaque étape du projet. Une approche orchestrée permet de maîtriser simultanément la continuité de service, la conformité et les risques liés au transfert sécurisé de boîtes aux lettres Exchange Online.
Les points clés retenus tout au long de cet article confirment que la convergence de tenants Microsoft 365 pour la messagerie ne s’improvise pas : audit préalable, gestion des identités, synchronisation des attributs et validation post-migration constituent le socle d’un plan de reprise en cas d’échec de migration. Selon Microsoft Learn, la migration inter-clients permet aux administrateurs d’utiliser des interfaces familières telles qu’Exchange Online PowerShell et MRS, ce qui réduit la courbe d’apprentissage et sécurise le processus. (Source : Microsoft Learn — 2025-02-28)
Pour les décideurs et architectes IT, la prochaine étape consiste à évaluer précisément la maturité de leur environnement Microsoft 365 et à s’appuyer sur l’expertise d’Eliadis pour structurer chaque phase du projet. Anticiper, documenter et tester restent les meilleurs atouts pour transformer une migration complexe en succès durable.
