Réussir une migration vers Microsoft 365
Les étapes d'une migration Microsoft 365 maîtrisée, du recensement des données au sevrage de l'ancien environnement, et les pièges qui coûtent le plus cher.
Ce qui rate rarement, et ce qui rate souvent
La migration technique des boîtes aux lettres est aujourd'hui un problème résolu : les outils fonctionnent, les procédures sont documentées. Ce qui déraille est ailleurs — dans les fichiers partagés, les habitudes de travail et les applications qui envoient des courriers sans que personne ne s'en souvienne.
Une migration réussie consacre plus de temps au recensement qu'au transfert.
Étape 1 : recenser au-delà des boîtes aux lettres
Listez tout ce qui touche à la messagerie et aux fichiers :
- Boîtes aux lettres individuelles, partagées, ressources et listes de diffusion
- Règles de transfert existantes, y compris vers l'extérieur
- Applications et copieurs qui envoient des courriers automatiques
- Partages de fichiers, avec leur volume et leur profondeur d'arborescence
- Fichiers de messagerie archivés en local sur les postes
Les deux dernières lignes sont celles qui font exploser les délais. Une arborescence de fichiers trop profonde ou des noms trop longs provoquent des échecs en série au moment du transfert.
Étape 2 : nettoyer avant de transférer
Migrer des données mortes coûte du temps de transfert, de la licence et de la confusion. Avant de démarrer :
- Identifiez les comptes inactifs et tranchez leur sort
- Repérez les partages sans accès depuis plus de deux ans
- Corrigez les chemins trop longs et les caractères problématiques
- Décidez ce qui devient une archive consultable plutôt qu'un contenu migré
C'est la seule occasion réaliste de faire ce ménage. Après la migration, plus personne n'y reviendra.
Étape 3 : préparer les identités
L'identité conditionne tout le reste. Décidez tôt :
- Synchronisation depuis Active Directory, ou identités gérées uniquement dans le cloud
- Méthode d'authentification et déploiement du multifacteur
- Convention de nommage, et traitement des homonymes
- Attribution des licences par groupe plutôt qu'individuellement
Activez le multifacteur avant la migration, pas après. Le faire ensuite oblige les utilisateurs à subir deux changements successifs, et double la charge sur le support.
Étape 4 : migrer par vagues cohérentes
Constituez les vagues par équipe entière, jamais par ordre alphabétique. Les collègues qui travaillent ensemble partagent des agendas et des fichiers : les séparer entre deux vagues crée des incohérences pendant toute la période de transition.
Commencez par une vague pilote incluant l'équipe IT elle-même. Vous découvrirez les problèmes sur des utilisateurs capables de les décrire précisément.
Étape 5 : accompagner, pas seulement informer
La différence entre une migration vécue comme une réussite et la même migration vécue comme une catastrophe tient souvent à trois choses :
- Une communication annoncée à l'avance, avec des dates fermes
- Une aide-mémoire d'une page : où sont mes fichiers, comment je me connecte, qui j'appelle
- Une présence renforcée du support les deux jours suivant chaque vague
Étape 6 : ne pas éteindre trop vite
Conservez l'ancien environnement en lecture seule pendant au moins un mois après la dernière vague. C'est la période où remontent les demandes de fichiers oubliés et les règles de transfert qu'on avait manquées.
Prévoyez formellement une date de sevrage, sinon l'ancien système survivra des années et vous paierez deux infrastructures.
Le piège qui coûte le plus cher
Les applications métier qui envoient des courriers automatiques. Elles sont configurées une fois, il y a des années, et personne ne sait plus lesquelles existent. Le jour du basculement, les notifications, factures et alertes cessent silencieusement.
Recensez-les au début du projet, en interrogeant les responsables métier plutôt que la documentation technique. Ils savent quels courriers ils reçoivent tous les matins.