Planifier soigneusement votre migration est essentiel pour réussir votre projet de migration. Voici des sujets qui peuvent avoir un impact sur votre migration et qui doivent être pris en compte lors de la phase de planification.

Les listes de contrôle pour la migration sont des documents PDF qui peuvent vous aider à prendre en compte tous les aspects de votre environnement pour votre migration.

Pour télécharger La liste de contrôle ultime pour la migration SharePoint, cliquez ici.

Pour télécharger La liste de contrôle essentielle pour la migration Microsoft Teams, cliquez ici.

Même si ShareGate Migrate propose une interface simple, il s'agit d'une application complexe côté client qui effectue de nombreuses interactions avec vos environnements via les API Microsoft.

En raison des restrictions de ces API et des différentes versions possibles de SharePoint, il est important de prendre en compte les limitations suivantes.

L'apparence et la convivialité dépendent d'éléments comme les mises en page de page, les pages maîtres et les solutions personnalisées, ce que nous ne pouvons pas prendre en charge. Le problème provient des différentes versions de SharePoint et du fait que nous ne pouvons pas déterminer comment une solution personnalisée affectera votre destination.

Pour plus d'informations sur ces limitations et d'autres, consultez Apparence et convivialité ou Pages maîtres et mises en page.

ShareGate Migrate ne prend pas entièrement en charge les solutions personnalisées et tierces.

Les solutions personnalisées peuvent affecter les pages, les colonnes de liste, les types de contenu et de nombreux éléments dans un environnement SharePoint local.

Si vous migrez vers un environnement local, vous pouvez essayer d’installer votre solution personnalisée ou tierce dans votre environnement de destination avant la migration si elle est disponible. Parfois, avoir la solution personnalisée disponible à la destination peut permettre à l’application de migrer du contenu qui ne serait autrement pas pris en charge.

Effectuer une analyse de la source devrait révéler toute solution personnalisée dans votre environnement (plus d’informations sur l’analyse de la source ci-dessous).

Les collections de sites avec un verrouillage en lecture seule actif ne migreront pas correctement. Cette fonctionnalité interfère avec les API SharePoint et provoquera de nombreux messages d’erreur imprévisibles. Vous devez désactiver cette fonctionnalité pour pouvoir migrer.

Pour plus d’informations sur ces limitations, consultez Verrouillage en lecture seule.

Effectuer une analyse de la source vous permet d’établir un inventaire de votre environnement source.

Cela vous donnera un aperçu de tout ce que vous avez dans la source et un accès à une liste détaillée que vous pouvez exporter au format Excel ou CSV.

La liste peut révéler du contenu non pris en charge ainsi que des erreurs et avertissements généraux que vous pouvez examiner avant même de commencer votre migration.

Pour plus d’informations, consultez Guide pas à pas – Analyse de la source d’un partage de fichiers et Guide pas à pas – Analyse de la source SharePoint et Microsoft 365.

Il y a trop de facteurs dans une migration pour pouvoir fournir une estimation fiable du temps nécessaire.

Voici quelques facteurs qui peuvent influencer la durée de votre migration :

Parce qu’une migration SharePoint n’est pas un simple transfert de fichiers, il est impossible de déterminer combien de temps prendra votre tâche de migration.

La meilleure façon d’obtenir une estimation pour votre contenu spécifique est de faire des tests. La prochaine section de cet article montre comment vous pouvez avoir une idée du temps que pourrait prendre votre migration.

Effectuer une migration test dans votre environnement est la meilleure façon d’estimer le temps de migration et d’identifier les défis à relever. Cela vous aidera à établir un plan de migration plus réaliste.

Nous vous suggérons de vérifier votre rapport de migration à la fin de votre migration test. Le rapport pourrait révéler des avertissements et des erreurs que vous pourriez rencontrer lors de la migration. Pensez également à augmenter votre estimation du temps de migration au cas où vous auriez à résoudre un problème lors de la migration réelle.

Pour avoir une idée générale du temps nécessaire pour migrer plusieurs collections de sites, identifiez un site qui représente bien votre collection de sites moyenne et migrez-le.

Utiliser le temps nécessaire pour migrer une collection de sites moyenne dans votre environnement vous donnera une bonne base pour estimer la durée totale de la migration de plusieurs collections de sites.

