Bonnes pratiques pour planifier votre migration Microsoft 365

Le secret d'une migration qui ne vire pas au gouffre de temps ? Vous l'avez deviné : une bonne planification avant migration. Voici les bonnes pratiques qui vous mettent sur la voie du succès.

Quelle est la différence entre une migration chaotique et une migration sans accroc ? Tout se joue souvent avant le moindre déplacement de données.  

La planification avant migration, c'est poser des bases solides. Comme dit le proverbe : « mesurez deux fois, coupez une fois ». Plus votre préparation est rigoureuse, moins vous rencontrerez de surprises et de contretemps pendant la migration.  

La dernière fois, j'ai abordé les défis d'une migration M365 et comment les régler. Dans cet article, on voit comment bien préparer votre migration : les étapes de planification qui vous font gagner du temps, réduisent les risques et préparent votre organisation à une transition réussie. Aligner les parties prenantes sur une vision claire, préparer votre environnement cible : une planification soignée vous rend opérationnel dès le jour J.

Regardez la session complète sur demande : venez à bout des plus grands défis de migration Microsoft 365.

‍Définissez votre vision et votre portée

Commencez par définir clairement pourquoi vous migrez vers Microsoft 365 et ce que vous voulez en tirer.  

Vous voulez peut-être améliorer la collaboration à distance, retirer des serveurs sur site vieillissants, renforcer la sécurité ou regrouper des outils disparates sur une seule plateforme. Poser cette vision vous aide à expliquer l'importance du projet aux parties prenantes et aux utilisateurs finaux.  

En parallèle de la vision, déterminez la portée de la migration. Migrez-vous seulement des fichiers et des sites SharePoint ? Les e-mails et les calendriers ?  Et les applications de département ou les flux de travail liés à SharePoint ou Teams, essentiels aux opérations quotidiennes ? Documentez les systèmes, les charges de travail et les unités métier inclus dans la portée, et ceux qui en sont exclus (pour l'instant). Vous éviterez ainsi les dérives de portée plus tard. Fixez aussi vos critères de succès dès le départ. Par exemple : « Tous les employés ont accès au nouvel environnement et au contenu essentiel dès le premier jour, et les systèmes hérités sont mis hors service d'ici la date X. » Ce genre de critère vous donne des objectifs concrets à viser.

Dans la foulée, montez une équipe de projet et une structure de gouvernance. Trouvez un commanditaire exécutif capable de porter le projet et d'aider à débloquer les enjeux de haut niveau ou les besoins en ressources. Nommez un gestionnaire de projet ou un responsable de migration qui coordonnera toutes les pièces mobiles. Vous voudrez aussi des représentants de plusieurs horizons : opérations IT (pour l'infrastructure et la planification des identités), sécurité et conformité (pour valider que les exigences sont respectées), et représentants des unités métier ou utilisateurs experts (pour porter la voix des utilisateurs et aider aux décisions de contenu). Définissez clairement les rôles et les responsabilités de l'équipe : qui gère la communication ? Qui pilote l'outil de migration ? Qui valide que le contenu a bien migré ? En établissant tôt cette gouvernance et cette structure d'équipe, chacun sait ce qu'il a à faire.

Évaluez votre environnement actuel

Une fois la portée définie, faites l'inventaire complet de votre environnement actuel. Autrement dit : auditez le contenu et les systèmes que vous avez, et la façon dont ils sont structurés.

Les questions à trancher à cette étape :

