La première question que se posent les clients lorsqu’ils se lancent dans un projet de migration dans Microsoft 365 est la suivante : « Combien de temps faudra-t-il pour migrer le contenu ? » J’ai compris ! C’est une question importante à poser à un prestataire qui s’apprête à déplacer vos données d’une plateforme à une autre.
En savoir plus :
- 3 choses à savoir avant de procéder à une migration Microsoft 365 de client à client
- Considérations importantes concernant la migration vers Microsoft 365 d’une entité à une autre
- Approches de migration vers Microsoft 365
- Consolidez votre environnement cloud – Migrez vos « Workloads/Applications » vers M365
Vous voulez effectuer une stratégie de migration vers Microsoft Office 365 et SharePoint en douceur ? Obtenez gratuitement notre Liste de contrôle pour la migration vers Office 365 et SharePoint dès aujourd’hui !
Dans cet article, je vais vous parler d’une autre question à poser avant de choisir le prestataire qui vous accompagnera dans votre projet de migration : « Dans quelle mesure votre processus de migration est-il fiable ? ».
Si la vitesse de migration est un élément important, les dates de début et de fin de la migration qui englobent toutes les activités d’un projet sont des facteurs bien plus importants qu’il convient de planifier et d’optimiser.
Avant d’aller plus loin, permettez-moi de vous expliquer quelque chose. Ici, chez AvePoint, nous avons effectué de très nombreux tests pour définir des attentes de performance de référence pour toutes sortes de scénarios : SP2010 – SPO, SPO vers SPO, File Share vers Microsoft Teams, etc. Pour chaque grande nouvelle version de DocAve ou FLY, ces tests nous donnent un cadre de référence initial. Cependant, ces références ne sont pas absolues et ne peuvent pas être appliquées uniformément d’un projet à l’autre. La variabilité entre les données est honnêtement trop importante et il est difficile de généraliser les résultats des performances en laboratoire pour les étendre à tous les environnements.
Nos années d’expérience nous ont appris qu’il existe un certain nombre de caractéristiques communes qui affectent la vitesse de chaque projet de migration des données, parmi lesquelles :
- les informations de base sur le contenu à déplacer (nous appelons cela les informations essentielles) ;
- les attributs connexes du contenu migré comme les métadonnées, les autorisations, etc. (nous appelons cela les informations secondaires) ;
- le matériel disponible pour effectuer les tâches de migration ;
- les restrictions et limitations imposées aux points de terminaison source et de destination par les prestataires pour garantir la fiabilité de la plateforme ;
- l’architecture et la performance de base de l’outil de migration choisi pour effectuer la migration ; et
- l’efficacité du processus de migration et le temps d’activité des tâches.
Je ne reviendrai pas sur les caractéristiques ci-dessus dans la mesure où j’en ai déjà parlé dans des articles précédents. À la place, je vais vous parler du facteur primordial qui est souvent oublié et qui aura pourtant un impact bien plus important sur la durée globale de votre projet que l’on pourrait le croire : l’efficacité du processus et le temps d’activité des tâches.
Pour faire simple, vous devez vous assurer que votre plateforme de migration fonctionne au maximum de sa capacité lorsque vous effectuez simultanément plusieurs tâches. Vous devez également vous assurer qu’il n’y a pas d’interruption entre les tâches et que le taux d’échec des tâches est faible. Lisez la suite pour connaître les trois éléments à prendre en compte lors d’une migration vers Microsoft 365.
Capacité de l’infrastructure
C’est l’idée que vous devez maximiser votre plateforme de migration en fonction des objectifs du projet et du volume de contenu à déplacer. Vous devez également vous assurer de choisir la bonne infrastructure et d’optimiser le nombre d’agents pour renforcer la simultanéité des tâches sur votre plateforme de migration. N’oubliez pas qu’à un certain point, vous serez limité par Microsoft si vous effectuez trop de tâches simultanément.
Il est difficile de déterminer où se trouve ce seuil, c’est pourquoi nous vous recommandons d’augmenter progressivement votre capacité disponible tout en surveillant les codes indiquant une erreur de limitation. Il serait donc contreproductif d’effectuer une migration avec 10 agents, cela risquerait de déclencher une limitation qui ralentirait tout. Cette ligne est fluide et doit être ajustée.
Périodes d’indisponibilité
Lorsque vous avez investi dans une architecture de migration, vous avez envie de maximiser le nombre de tâches qui seront migrées à tout moment. L’investissement consacré aux ressources de votre infrastructure est trop élevé pour vous permettre d’avoir des serveurs inactifs. Lorsque nous effectuons des migrations, nous intégrons généralement des scripts de tâches aux groupes de tâches pour nous assurer que, lorsque le nombre de tâches diminue, les tâches suivantes dans la file d’attente sont automatiquement sélectionnées et exécutées sans qu’aucune intervention humaine ne soit nécessaire.
Cela permet au groupe technique de se concentrer davantage sur la résolution des problèmes et les rapports de tâches que sur la programmation et le démarrage des tâches, ce qui peut arriver à n’importe quel moment de la journée. Une fois encore, vous devez vous assurer que toutes les heures machines disponibles soient consacrées à l’exécution des tâches.
Taux d’erreur
Bien qu’impressionnante, une tâche affichant un débit de 20 Go par heure le devient beaucoup moins si elle multiplie les erreurs qui vous obligeront à évaluer et résoudre les problèmes et programmer des ré-exécutions. Certaines sources ont plus tendance à afficher un taux d’échec des objets élevé, et les délais d’expiration et les seuils contribuent à la nécessité de ré-exécuter certaines tâches. D’après notre expérience, c’est là que les projets perdent le plus de temps. Imaginez ce qui peut se passer si votre plateforme de migration est inactive pendant que vous consacrez tout votre temps à résoudre les codes d’erreur des tâches et à ré-exécuter les tâches de migration.
S’il est inévitable qu’il y ait quelques rapports d’erreur, nous vous conseillons de prendre le temps en amont de placer les sites qui, d’après nos outils de découverte, sont susceptibles d’avoir des taux d’erreur supérieurs à la normale dans des conteneurs distincts de ceux des autres sources qui ne montrent aucun symptôme d’erreur. Il convient par ailleurs de noter que certaines erreurs peuvent être corrigées et d’autres, non.
Il est donc important de s’assurer d’avoir un moyen d’examiner les rapports d’erreur au niveau macro et de filtrer les codes d’erreur qui doivent être gérés par les utilisateurs. Vous devez également faire en sorte de disposer d’un mécanisme efficace pour signaler les échecs d’objet aux utilisateurs au cas où les utilisateurs devraient prendre des mesures pour corriger les fichiers directement. Envoyer des e-mails à des centaines de milliers d’utilisateurs avec des rapports de tâche individuels n’est pas une mince affaire et il convient d’en tenir compte lors de la phase de conception.
Conclusion
En résumé, si vous voulez que votre projet de migration se passe bien, il est essentiel de se concentrer sur l’efficacité du processus et le temps d’activité des tâches. En réduisant vos périodes d’indisponibilité, en évitant les limitations et en gérant correctement votre taux d’erreur, chaque migration vers Microsoft 365 sera toujours relativement fluide. Vous avez des conseils à partager ? N’hésitez pas à nous les envoyer ci-dessous !
Produits AvePoint
Vous ne savez pas quoi faire quand votre projet de migration vient au premier plan ? L’outil de migration AvePoint ouvre la voie à votre transformation digitale, que vous migriez vers la dernière version de SharePoint ou le cloud.
Pour en savoir plus sur Microsoft 365, n’oubliez pas de vous abonnez à notre blog !