Pour avoir une idée générale du temps de migration de votre contenu, trouvez un dossier ou une bibliothèque contenant au moins un gigaoctet de documents qui représente bien votre projet global, et migrez-le. Cela vous donnera une métrique pour estimer combien de temps prendra la migration de l’ensemble de vos données.

Par exemple, si un gigaoctet de données a pris une heure à migrer, vous pouvez estimer que votre contenu se migrera à un rythme d’un gigaoctet par heure.

Vous pouvez supprimer tout ce qui n’est pas utilisé dans votre environnement source pour réduire la portée globale de votre migration et accélérer le processus.

Vous pouvez exécuter le rapport de sites inutilisés pour analyser votre environnement source (SharePoint 2010 et versions ultérieures), et créer des rapports personnalisés si vous souhaitez rechercher du contenu dans vos sites.

Grâce à ces rapports, vous pouvez archiver le contenu inutilisé dans la source avant la migration, ou omettre ces éléments dans votre plan de migration.

Il peut être difficile de migrer une grande collection de sites avec de nombreux sous-sites. Une telle migration générera un rapport de migration très volumineux et compliquera la résolution des erreurs.

Si vous obtenez une défaillance du serveur qui interrompt votre migration, l’application ne pourra pas reprendre cette migration, et il sera très difficile de déterminer ce qu’il reste à migrer pour éviter de devoir recommencer la migration de toute la collection de sites.

Pour faciliter la gestion de la migration d’une grande collection de sites, nous recommandons de migrer la collection de sites sans ses sous-sites, puis de migrer les sous-sites en petits lots.

Migrez seulement quelques sous-sites à la fois et tenez compte de leur taille ou complexité lorsque vous divisez la migration.

Pour migrer la collection de sites parent sans ses sous-sites, rendez-vous dans les options de copie et décochez Subsites.

Vous pouvez ensuite vous connecter à votre collection de sites à la source et à la destination. Dans la fenêtre de migration, double-cliquez sur le nom de la collection de sites dans les panneaux source et destination pour afficher les sous-sites. Sélectionnez quelques sous-sites et migrez-les.

Selon le niveau de personnalisation de votre environnement et ce qui est pris en charge à la destination, il se peut que certaines métadonnées ne soient pas prises en charge ou difficiles à conserver.

En cas de limitation ou de problème avec les métadonnées, vous pouvez gagner du temps en déterminant quelles données sont importantes pour votre organisation. Une bonne communication est essentielle pour une migration rapide et réussie.

Voici quelques éléments clés à retenir concernant la migration des métadonnées :

Les utilisateurs qui ne sont pas présents dans l’annuaire actif de votre destination sont appelés utilisateurs non résolus.

ShareGate Migrate ne peut pas ajouter un utilisateur non résolu à une colonne Person or Group lors d’une migration vers une destination SharePoint locale. Cela inclut les champs Created by et Modified by.

L’application peut conserver les utilisateurs non résolus et les valeurs de groupe lors d’une migration vers Microsoft 365 uniquement en Insane mode.

Insane mode comporte quelques limitations qui peuvent faire en sorte qu’une liste ou une bibliothèque soit automatiquement migrée en mode Normal dans Microsoft 365. Lorsque la migration de la liste repasse en mode Normal, l’application perd la capacité de conserver les utilisateurs non résolus.

Vous pouvez créer un mappage des utilisateurs si vous souhaitez remplacer les utilisateurs et groupes non résolus par d’autres comptes ou groupes dans ce cas.

Pour plus d’informations sur la façon dont les utilisateurs sont associés lors d’une migration, cliquez sur Association des utilisateurs et groupes (mappage automatique).

Les ID des éléments de liste ne sont pris en charge que lors d’une migration vers une destination Microsoft 365 avec Insane Mode.

Comme pour les utilisateurs non résolus, les limitations de l’Insane mode peuvent faire en sorte qu’une liste ou une bibliothèque soit migrée en mode Normal, et que les ID des éléments de liste soient remplacés par de nouveaux.

Les ID des éléments de liste ne sont pas pris en charge en mode normal ni dans aucune version locale de SharePoint.

Pour plus d’informations, consultez ID des éléments de liste.

Les pages sont en partie constituées de références à votre environnement SharePoint. Elles sont partiellement reconstruites par ShareGate Migrate pour fonctionner à la destination.

Vous pourriez perdre certains éléments de vos pages s'ils font référence à quelque chose qui n'existe pas dans la destination.