• Quel contenu avons-nous, et où se trouve-t-il ? Listez tous les dépôts : partages de fichiers, sites SharePoint, boîtes aux lettres Exchange, fichiers PST et autre contenu lié à SharePoint, peut-être du contenu dans Google Drive ou sur d'autres plateformes si vous consolidez. N'oubliez pas les sources moins évidentes, comme les dossiers publics Outlook ou les données stockées dans des outils de collaboration que Teams pourrait remplacer.
• Quel volume de données ? Estimez le volume (téraoctets de fichiers, nombre de sites, boîtes aux lettres et leur taille, etc.). Ça influence l'échéancier et le choix de la méthode de migration.
• Qui possède ou utilise ce contenu ? Repérez les départements ou les groupes qui « possèdent » les différents ensembles de contenu. Connaître le propriétaire aide plus tard, au moment de décider quoi migrer et d'obtenir les approbations pour supprimer ou archiver. Comptez aussi vos utilisateurs et repérez les données inactives (fichiers ou boîtes aux lettres d'anciens employés) qui n'ont peut-être pas besoin d'être migrées.
• Quelles sont les dépendances ? Documentez les dépendances et les intégrations. Par exemple : avez-vous un intranet SharePoint qui pointe vers des partages de fichiers précis, ou des flux de travail qui relient un système hérité à vos documents ? Comprendre ces dépendances vous aide à faire correspondre les fonctionnalités existantes à leurs équivalents Microsoft 365, sans casser la continuité ni frustrer les utilisateurs.
• Quelles sont les personnalisations et les cas particuliers ? Vous avez peut-être des composants WebPart SharePoint personnalisés, des formulaires InfoPath ou des feuilles Excel avec macros qui dépendent de chemins sur site. Listez-les. Certaines fonctionnalités sur site n'ont pas d'équivalent direct dans le nuage : il vous faudra un plan (repenser un processus, passer par un outil tiers, ou accepter des changements de fonctionnement).

Cette évaluation représente une bonne charge de travail, mais des outils de migration peuvent vous aider. Par exemple, les fonctions d'inventaire et d'analyse de ShareGate (incluses dans sa trousse de migration) analysent votre environnement et produisent des rapports sur les sites, la taille du contenu, les données inutilisées ou orphelines, et plus encore. (Si vous n'avez pas encore d'outil, même une feuille de calcul tenue à la main vaut mieux que rien !) Le résultat de cette évaluation, c'est votre « inventaire de migration » et une vision plus claire de l'ampleur du projet.

Planifiez votre architecture d'information dans Microsoft 365

Passons maintenant à la destination : Microsoft 365. Une étape essentielle consiste à concevoir l'architecture d'information cible et les paramètres Microsoft 365 avant de migrer quoi que ce soit. Autrement dit : décidez comment vous structurerez vos sites SharePoint, Microsoft Teams, OneDrive et tout autre composant pertinent pour votre organisation. Par exemple :

