Migration SharePoint - Comment réussir sa transition sans casse ?

Une migration SharePoint réussie ne consiste pas à copier des fichiers d’un point A vers un point B. Il faut aussi préserver les droits d’accès, les métadonnées, les pages et les automatisations qui font tourner l’espace de travail au quotidien. Dans un environnement Microsoft, ce sujet touche vite Teams, OneDrive, Power Automate et la gouvernance des données, donc un mauvais choix de méthode se paie cash.

Ce que doit vraiment préserver une migration SharePoint

Je vois encore trop souvent des projets réduits à une copie de bibliothèques. C’est insuffisant, parce qu’un site SharePoint utile repose aussi sur ses droits, son arborescence, ses pages, son moteur de recherche et parfois ses automatisations. Quand je prépare un transfert, je fais donc le tri entre ce qui est du contenu pur et ce qui relève de la logique métier.

• le contenu, c’est-à-dire les documents, dossiers, listes et bibliothèques ;
• la structure, avec les sites, sous-sites, pages et la navigation ;
• le contrôle, donc les permissions, les groupes et l’héritage des droits ;
• la connaissance métier, avec les types de contenu, le term store et les métadonnées ;
• l’automatisation, autrement dit les workflows, formulaires et intégrations.

Avec un site standard, les chances de reprise sont bonnes. Les sites “out-of-the-box”, sans code ni outil tiers, se déplacent plus proprement, et les outils Microsoft savent conserver plusieurs éléments utiles comme la navigation, les pages ou certaines web parts. En revanche, tout ce qui dépend de code personnalisé, de solutions tierces ou de formulaires anciens doit être traité comme un chantier à part. C’est ce tri qui me permet ensuite de choisir une cible réaliste.

Quelle cible choisir en 2026

Avant de lancer le moindre export, je décide si l’objectif est le cloud ou une nouvelle ferme locale. La politique de cycle de vie Microsoft place SharePoint Server 2016 et SharePoint Server 2019 à leur fin de support étendu le 14 juillet 2026, ce qui change clairement la donne. En pratique, je n’irais pas bâtir une stratégie durable sur 2019. Si vous restez on-premises, la cible logique est plutôt SharePoint Server Subscription Edition.

Si vous visez Subscription Edition, le chemin passe par la méthode database-attach: on crée une nouvelle ferme, on copie ou restaure les bases de contenu et de services, puis on les attache pour les mettre à niveau. Ce n’est donc pas un simple clic d’upgrade. Et si vos workflows datent encore de SharePoint 2013, je les mets déjà dans le plan de transformation, car ils ont été retirés de SharePoint Online le 2 avril 2026. Une fois la cible fixée, je passe au diagnostic du terrain réel.

Ce qu’il faut inventorier avant de toucher aux données

Microsoft Learn indique que la SharePoint Migration Tool, dans ses versions récentes, intègre directement l’évaluation des sites SharePoint Server. Je m’en sers comme point de départ, parce qu’un scan me donne tout de suite la cartographie des risques au lieu de les découvrir pendant le cutover. Si vous utilisez encore la SharePoint Migration Assessment Tool, je conseille de prévoir sa sortie avant le 1er octobre 2026 et de basculer sur cette capacité de scan.

• les sites, sous-sites, bibliothèques et listes réellement utilisés ;
• les permissions héritées, les groupes AD/Entra ID et les accès externes ;
• les versions, les types de contenu, le term store et la navigation ;
• les web parts, formulaires, flux et solutions tierces ;
• les contraintes de volume, de noms de fichiers et de quotas.

Je classe ensuite chaque élément dans trois bacs: migrer tel quel, migrer avec adaptation, ou reconstruire. C’est là que je décide aussi si je garde une structure classique ou si je modernise le site. Les taxonomies globales exigent des droits d’administrateur global, donc je sécurise cet accès très tôt. À partir de ce tri, je peux préparer un pilote qui ressemble vraiment à la production.

