Migrer vers SharePoint 2013 : les questions à se poser avant de migrer

Quelle vision a-t-on de l’existant ?

Généralement, lorsque l’on parle de migration, un raccourci est rapidement fait sur le contenu uniquement. Effectivement, avoir une bonne vision de son corpus documentaire est nécessaire, mais il faut prendre en compte l’intégralité de l’environnement : infrastructure réseau et matérielle, cartographie des utilisateurs, annuaire et implémentation de la sécurité, interactions avec d’autres systèmes (CRM, ERP,  GED…)… S’il est souvent impossible d’avoir un cliché  instantané de l’ensemble, réunir les différents acteurs du SI permet non seulement de dresser une vue d’ensemble la plus  complète possible mais également d’identifier les individus à impliquer aux différents stades du projet de migration.  De cette vision d’ensemble, pourront ensuite se dégager les premiers points de vigilance.

Parmi ceux-ci :

• Compte tenu de l’infrastructure – matériel, réseau, logiciel  – requise par SharePoint 2013, de la taille du projet, de  son étendue géographique, on pourra décider de conserver l’infrastructure en place ou au contraire la décommissioner et partir sur une toute nouvelle plateforme. C’est peut-être également une occasion d’accroître le niveau de sécurité en changeant le moyen d’authentification sur l’infrastructure, SharePoint 2013 proposant par défaut une authentification de type claims ainsi que des améliorations de cette infrastructure.

La cartographie des utilisateurs peut être un outil de décision important : j’ai souvent été confronté à des environ-nements (SharePoint ou LiveLink) dans lesquels plusieurs milliers d’utilisateurs étaient déclarés mais qui pour autant  n’étaient pas ou très peu actifs.

De fait, comment dimensionner l’architecture cible ? Cette question du ratio entre utilisateurs  enregistrés et utilisateurs actifs peut également permettre d’orienter son choix stratégique : choisir Office 365 et une facturation à l’utilisateur ou un environnement on premise dans lequel une licence pour chaque utilisateur pouvant accéder à SharePoint devra être achetée. De cette cartographie, on pourra également définir si les utilisateurs doivent conserver   le même niveau de permissions une fois migrés ou s’il s’agit d’un point qui devra faire l’objet d’une vigilance particulière.

• La structuration de l’annuaire d’entreprise permet-elle de répondre aux exigences techniques / métier ? J’ai rencontré ce cas concret sur un projet d’Intranet global, pour lequel la structure de l’annuaire ne permettait pas d’identifier la localisation géographique d’un utilisateur, remettant en cause une architecture décentralisée. Il peut être important de devoir restructurer l’annuaire pour tirer au mieux parti de SharePoint 2013 dans une telle configuration.

• Toujours à propos de l’annuaire, identifier avant la migration la liste des comptes utilisateurs désactivés ou supprimés permet d’éviter de rencontrer des problèmes de performance lors de la recherche de mapping utilisateurs au moment de la migration, ou d’empêcher simplement la migration des contenus.

Quelle est la quantité de contenu à migrer ?

Cette question pose également celle de la quantité totale des contenus existants, tenant compte non seulement des documents mais aussi des images, des pages, ainsi que du nombre de versions pour chacun de ces objets. Il faut également prendre en compte les contenus hébergés sur des serveurs de fichiers externes. Avoir une idée précise de cette valeur permet non seulement de dimensionner correctement l’environnement de destination, mais également de définir une stratégie de migration adéquate :

• La totalité des informations doit-elle être migrée ?

• Faut-il purger les contenus préalablement à la migration ?

• Une stratégie d’archivage doit-elle être mise en place ?

• Une stratégie d’externalisation du contenu via RBS doit-elle être mise en place ?

Se poser cette question et élaborer la stratégie adéquate permet de jouer sur différents leviers tels que la quantité de données à migrer, la durée de la migration, les temps d’indisponibilité de la plateforme, les risques d’échecs…

Quel est le niveau de personnalisation de la source ?

Cette question va prendre son plus grand sens dans le cadre d’une migration d’une version antérieure de SharePoint vers SharePoint 2013 ou SharePoint Online. Hors de ce cadre, il devient plus complexe d’envisager une migration des personnalisations. Tout d’abord, il faut distinguer plusieurs types de personnalisations.

Les customisations d’ordre graphique par exemple (HTML, CSS) peuvent difficilement être migrées, la structure des pages étant différente ; les customisations utilisant un outil tiers doivent être abordées sous un autre angle conjointement avec l’éditeur.

Si le support de SharePoint 2013 est possible, un outil de migration – ou du support technique – est peut-être disponible. Ensuite, déterminer l’impact des customisations sur la cible. Dans le cadre de développements liés à un besoin métier, faut-il redévelopper un composant ? Utiliser une feature SP2013 native répondant à ce même besoin ? Redéfinir le besoin métier ? Ou simplement ignorer la customisation ? Par exemple : est-ce que des workflows sont utilisés dans l’environnement source ? Le point est important car potentiellement bloquant, selon les exigences métiers.

Si l’environnent source est SharePoint 2010, les workflows peuvent être migrés, SharePoint 2013 proposant un mode de compatibilité.

