Migrer SharePoint sans arrêter l'activité
Le difficile, dans une migration, n'est pas de déplacer des fichiers. C'est que personne ne cesse de travailler pendant qu'ils se déplacent.
Il y a 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 ce fait.
Nous avons choisi la seconde sur des farms globales à 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 toujours.
Ce que l'on apprend à regarder autrement
L'instinct 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 ne trouve pas le document dont elle a besoin à cet instant. Peu importe qu'il existe quelque part. Pour cette personne, à ce moment-là, le système a échoué. Et c'est là que la confiance se perd, 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 possède quoi, et lesquels portent des permissions que personne ne sait expliquer. Une part substantielle de ce que l'on trouve ne doit pas être migrée. Elle doit être archivée ou supprimée, et c'est une décision métier, pas 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 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 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 où source et cible coexistent, la source en lecture seule. Si quelque chose casse, personne ne se retrouve empêché 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 petit. Dans une migration big bang, la première erreur est publique, elle est grande, et elle atteint 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 dont on se souvient pour son week-end.
