Les 7 modes de migration M365 expliques : lequel choisir ?

Quand on planifie une migration Microsoft 365 tenant-to-tenant, on decouvre vite que tous les utilisateurs ne peuvent pas être migrés de la même manière. Certains changent simplement de domaine, d'autres doivent cohabiter entre deux tenants pendant des semaines, d'autres encore fusionnent dans un compte existant. C'est pour ca que les consultants experimentnes definissent un "mode de migration" par utilisateur. Voici les 7 modes et quand les utiliser.

1. Full (Migration complete)

C'est le mode le plus courant et le plus simple. L'utilisateur "jean.dupont@contoso.com" devient "jean.dupont@fabrikam.com", avec un alias sur contoso.com pour ne pas perdre d'emails.

Quand l'utiliser : pour la majorite des utilisateurs dans une migration standard. Tous les services sont migrés, l'utilisateur bascule complètement vers le nouveau tenant.

Scénario typique : fusion-acquisition ou l'entreprise acquise adopte le domaine de l'acquereur. 80% des utilisateurs sont en mode "Full".

2. Cohabitation Alias

Ce mode est essentiel quand la migration se fait par vagues et que les utilisateurs déjà migrés doivent pouvoir communiquer avec ceux qui ne le sont pas encore. L'alias sur le tenant oppose assure que les emails arrivent toujours au bon endroit.

Quand l'utiliser : migration par vagues avec des equipes reparties entre les deux tenants pendant plusieurs semaines. Besoin d'un routage mail transparent.

Scénario typique : ETI de 500 utilisateurs avec 4 vagues de migration sur un mois. Pendant la periode de cohabitation, chaque utilisateur a un alias sur l'autre tenant pour garantir la continuite des echanges.

3. Cohabitation Shared (Boite partagee)

La difference avec le mode Alias est que les emails ne sont pas simplement rediriges : ils sont réellement stockés dans une boîte partagée accessible par l'utilisateur. Cela permet de consulter l'historique des emails recus pendant la cohabitation.

Quand l'utiliser : quand il est important de conserver un historique des emails recus sur chaque tenant pendant la cohabitation. Utile pour les fonctions juridiques ou les postes avec des obligations de retention.

Scénario typique : migration d'un cabinet d'avocats ou les obligations legales exigent que chaque email soit stocké et accessible, même pendant la phase transitoire.

4. Merge (Fusion)

Ce mode s'applique quand l'utilisateur a déjà un compte sur le tenant destination (par exemple, un compte créé manuellement ou via un précédent projet). Au lieu de créer un nouveau compte, on fusionne les données dans le compte existant.

Quand l'utiliser : acquisitions ou certains employés ont déjà été integres partiellement au tenant destination, ou quand un utilisateur a des comptes sur les deux tenants et qu'il faut les consolider.

Scénario typique : un collaborateur detache chez l'acquereur depuis 6 mois a déjà un compte @fabrikam.com. Il faut migrer ses données @contoso.com vers ce compte existant sans perdre ce qui est déjà sur @fabrikam.com.

5. Guest (Invite)

Certains utilisateurs n'ont pas besoin d'une migration complete. Un acces guest leur suffit pour collaborer sur les sites SharePoint et les canaux Teams du tenant destination.

Quand l'utiliser : prestataires externes, collaborateurs temporaires, ou equipes qui ne necessitent qu'un acces de collaboration sans migration de messagerie.

Scénario typique : lors d'une cession, l'équipe IT partagée continue a collaborer sur des projets communs pendant 6 mois. Ils ont un acces guest plutot qu'une migration complete.

6. Leaving (Depart)

Ce mode concerne les utilisateurs qui quittent l'entreprise avant, pendant ou juste apres la migration. Il n'est pas pertinent de les migrer, mais il faut s'assurer que les emails qui continuent d'arriver a leur ancienne adresse sont captures.

Quand l'utiliser : collaborateurs en fin de contrat, departs planifies, ou utilisateurs qui ne rejoindront pas le nouveau tenant.

Scénario typique : lors d'une restructuration, 15% des effectifs sont licencies dans le cadre du plan social. Ils sont marques en mode "Leaving" avec une boîte partagée pour capturer leurs emails pendant 3 mois.

7. Alias (Nouvel alias)

Ce mode est utilise quand la convention de nommage change entre les deux tenants. Au lieu de simplement changer le domaine, on restructure aussi la partie locale de l'adresse.

Quand l'utiliser : rebranding complet avec changement de convention de nommage, ou harmonisation des formats d'email entre deux entités fusionnées.

Scénario typique : l'entreprise source utilise "prenom.nom@source.com" et l'entreprise destination utilise "p.nom@destination.com". Il faut adapter chaque adresse a la nouvelle convention.

Comment choisir le bon mode ?

Le choix du mode depend de plusieurs facteurs :

• L'utilisateur a-t-il déjà un compte sur le tenant destination ? Si oui, mode Merge.
• La migration est-elle immediate ou progressive ? Progressive = Cohabitation (Alias ou Shared).
• L'utilisateur a-t-il besoin d'Exchange ? Si non, mode Guest.
• L'utilisateur quitte l'entreprise ? Mode Leaving.
• La convention de nommage change ? Mode Alias.
• Cas standard, migration complete ? Mode Full.

Dans la pratique, la plupart des projets utilisent 2 a 4 modes differents. Par exemple : 80% des utilisateurs en Full, 10% en Cohabitation Alias, 5% en Merge, et 5% en Leaving.

La complexité vient du fait que chaque mode a des implications différentes sur les UPN, les alias, les licences, le routage mail et les applications. Gerer tout cela dans un tableur Excel est vite ingérable au-delà de 50 utilisateurs. C'est exactement le problème que resout MigrateKit : une interface unique pour attribuer le mode, la direction mail et les emails personnalises par utilisateur, avec une génération automatique de tous les livrables adaptes au mix de modes du projet.

Tableau recapitulatif