Un problème courant concerne la migration de votre page d'accueil, selon la façon dont elle est définie dans votre source. Les anciennes versions de SharePoint plaçaient la page dans le dossier racine de votre site.
Cela complique la migration de la page d'accueil seule en cas de problème.

Pour plus d'informations, consultez Migration de la page d'accueil (Home.aspx et default.aspx).

Tous vos composants WebPart ne sont pas pris en charge lors de la migration vers un site moderne dans Microsoft 365.

Pour plus d'informations, consultez Composants WebPart pris en charge pour l'expérience moderne de Microsoft.

La principale préoccupation lors des migrations vers l'expérience moderne dans Microsoft 365 est de perdre l'expérience moderne dès que vous migrez des pages utilisant l'expérience classique dans un site moderne.

Lorsque vous migrez une page classique, SharePoint appliquera l'expérience classique pour la navigation et l'apparence de cette page dans la destination.

Les formulaires Infopath ne sont pas compatibles avec l'expérience moderne. Ils seront copiés dans la destination, mais Infopath ne peut pas être ouvert dans une liste avec l'expérience moderne.

Vos utilisateurs devront passer leurs listes à l'expérience classique s'ils souhaitent utiliser leurs formulaires Infopath.

Un custom script est requis pour la plupart des migrations et la fonctionnalité n'est activée automatiquement lors de la migration vers un site moderne que si vous disposez des autorisations d'administrateur global ou d'administrateur SharePoint.

Pour savoir comment un administrateur global ou un administrateur SharePoint peut activer la fonctionnalité manuellement pour vous si vous ne disposez pas de ces autorisations, consultez La copie vers une collection de sites Microsoft 365 nécessite l’activation des Custom Scripts à la destination.

Si vous migrez une collection de sites telle quelle dans votre destination, les autorisations seront répliquées tant que vos utilisateurs et groupes de sécurité (AD) sont disponibles dans la destination.

Votre projet de migration est une excellente occasion d'évaluer la structure actuelle de vos autorisations et de voir comment vous pouvez la simplifier.

Vous pouvez valider vos autorisations avec le rapport de matrice des autorisations.

Votre migration sera plus simple et votre destination plus facile à gérer si vous pouvez supprimer les autorisations personnalisées inutiles.

Lorsque vous rétrogradez une collection de sites en sous-site ou que vous promouvez un sous-site pour en faire une collection de sites à la destination, vos autorisations personnalisées sont généralement conservées, mais vous constaterez quelques changements dans les groupes par défaut (membres, propriétaires et visiteurs).

Pour plus d'informations sur la gestion de vos autorisations, cliquez sur le scénario approprié ci-dessous :

Si vos documents comportent de nombreuses versions, leur migration peut prendre plus de temps. Essayez de déterminer combien de versions récentes vous avez réellement besoin de conserver. Si votre organisation ne réalise pas d'audits sur le contenu, votre migration pourrait être plus rapide si vous limitez le nombre de versions par fichier dans vos options de copie.

Des erreurs peuvent survenir sur les versions précédentes d'un élément lors de la migration. Si vous n'êtes pas obligé de conserver toutes vos versions, la solution la plus simple est de limiter le nombre de versions à conserver pendant la migration.

Testez et évaluez soigneusement vos scripts PowerShell avant d'exécuter vos migrations afin d'éviter tout problème, comme la copie de fichiers vers la mauvaise destination à cause d'une erreur ou d'une faute de frappe dans un script.

Prenez le temps de bien vous familiariser avec nos commandes avant de lancer une migration PowerShell.

Maintenant que vous savez comment utiliser ShareGate Migrate et à quoi faire attention, vous pouvez commencer à établir votre calendrier de migration.

Commencez par ce que vous avez appris lors de vos tests. Définissez un temps moyen de migration pour vos collections de sites, tenez compte des grandes bibliothèques, des autorisations et de tout le reste, puis déterminez comment vous souhaitez effectuer votre migration.

Pendant que vous effectuez votre migration, il est probable que vos utilisateurs continuent d'utiliser l'environnement source.

Comme vous ne pouvez pas verrouiller vos sites pendant la migration, il est essentiel de mettre en place un bon plan de communication avec vos utilisateurs. C'est particulièrement important si vous gérez une migration de grande envergure.

Pensez à communiquer les informations suivantes à vos utilisateurs :

Suivant

"Cet article a été traduit à l'aide de l'intelligence artificielle. En cas de doute, veuillez vous référer à la version originale en anglais."