5 points de vigilance pour planifier la migration vers Exchange Online

Les responsables de projet partent du principe que les utilisateurs ont besoin de l’ensemble de leurs données pour travailler efficacement et qu’il serait impensable de ne pas migrer la totalité du contenu des boites aux lettres. Néanmoins, migrer l’ensemble des données immédiatement n'est pas facilement réalisable ni même nécessaire.

Évidemment, il n’est pas possible de filtrer le contenu des boîtes aux lettres, en cours de migration, avec Mailbox Replication Service (MRS) fourni par Microsoft. Doit-on se plier aux possibilités techniques de l’outil proposé nativement quitte à ralentir le projet ou chercher une solution plus souple et adaptable permettant d’accélérer la migration ? Un projet ne doit jamais être défini en fonction des capacités d’un outil mais sur la base des besoins métiers auxquels un outil devra répondre.

Élargissons le champ d’analyse aux autres charges de traitement nécessaires pour une migration vers le Cloud et notamment Office 365. Il faut prendre en compte les boîtes mail, les archives, les fichiers et les dossiers publics. Ce à quoi s’ajoutent les discussions Teams ainsi que les documents partagés via Teams, SharePoint et OneDrive, si une migration inter-tenants est nécessaire. Cela peut représenter des téraoctets de données. Une grande partie de ces données est ancienne et peu souvent accédée. Il est peu probable qu’elle soit nécessaire aux utilisateurs dans les 90 jours. En tenir compte permet d’accélérer la migration en segmentant les données à migrer pour respecter des délais souvent très serrés.

Les données accédées dans les 90 derniers jours seront migrées en priorité. Une fois les utilisateurs basculés dans le nouvel environnement, il sera temps de migrer (ou d’archiver) les données plus anciennes. La migration sera plus rapide, perçue comme plus efficace sans pour autant impacter la productivité des utilisateurs.

Pourquoi les dossiers publics (Public Folder) sont-ils si effrayants? Les dossiers publics sont une technologie dépassée associée à Exchange depuis ses débuts. Ils sont difficiles à gérer, volumineux, et incitent les utilisateurs finaux à contourner les stratégies de rétention et les limites de taille des boîtes mail en les utilisant comme solution d'archivage. Ces défauts sont aussi ceux des fichiers PST.

L'avantage de migrer vers le cloud est qu'il devient possible de déplacer des données de dossiers publics vers des outils de collaboration plus modernes tels que SharePoint Online ou les espaces partagés des groupes Microsoft 365.

Même si, depuis Exchange 2013, il est possible de migrer directement vers les dossiers publics d’Exchange Online en conservant la hiérarchie et les permissions, il y a des restrictions. Par exemple, si un dossier public dépasse 25 Go, Microsoft recommande de le nettoyer pour en réduire la taille. De plus, Exchange Online limite le nombre de dossiers dans un arbre de dossiers publics à 500 000.

Il y a donc deux choix de migration possibles: soit conserver les dossiers publics on-premise (en mode hybride) parce qu'ils dépassent les limites d'Exchange Online, soit migrer toutes les données des dossiers publics qui le nécessiteraient vers des espaces de groupe Microsoft 365 (limitées à 50 Giga-octets).

L'utilisation du processus de migration par lots géré par PowerShell ou par un produit tiers fournira une méthode pour copier les données de courrier et de calendrier des dossiers publics directement vers les groupes Office 365 sans aucune étape intermédiaire. En outre, une fois les dossiers publics migrés vers des groupes Office 365, vous pourrez convertir ces groupes en Microsoft Teams si vous le souhaitez, offrant ainsi encore plus de solutions de collaboration aux utilisateurs.

Après avoir dressé un inventaire des applications en lien avec Exchange on-premise, chacune devra être évaluée au cas par cas, ce qui entraînera le dé-commissionnement de certaines. Vous devrez alors déterminer sous quelles formes les autres seront conservées.

Voici 5 stratégies de migration d'applications à prendre en considération.