La méthode que je recommande pour déplacer les sites sans tout casser

Je ne lance jamais un gros lot en premier. Je commence par une zone représentative, puis je répète sur des lots plus larges quand les résultats sont stables. Le bon enchaînement, à mes yeux, ressemble à ceci:

1. Préparer la destination avec les groupes, les quotas, les conventions de nommage, les hubs et les politiques de partage.
2. Exécuter un pilote sur un site ou un sous-ensemble vraiment typique.
3. Lancer les lots avec synchronisation incrémentale pour ne reprendre que les éléments nouveaux ou modifiés.
4. Vérifier les droits, la navigation, la recherche, les pages et les workflows avec des utilisateurs métier.
5. Basculer dans une fenêtre de gel, passer l’ancien environnement en lecture seule, puis faire le delta final.

Pour les sites SharePoint on-premises, j’utilise surtout SPMT. Pour les partages de fichiers qui doivent atterrir dans SharePoint, OneDrive ou Teams, Migration Manager est souvent plus adapté, parce qu’il s’appuie sur des agents et accepte des fichiers jusqu’à 250 Go. Sur un projet Microsoft 365 éligible, FastTrack peut ajouter la planification, le suivi et les rapports. Quand j’ai beaucoup de sources, je passe aussi par des fichiers CSV ou JSON pour industrialiser les lots. Même avec cette méthode, certaines erreurs reviennent sans cesse.

Les erreurs qui coûtent le plus cher

Quand un projet dérape, ce n’est presque jamais à cause d’un seul bug. C’est plutôt un empilement de petits oublis qui deviennent visibles au moment où les utilisateurs reviennent. Les erreurs que je croise le plus sont toujours les mêmes:

• Confondre copie et migration. Copier des fichiers ne garde pas les droits, les pages, les liens ni les usages.
• Ignorer la taxonomie. Les métadonnées, le term store et les types de contenu sont souvent sous-estimés, alors qu’ils structurent la recherche et le classement.
• Traiter les workflows anciens comme s’ils étaient encore valides. Les workflows SharePoint 2013 doivent être refondus vers Power Automate ou une alternative supportée.
• Sautez le pilote. Un test court, mais représentatif, révèle souvent les vrais problèmes avant qu’ils ne deviennent chers.
• Remplir la cible trop vite. FastTrack recommande de rester sous 75 % de la capacité globale de SharePoint, stockage additionnel compris, pour garder de l’air pendant la migration.
• Oublier le réseau. SPMT ne fonctionne pas bien derrière des connexions proxy, donc je valide l’architecture réseau avant de démarrer.

La plupart de ces erreurs se corrigent avant le démarrage; après coup, elles coûtent beaucoup plus cher. Le point suivant, c’est donc la validation post-bascule et la manière dont on ferme proprement le projet.

Ce que je valide après la bascule pour clôturer proprement

Après la copie, je ne déclare pas la migration terminée. Je vérifie d’abord que la recherche remonte les bons contenus, que les permissions donnent exactement les bons résultats, que les pages s’ouvrent, que les liens profonds tiennent et que les workflows critiques repartent sans contournement. Je fais aussi valider le nouvel espace par quelques utilisateurs métier, parce qu’un site techniquement sain peut encore être ergonomiquement déroutant.

• valider la recherche, les filtres et l’accès aux documents importants ;
• contrôler les droits réels, pas seulement les groupes théoriques ;
• former les utilisateurs sur les nouveaux emplacements, les hubs et les automatismes ;
• garder l’ancien environnement en lecture seule le temps de la stabilisation.

Si je devais garder une seule règle, ce serait celle-ci: une bonne migration SharePoint ne se juge pas au volume déplacé, mais à la vitesse à laquelle les équipes reprennent leur travail sans contournements ni perte de repères. C’est ce niveau de continuité qui transforme un projet technique en vraie valeur métier.