Migration Microsoft 365 tenant-to-tenant

Les déclencheurs typiques

Une 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. Comprendre le déclencheur est important car il détermine les contraintes (calendrier, budget, image, gestion du changement).

• Fusion-acquisition : consolidation de deux ou plusieurs tenants vers un tenant cible, souvent dans les 12 mois post-acquisition.
• Scission ou cession d'activité : extraire une partie d'un tenant existant vers un nouveau tenant indépendant.
• Sortie d'un groupe : filiale rachetée par un actionnaire externe, doit quitter le tenant du groupe.
• Restructuration interne : consolidation de plusieurs entités historiques sous une nouvelle structure.
• Rebranding majeur : passage à un nouveau nom de domaine principal, opportunité de remettre à plat.
• Pression Microsoft 365 SKUs ou coûts : consolidation pour optimiser les licences.

Pourquoi c'est plus complexe qu'une migration on-premise

Contrairement à une migration Exchange on-premise → Microsoft 365 (où l'outillage Microsoft est mature et documenté), Microsoft ne fournit pas d'outil natif complet pour la migration entre deux tenants Microsoft 365. Il faut combiner plusieurs solutions tierces, accepter des compromis (Teams chat history limité, certaines métadonnées SharePoint perdues), et orchestrer manuellement la coexistence.

L'autre complexité : la migration tenant-to-tenant ne touche pas que les boîtes aux lettres. Elle touche tout l'écosystème Microsoft Graph : SharePoint, OneDrive, Teams, Planner, Stream, Yammer, Power Platform, Dynamics, applications enregistrées, comptes de service. Chaque service a ses propres mécaniques de migration et ses propres limites.

Phase 1 - Cadrage et inventaire (2 à 4 semaines)

Le cadrage est la phase la plus critique et la plus souvent sous-dimensionnée. C'est là qu'on documente précisément ce qui va bouger.

• Audit des deux tenants : licences, configurations, politiques Conditional Access, MFA, Defender, Purview.
• Inventaire exhaustif des objets : boîtes aux lettres (taille, type, archive activée), sites SharePoint, équipes Teams (avec onglets, canaux, applications), OneDrives, groupes de sécurité, groupes Microsoft 365, comptes de service, applications enregistrées Azure AD.
• Cartographie des intégrations tierces : CRM (HubSpot, Dynamics, Zoho), ERP, signature électronique (DocuSign), outils de paie, applications métier.
• Décision identité : cohabitation, fusion AD, AD Connect cible.
• Décision domaines : nouveau domaine principal, redirections email, certificats SSL.

Phase 2 - Architecture cible et choix d'outils (1 à 2 semaines)

Sur la base de l'inventaire, l'architecte définit la cible et choisit les outils. Décisions principales :

• Domaine principal cible : conservation, fusion, ou nouveau ?
• Stratégie d'identité : tenant cible Microsoft Entra ID greenfield, ou fusion AD on-premise via ADMT/Quest ?
• Outils de migration : BitTitan MigrationWiz (boîtes + OneDrive), Quest ou ShareGate (SharePoint), AvePoint Fly (Teams).
• Calendrier de bascule DNS et stratégie de coexistence (free/busy cross-tenant, routage SMTP partagé).
• Gouvernance pendant la transition : qui crée des objets dans quel tenant ? gel des changements ?

Phase 3 - Coexistence et pilote (2 à 4 semaines)

Avant toute migration de masse, mettre en place la coexistence pour que les utilisateurs des deux tenants puissent collaborer pendant la transition :

• Free/Busy cross-tenant (cross-tenant calendar sharing) : un utilisateur du tenant A peut voir les dispos d'un utilisateur du tenant B.
• Domaine de routage intermédiaire (ex: contoso-mig.onmicrosoft.com) pour éviter les boucles email pendant la transition.
• Configuration des MX, autodiscover, SPF, DKIM, DMARC pour la coexistence.
• Migration pilote sur 20 à 50 utilisateurs représentatifs : 1 commercial, 1 RH, 1 finance, 1 direction, 1 manager, 1 stagiaire, etc.
• Mesure des temps de migration unitaires, identification des cas edge.

Phase 4 - Vague principale (2 à 8 semaines)

La migration de masse se fait par vagues de 100 à 500 utilisateurs, généralement pendant les fins de semaine. Chaque vague suit le même runbook :

1. 1Vendredi 18h - Communication finale, gel des modifications côté tenant source.
2. 2Vendredi 22h - Démarrage de la migration des boîtes aux lettres (delta migration finale, les pre-migrations ayant été faites les semaines précédentes).
3. 3Samedi 8h - Vérification des migrations, escalade si erreur.
4. 4Samedi 14h - Migration OneDrive delta, SharePoint delta.
5. 5Dimanche 10h - Bascule DNS pour les utilisateurs migrés, test envoi/réception.
6. 6Dimanche 18h - Validation end-to-end, communication go/no-go pour lundi matin.
7. 7Lundi 7h - Helpdesk renforcé, traitement des incidents.

Phase 5 - Cleanup et hand-over (2 à 3 semaines)

Une fois la dernière vague terminée, on nettoie :

• Suppression progressive des objets dans le tenant source.
• Suppression des partages cross-tenant qui n'ont plus de raison d'être.
• Hardening final du tenant cible : Conditional Access cible, Defender, Purview, sensitivity labels.
• Transfert documentaire : runbooks, architecture, décisions, dépendances connues.
• Décommissionnement du tenant source (parfois conservé en lecture seule pendant 6 à 12 mois pour archive légale).

Phase 6 - Support post-migration (4 à 6 semaines)

Le projet ne s'arrête pas à la dernière bascule. Les 4 à 6 semaines suivantes sont consacrées au support renforcé :

Helpdesk dédié avec SLA renforcé sur les sujets migration. Résolution des cas edge : items non migrés (généralement 1-3 % du volume), boîtes corrompues à re-migrer manuellement, Teams chats à reconstruire partiellement. Suivi de la stabilisation des intégrations tierces (CRM, signature, paie).