Migrer SharePoint sans arrêter l'activité
Le plus difficile, dans une migration, n'est pas de déplacer des fichiers. C'est que personne ne s'arrête de travailler pendant qu'ils se déplacent.
Il existe deux façons de mener une migration SharePoint. La première : choisir un week-end, tout éteindre, copier et prier. La seconde : accepter que l'activité ne puisse pas s'arrêter, et concevoir la migration autour de cette contrainte.
Nous avons choisi la seconde sur des farms mondiales à la Commission européenne, sur l'intranet de publication du gouvernement irlandais et lors de migrations d'on-premises vers SPFx chez des clients du Fortune 500. Le schéma se répète invariablement.
Ce que l'on apprend à regarder autrement
Le réflexe naturel est de traiter la migration comme un problème de transport de données. Nous l'avons fait aussi, au début. Ce n'en est pas un. C'est un problème de continuité.
Les fichiers finissent toujours par arriver. Ce qui ruine un projet, c'est le jour où une équipe ouvre le portail et n'y trouve pas le document dont elle a besoin à cet instant précis. Peu importe qu'il existe quelque part. Pour cette personne, à ce moment-là, le système a échoué. Et c'est là que se perd la confiance, bien plus coûteuse à regagner que n'importe quel fichier.
Ce que nous faisons avant de déplacer le moindre octet
Un véritable inventaire. Il ne s'agit pas de compter des sites. Il s'agit de comprendre lesquels sont vivants, lesquels plus personne n'ouvre depuis des années, à qui appartient quoi, et lesquels portent des permissions que personne ne sait expliquer. D'après notre expérience, une bonne partie de ce que l'on y trouve n'a pas vocation à être migrée : il faut l'archiver ou la supprimer, et c'est une décision métier, non technique.
Une carte des dépendances. Flux, formulaires, personnalisations, intégrations bâties il y a sept ans et qui alimentent encore un rapport que le conseil d'administration lit chaque lundi. C'est là que se cachent les surprises.
Une décision sur l'existant. Les web parts classiques ne survivront pas. La question n'est pas de savoir comment les convertir, mais si elles méritent de l'être. Souvent, la réponse honnête est non.
Par vagues, pas en big bang
On déplace par groupes aux frontières nettes : une direction, une fonction, un ensemble de sites ayant le même propriétaire. Chaque vague comporte une période pendant laquelle la source et la cible coexistent, la source étant en lecture seule. Si quelque chose casse, personne ne se retrouve dans l'impossibilité de travailler : on recule d'une vague, pas de tout le projet.
C'est plus lent sur le papier. C'est bien plus rapide dans les faits, car il n'y a pas d'arrêt imprévu.
Ce que l'on gagne à procéder ainsi
On gagne le droit d'échouer à petite échelle. Dans une migration big bang, la première erreur est publique, elle est massive, et elle remonte à la direction le jour même. Par vagues, la première erreur touche trente personnes, se corrige en une matinée, et la vague suivante ne la répète pas.
Rien n'est laissé au hasard. Voilà la différence entre une migration dont on se souvient pour son résultat et une migration dont on se souvient pour son week-end.