Les workflows MOSS 2007 sont en revanche non compatibles. Qu’en est-il des workflows proposés par des éditeurs tiers ? Quid de ceux en place sur des environnements source non SharePoint ?

Quel niveau d’exigence avoir ?

Les exigences techniques ne posent généralement pas trop de problèmes une fois que l’audit de l’existant est effectué. En revanche, le niveau d’exigence fonctionnelle va souvent  impacter la durée de la phase d’étude pré-migration (d’autant  plus si plusieurs acteurs métier sont impliqués). Une des exigences métier que j’ai pu le plus souvent rencontrer  est celle de la structuration des données. Dans ce cas précis, il est, d’après mon expérience, difficile de parvenir à un consensus et des outils tiers effectueront parfaitement les tâches de restructuration de SharePoint après la migration. Il peut être intéressant de soulever ce point et le gérer comme un projet annexe. Une autre exigence concerne le niveau de fidélité que l’on doit attendre des données migrées. Qu’est-ce que la « fidélité » des  données ? Les éléments propres au contenu tout d’abord. La langue, les caractères utilisés dans le nom du fichier, les différentes métadonnées gérées par un système source, la sécurité  paramétrée sur un document… ensuite les éléments propres au(x) conteneur(s), qui seront globalement les mêmes que pour le contenu mais appliqués aux répertoires, site, bibliothèques, etc. Requérir une fidélité complète de ces données peut être une exigence faible dans un contexte de migration depuis SharePoint ou un système de fichier Microsoft vers SharePoint 2013 ou Online.

En revanche, cela peut être une contrainte forte dans le cas d’un autre type de migration car techniquement différent : par exemple, les champs « Auteur »  et « Lecteur » de Lotus Notes. Ces champs de métadonnées, s’ils sont renseignés, déterminent les permissions qu’auront des utilisateurs sur le contenu. S’il n’y a ni pendant fonctionnel ni technique direct dans SharePoint, cette fonctionnalité est néanmoins reproductible et une adaptation peut être envisagée.

Mais cette adaptation a un coût à prendre en compte, qui va déterminer le niveau d’exigence quant à l’acceptabilité de la perte de quelques-unes ou toutes les métadonnées de mes contenus, et/ou de la sécurité qui y est paramétrée.

Quel est le type de migration attendu ?

Il existe plusieurs façons d’envisager une migration.

Migration complète de l’ancien système vers le nouveau.

Dans ce scenario, tout est basculé en une seule fois, l’ancien système étant fermé dès lors que le nouveau est en ligne. Ceci suppose que suffisamment de tests aient été menés pour valider tous les points du projet de migration, afin que la bascule s’effectue de la façon la moins impactante possible pour les utilisateurs.

Migration loties pendant laquelle des groupes d’utilisateurs partageant les mêmes contenus vont être migrés successivement

Dans ce scénario, une migration complète est appliquée à différents lots de l’environnement source. Par exemple des groupes qui sont basculés successivement, ce qui permet de minimiser les temps de migration, dès lors qu’un degré d’isolation a été défini pour les lots de données.

Migration incrémentale

Dans ce scénario, une première migration complète sera effectuée pour initialiser et valider l’environnement cible. Cependant, les utilisateurs continuent à travailler sur l’environnement source. A jalons réguliers, une migration incrémentale a lieu pour conserver le niveau de contenu sur la cible. Une fois la cible validée et les utilisateurs formés, une dernière migration incrémentale permet de basculer définitivement. Il n’y a pas de bonne ou de mauvaise façon de faire, chaque projet est différent et le choix du type de migration doit être fait en fonction des différents métriques (volume de données, complexité de la migration, degré de formation des utilisateurs, etc.).

Quel temps d’indisponibilité de la plateforme est acceptable ?

C’est encore une fois une question simple mais qui va impacter la stratégie de migration : quelle est la durée d’indisponibilité acceptable pour les plateformes cible et source ? Et au-delà de l’indisponibilité pure, il faut aussi tenir compte des possibilités de dégradation des performances, de verrous sur les bases de données, etc.

Quels sont les besoins en ressources humaines et matérielles ?

Généralement, la ferme SharePoint et son infrastructure sont correctement dimensionnées. C’est plus souvent au niveau de l’architecture de la ferme que des points sont à revoir, mais nous ne sommes plus alors dans le périmètre de la migration. Le deuxième point de dimensionnement à prendre en compte est celui en ressources humaines : les équipes qui seront responsables des étapes du projet de migration sontelles suffisantes et suffisamment pourvues, ou faut-il prévoir une équipe dédiée ? Eventuellement des formations dédiées au projet ? Le temps dédié à la validation d’une migration peut être conséquent, d’autant plus si des erreurs ou des manques sont détectés. Cas concret que j’ai pu rencontrer dans le cadre d’une migration depuis SharePoint 2003 vers 2010, quelques centaines de milliers de documents pour lesquels deux colonnes de métadonnées, assez critiques, sont restées vides. Il était très complexe de scripter le remplissage de ces colonnes et trois personnes ont été assignées à cette tâche manuelle compte tenu du planning.