• Réhéberger L’équipe IT déplace simplement l'application existante vers une plateforme IaaS (Infrastructure as a Service). Cette stratégie est rapide mais n'apporte aucune modernisation de l'application.
• Réviser : Cela consiste à modifier l’application pour profiter des avantages du cloud, tels que les conteneurs, et les nouvelles méthodes de stockage de données. Cette stratégie est axée sur la réduction des coûts d'exploitation grâce aux services managés du Cloud. Cependant, elle nécessite une expertise à la fois de l’application et des services Cloud pour éviter toute interruption de service lors du déploiement.
• Réarchitecturer : Contrairement à la révision, il s’agit ici d’une modification majeure de l’application afin qu’elle utilise essentiellement des technologies purement Cloud. Ici aussi, il faudra réunir une expertise importante de l’application et des services Cloud pour garantir la continuité de service y compris pendant les déploiements.
• Reconstruire : Il peut être tentant de réécrire totalement ou partiellement l’application. Elle pourra ainsi profiter des technologies les plus récentes et se débarrasser des compromis et handicaps sans alternative dans le passé. Le design pourra être simplifié et son architecture allégée. Avec Microsoft 365 Power App et Dynamics, même des non-développeurs pourront participer au projet. Le temps passé à corriger les bugs d’un code obsolète pourra être dédié à la création de nouvelles fonctionnalités.
• Remplacer : Enfin, la dernière stratégie consiste à remplacer l’application par une autre. Avec l’explosion des offres SasS, il est tout à fait possible qu’il en existe un répondant au cahier des charges de l’application initiale.

Lors de la planification d'un projet de migration par phases vers Exchange Online, il faut évidemment dimensionner chaque lot en fonction des capacités d’absorption du changement de l’organisation. La vitesse de migration ne doit pas être déterminée uniquement en fonction des contraintes techniques mais aussi en fonction de la charge maximale que le support sera éventuellement amené à traiter entre autres contraintes organisationnelles.

• Planification : Peu de projets sont suffisamment restreints pour pouvoir être mené à bien uniquement le week-end. La meilleure solution consiste à exécuter les lots de migration toute la semaine en continue tout en privilégiant les heures creuses pour les plus volumineux. Les taches finales avant basculement des utilisateurs seront planifiées en début de week-end afin que les migrations différentielles définitives et les actions post migrations puissent avoir lieu avant le retour des utilisateurs qui commenceront une nouvelle semaine en utilisant l’environnement cible sans même s’en rendre compte.
• Communication : La mise en œuvre d’un plan de communication avec les utilisateurs finaux est cruciale. Ils devront être informés du déroulement des étapes de migration qui peuvent les impacter et savoir qui contacter en cas de problème ou de questions. La mise en place de F.A.Q. accessibles en self-service permettra de soulager le support. Ce dernier devra être impliqué dans la conception du plan de communication afin de le rendre plus efficace. De plus le support devra aussi participer aux phases pilotes afin de pouvoir anticiper les problématiques rencontrées. Il devra avoir un accès facile et rapide aux différents journaux afin de diagnostiquer au plus vite les actions de remédiation à mener. 
• Dimensionnement des lots : Les lots de migration ne doivent pas être tous dimensionnés à l’identique en fonction de la capacité de migration maximale. Il est important de tenir compte des spécificités et difficultés locales : criticité de l’environnement, fuseau horaire, disponibilité d’une équipe support locale, bande passante disponible etc… Ces critères peuvent entrainer la diminution volontaire de la taille de certains lots.

Il n’est pas opportun de migrer les service fournis par l’Active Directory on-premise vers Azure Active Directory ou Azure AD Domain Services immédiatement. La migration vers Exchange Online est, de toute manière, une étape incontournable. Elle permettra de se familiariser avec l’administration d’Azure AD avant de basculer progressivement de plus en plus de services vers cette technologie pour bénéficier de sa sécurité et sa flexibilité.

La récente attaques HAFNIUM est un argument supplémentaire pour envisager de migrer vers Exchange Online et ne plus avoir à gérer la sécurité de l’infrastructure de messagerie. Une très grande majorité d’organisations a déjà commencé à migrer au moins une partie de ses boites aux lettres. La plupart considère qu’il ne s’agit que d’un premier pas avant une utilisation plus massive des applications Cloud telles que Teams, SharePoint Online, OneDrive, Power BI etc…

Par Regis Alix, Senior Principal Solutions Architect chez Quest Software