Comment une petite équipe chez Avanade a mené une migration de 2 000 sites avec ShareGate

Une entreprise manufacturière française faisait tourner un environnement SharePoint hybride. Les charges de travail récentes étaient déjà passées sur SharePoint Online, surtout poussées par l'adoption de Microsoft Teams. Mais le contenu hérité dormait toujours sur des serveurs SharePoint 2010 sur site.  

Une situation qui va vite devenir courante : SharePoint 2016 et 2019 arrivent en fin de support en juillet 2026, et 70 % des organisations que nous avons interrogées déclaraient encore avoir des données sur ces serveurs en mars 2025.

Le client d'Avanade voulait tout consolider dans le cloud et décommissionner ses serveurs, pour éliminer au passage des coûts d'infrastructure récurrents.  

Objectif simple. Environnement, beaucoup moins.

2 000 sites, 2 personnes et une décennie de complexité accumulée

La portée était costaude : 2 000 sites SharePoint et plus de 1,3 To de données. Et comme la source était SharePoint 2010, l'environnement traînait plus de dix ans de complexité accumulée : formulaires InfoPath, solutions sandbox, workflows personnalisés et injections JavaScript enfouies au fond des pages de sites.

Avanade a affecté deux personnes à la migration : Aimery Thomas, Microsoft MVP et Modern Workplace Manager chez Avanade, comme responsable technique, épaulé d'un développeur junior. Un architecte passait deux fois par semaine, mais l'exécution quotidienne reposait entièrement sur leurs épaules.

Pour un projet de cette taille, l'équipe avait besoin d'un outil capable d'abattre le gros du travail. Aucune place pour les procédures manuelles ou les rustines.

Les risques invisibles que les outils standards ne détectent pas

Au-delà des défis évidents, ce qui inquiétait Aimery, c'est ce qu'il ne voyait pas. Les injections de script, ce JavaScript intégré directement dans les pages SharePoint, sont notoirement difficiles à détecter. L'outil d'évaluation de migration SharePoint de Microsoft ne les repérait pas.

« On a dû construire un script PowerShell sur site pour identifier ce genre de complexités cachées », raconte Aimery.

Si ces complexités n'étaient pas attrapées avant la migration, elles ressortiraient en erreurs après. Et là, beaucoup plus difficiles et coûteuses à corriger.

L'évaluation d'abord : couper le projet en deux avant de migrer un seul site

Le premier réflexe d'Aimery n'a pas été de migrer. Ça a été de comprendre exactement à quoi il avait affaire.

Avec le rapport d'analyse de la source de ShareGate Migrate, l'équipe a évalué les 2 000 sites de l'environnement SharePoint 2010. Première découverte, et pas la moindre : environ 1 000 sites n'avaient enregistré aucune activité depuis plus de deux ans.  

Avec l'accord de l'entreprise, ces sites inactifs sont sortis de la portée du projet. Résultat : 50 % de moins. Donc un échéancier nettement plus court et des coûts de migration plus bas, avant même d'avoir déplacé le premier site.

« Prenez le temps qu'il faut pour évaluer la source. Parce que vous pourriez bien sortir la moitié des sites de votre périmètre », conseille Aimery.

L'équipe a ensuite poussé l'analyse sur les 1 000 sites restants, en classant chacun selon une série de critères de complexité : formulaires InfoPath, workflows actifs, solutions sandbox et injections de script. Tout site présentant un de ces critères était marqué complexe.  

Résultat : environ 800 sites simples et 200 complexes. Les simples passeraient en premier. Les complexes auraient droit à plus de temps.

Ce tri a transformé un projet tentaculaire et écrasant en deux phases gérables, avec un plan d'attaque clair.

Exécution automatisée, visibilité totale

Une fois la portée fixée, l'équipe a migré les 800 sites simples en quatre vagues. Chaque vague était équilibrée en tailles de sites et en nombres de fichiers pour garder une exécution prévisible.

Aimery, avec son bagage de développeur, s'est beaucoup appuyé sur le module PowerShell de ShareGate. L'équipe a scripté tout le processus : création des sites SharePoint Online cibles et déclenchement des migrations par programmation, sans passer par l'interface graphique.

« Ce que j'ai trouvé le plus utile, c'est de pouvoir lancer mes migrations ShareGate en PowerShell », dit Aimery. « Pendant la migration, on avait tellement d'autres choses à faire. Mais pour migrer, on n'avait qu'à déclencher l'exécution d'un script et tout se faisait automatiquement. »

Automatiser ne voulait pas dire avancer à l'aveugle. Même avec tout qui roulait en PowerShell, l'équipe suivait l'avancement en temps réel dans l'interface de ShareGate. Le contrôle d'un développeur, avec la supervision visuelle en prime. Pour une équipe de conseil qui livre des migrations en service, c'est cette combinaison qui permet à deux personnes de mener un projet qui en demanderait normalement quatre ou cinq.

Faire confiance aux rapports

Après chaque vague, l'équipe s'appuyait sur les rapports de migration de ShareGate pour confirmer que permissions, documents, métadonnées et tout le reste avaient bien atterri au bon endroit.

« On s'est vraiment fiés aux rapports de migration ShareGate », explique Aimery. « Si le rapport disait que tout était réussi, on lui faisait confiance. »

L'approche par vagues créait aussi des filets de sécurité naturels. Pendant que l'équipe migrait la vague deux, les utilisateurs de la vague un avaient des semaines pour vérifier leurs sites. L'équipe d'Aimery restait disponible en hypercare tout du long. Aucun document manquant n'a été signalé.

Quand les rapports signalaient un problème, l'équipe avait aussi un système. Elle maintenait un fichier de correspondance reliant chaque type d'erreur des rapports ShareGate à une action corrective précise. Les problèmes de colonnes de recherche, par exemple, se réglaient avec une migration incrémentale. Aucune devinette, juste un playbook documenté.  

C'est le genre de processus qui passe à l'échelle. Le même fichier de correspondance et la même gestion d'erreurs se réutilisent tels quels sur le mandat suivant, sans repartir de zéro.

Les sites complexes : moins complexes que prévu

Pour les 200 sites complexes, l'équipe a d'abord migré le contenu, puis évalué ce qui devait vraiment être reconstruit. Aimery a passé en revue les workflows de chaque site avec le client. Dans la plupart des cas, ils ont confirmé ne plus en avoir besoin.

Sur l'ensemble des sites complexes, seuls sept workflows ont dû être reconstruits dans Power Automate. Une dernière migration incrémentale a récupéré les modifications faites pendant la reconstruction, et le projet était bouclé.