• Structure SharePoint : déterminez si vous optez pour un seul hub de type intranet avec plusieurs sites, ou pour un modèle plus décentralisé. Vous pourriez créer un site hub moderne par département. Planifiez les bibliothèques de documents et l'organisation du contenu (par projet, par fonction, etc.). Une architecture SharePoint bien pensée rend le contenu plus facile à trouver une fois vos utilisateurs dans le nouveau système.
• Microsoft Teams, SharePoint ou OneDrive : clarifiez quel contenu va où. Une approche courante : les documents de travail personnels vont dans OneDrive, pour un stockage et un accès efficaces ; les documents de collaboration d'équipe ou de projet vont dans Teams (qui s'appuie en coulisses sur des sites d'équipe SharePoint) ; et le contenu à l'échelle de l'organisation ou d'archive vit dans des sites de communication SharePoint dédiés. Décidez si vous créez des équipes Teams pour certains groupes dans le cadre de la migration (par exemple, pour remplacer d'anciennes listes de distribution ou des dossiers de lecteur réseau).
• Permissions et gouvernance dans le nouvel environnement : planifier votre architecture va de pair avec la planification de la gouvernance. Déterminez qui doit avoir accès à quoi dans la nouvelle configuration, en vous appuyant sur Azure Active Directory pour simplifier la gestion des identités. C'est l'occasion de repenser les permissions : par exemple, simplifier des schémas devenus trop complexes dans l'ancien système. Repérez les sites ou les données sensibles qui demandent un traitement particulier (données RH ou financières réservées à quelques personnes). Microsoft 365 offre une gestion des permissions fiable ; prévoyez d'utiliser les groupes Azure AD, les niveaux de permission SharePoint et les appartenances Teams pour reproduire (ou améliorer) les contrôles d'accès de votre système actuel.
• Configurez les paramètres du tenant à l'avance : le centre d'administration Microsoft 365 contient une foule de paramètres qui peuvent affecter votre migration ou l'expérience de vos utilisateurs dans le nouvel environnement. Assurez-vous par exemple que toutes les licences nécessaires sont attribuées aux utilisateurs qui vont migrer. Configurez les paramètres SharePoint Online comme les limites de stockage des sites, et vérifiez que les paramètres de partage respectent vos politiques de sécurité (allez-vous autoriser le partage externe par défaut ou le restreindre ?). Si vous migrez les e-mails, tranchez d'avance sur les paramètres Exchange Online (taille des boîtes aux lettres, filtrage du pourriel, etc.). Bref, vous voulez un tenant Microsoft 365 prêt à recevoir vos contenus et vos utilisateurs.

À ce stade, montez aussi un banc d'essai ou une preuve de concept. Si possible, créez un petit environnement Microsoft 365 de test (ou utilisez une portion de votre tenant si vous migrez vers un tenant en production) pour valider l'architecture prévue. Créez par exemple un site SharePoint de test et déplacez quelques documents, ou montez une équipe Teams d'essai pour voir comment se comportent les fichiers et les permissions. Vous validerez vos hypothèses et découvrirez les ajustements à apporter à votre plan.

Bâtissez un plan de migration détaillé et un échéancier

Inventaire en main et conception cible en place, il est temps de bâtir le plan de migration.  Ce plan décrit étape par étape comment et quand la migration se déroulera. Ses éléments clés :

• Approche de migration : choisissez l'approche qui colle à votre situation. Une migration big bang, où tout bascule d'un coup (un week-end, par exemple) ? Ou une migration par phases, par vagues (par département ou par type de contenu), étalée dans le temps ? Ou encore une approche hybride, si vous devez faire cohabiter le sur site et le nuage un moment. Certaines organisations migrent d'abord les e-mails, puis les fichiers, puis les autres services. Il n'y a pas de recette unique : prenez celle qui réduit le plus vos risques. (En cas de doute, une approche par phases avec un pilote au départ est souvent plus sûre.)
• Échéancier et calendrier : construisez un échéancier qui couvre toutes les activités majeures : nettoyage du contenu (j'y reviens dans la 3e partie de cette série), jalons de communication aux utilisateurs, tests pilotes, les migrations elles-mêmes et le suivi post-migration. Soyez réaliste : les transferts de données prennent du temps. Mieux vaut prévoir du jeu pour les imprévus que d'annoncer une date de bascule et la manquer. Si vous avez des dates butoirs fermes (fin de contrat d'un système hérité, événement d'entreprise qui dicte le calendrier), mettez-les en évidence et planifiez à rebours pour être prêt. Pour chaque phase, fixez les fenêtres précises de copie des données et le moment de la bascule (quand les utilisateurs passent à Microsoft 365).
• Plan de communication : intégrez les communications aux utilisateurs dans votre échéancier. Vous pourriez annoncer le projet à toute l'organisation 60 jours d'avance, puis envoyer des rappels ou des conseils au fil des semaines. Prévoyez les avis d'interruption (« Le système sera en lecture seule le X, de Y à Z »), les instructions pour se connecter à Microsoft 365 la première fois, et à qui s'adresser en cas de pépin. La communication compte tellement qu'elle mérite son propre chantier dans le plan, avec son calendrier et son responsable.
• Plan de formation : planifiez de la même façon la formation et la préparation des utilisateurs. Sessions de formation une semaine avant la bascule, guides pratiques publiés sur l'intranet, à vous de voir. Repérez vos utilisateurs experts et donnez-leur un accès anticipé pour qu'ils deviennent les référents de leur équipe. Inscrivez ces activités au plan, pour ne pas les traiter après coup.
• Gestion des risques : passez en revue les risques possibles et prévoyez des mesures d'atténuation. Et si la bande passante pendant la migration était plus faible que prévu ? Si un membre clé de l'équipe quittait en cours de route ? Si certains fichiers échouaient à migrer ? Pour chaque risque majeur, ayez au moins un plan de rechange de base. Si la migration s'étire, pouvez-vous la prolonger sur un deuxième week-end ? Si des fichiers échouent à cause de noms trop longs, gardez un script ou un outil prêt à les repérer et à les corriger. Prévoyez aussi un plan de retour arrière (même si vous espérez ne jamais vous en servir) : si la migration doit être interrompue, comment vos utilisateurs continueront-ils à travailler sur l'ancien système en attendant ?

Consignez tous ces détails dans un cahier de migration (runbook). C'est le document que n'importe qui dans l'équipe peut consulter. Il liste chaque étape, le responsable et le moment exact. Par exemple : « Vendredi 17 h – Désactiver l'édition sur SharePoint sur site (Jean) et lancer l'outil de migration pour les collections de sites SharePoint (Alice). Surveiller la progression... Samedi 8 h – Valider un échantillon de contenu dans SharePoint Online (membres de l'équipe X et Y). »  Ce niveau de détail, combiné à l'automatisation, évite la confusion quand la pression monte, le week-end ou pendant les phases de migration.

Alignez les parties prenantes et finalisez le plan

Avant de passer à l'exécution, passez le plan de migration en revue avec toutes les parties prenantes clés (IT et affaires). Un feu vert des chefs de département ou de la direction sur l'échéancier et l'approche garantit que tout le monde est sur la même longueur d'onde.

C'est aussi le bon moment pour cadrer les attentes. Précisez par exemple que certains services peu utilisés ne seront pas migrés, ou rappelez que certaines fonctionnalités plus anciennes se comporteront différemment dans Microsoft 365. Assurez-vous que le personnel de soutien ou le centre d'assistance IT connaît le plan et se prépare à la hausse des demandes. Bref, personne ne doit être pris au dépourvu au moment de l'exécution. Un exercice de simulation avec l'équipe de projet aide beaucoup : rejouez les étapes du jour J et vérifiez que chacun connaît son rôle et que tous les prérequis sont en place.

Un dernier point essentiel : validez les prérequis techniques. À la fin de votre planification, vous devriez pouvoir répondre à ces questions :

• Tous les comptes utilisateurs sont-ils créés dans Microsoft 365 et licenciés comme il faut ?
• Avons-nous le matériel ou la machine virtuelle nécessaire pour faire tourner l'outil de migration ? Le chemin réseau est-il dégagé (pare-feu et compagnie autorisent-ils le transfert de données vers Microsoft 365) ?
• Si vous comptez utiliser un outil de migration tiers, est-il installé, à jour, et avez-vous fait un essai avec ?

Régler tout ça avant le jour J vous évitera les courses de dernière minute.

‍

Résumons. La planification avant migration peut sembler beaucoup de travail au départ, mais elle pose vraiment les bases de tout ce qui suit. Un plan détaillé donne à votre équipe de la confiance et de la clarté, réduit les risques d'erreur et augmente vos chances de livrer la migration à temps et sous le budget prévu. Comme le veut le vieil adage de la gestion de projet : « ne pas planifier, c'est planifier son échec ». En investissant dans un plan solide, vous planifiez activement votre succès.

Les autres articles de la série d'Andy sur la migration :

• Les défis d'une migration Microsoft 365 et comment les régler‍
• Nettoyage avant migration Microsoft 365 : quoi migrer, et quoi laisser derrière‍
• Comment mener un pilote et migrer vers Microsoft 365 sans interruption
• Comment soutenir vos utilisateurs après la migration‍
• Comment réussir l'adoption et la gouvernance de Microsoft 365