Aborder la migration de sa plateforme Sharepoint - Partie 3

Mise au point du support de migration

Le support de migration est réalisé pendant la phase de construction. Il s’agit de mettre au point le dispositif par lequel la migration est exécutée.
Il diffère en fonction de ce qui aura été planifié lors de la phase projet précédente. En fonction, le support de migration peut être un outil tiers, un automate de migration basé sur des scripts, ou encore une procédure manuelle listant les étapes à réaliser.

Industrialisation de la migration. De manière générale, il est fortement conseiller d’industrialiser au maximum le processus de migration. L’automate s’inscrit tout à fait dans cette optique car il est basé sur des scripts, mais ce n’est pas le cas de la procédure manuelle. En ce qui concerne l’outil tiers, ce dernier permet de configurer des tâches qui peuvent être séquencées puis exécutées, et propose également pour certains un export scripté pour une réelle automatisation.

L’industrialisation consiste à élaborer un processus de migration fortement automatisé et répétable. Les principaux avantages sont :

  • Une fiabilité accrue car le risque d’erreur humaine est limité
  • Une efficacité améliorée du fait de la rapidité d’exécution des scripts
  • Une contextualisation du processus aux différents environnements (Qualité, Pré-Production, Production), via notamment l’utilisation de fichier de configuration
  • La possibilité d’intégrer le processus au sein d’une intégration continue

La mise au point du support de migration est un processus itératif. Les activités de migration qui ont été planifiées de manière plus ou moins granulaire, sont réalisées et assemblées au sein du dispositif de migration. Par exemple, dans le cas d’un automate de migration, on pourrait imaginer un script principal, qui viendrait ordonnancer un certain nombre de sous scripts respectivement responsables de la migration d’espaces SharePoint définis.

Ainsi, il est possible d’exécuter les actions de migration unitairement sur des environnements de développement qui peuvent être restaurés à la demande. Le dispositif de migration global s’amorce donc itérations après itérations. 

Par ailleurs, des migrations dites à blanc doivent être prévues et jalonnent cette phase de réalisation. De cette manière, on tend à anticiper les écueils techniques potentiels et cela permet aussi d’effectuer des tests applicatifs sur des environnements dédiés. Les migrations à blanc permettent également de donner un aperçu du résultat final de la migration en production, en termes de prérequis de sécurité, de charge impactant les serveurs et de durée d’exécution.

Approches technologiques liées à la migration SharePoint. Il y a communément deux orientations technologiques possible pour la mise à niveau d’une plateforme SharePoint :
La première est la méthode standard, communément appelée « Database Attach Upgrade », et documentée par Microsoft. La seconde est l’utilisation d’un outil tiers, parmi lesquels on peut citer Metalogix Content Matrix, ShareGate, Quest Migration Suite for SharePoint ou AvePoint DocAve Migrator. Voici quelques éléments qui détaillent chacune de ces deux approches :

  • La migration dite standard appelée « Database Attach Upgrade », constitue une approche résolument orientée produit. Elle implique qu’une plateforme cible soit installée. Puis les bases de données des applications de services ainsi que les bases de données de contenu sont copiées vers la ferme cible, montées dans SharePoint, et mises à niveau avec les commandes Microsoft. L’ensemble des opérations peut être automatisé par le biais de scripts.
  • La migration via outil tiers est une approche orientée contenu. Elle suppose que la plateforme cible soit installée et préconfigurée avec les services SharePoint nécessaires. Cette approche se permet de jouer avec les contenus (sites SharePoint, listes, documents, permissions, …) qui sont accessibles via les interfaces à disposition sur la plateforme source et qui peuvent être copiés sur la plateforme cible via les interfaces à disposition sur cette dernière.

Ces deux approches peuvent bien évidemment être mixées. Ces choix devront être décidés pendant la phase de planification, en accord avec une stratégie claire.

Ci-dessous un comparatif général de chacune de ces approches :

Capacité

Database-Attach Upgrade

Outil tiers de migration

Plateforme

Migration non limitée en fonction de la version de la plateforme source et de la plateforme cible (ex : migration de SharePoint 2010 vers SharePoint 2016)

 

 

 

X

Migration depuis une plateforme On-premises vers SharePoint Online

 

X

Migration sans coût de licence additionnels

X

 

Continuité de service

 

X

Contenus

Migration granulaire / Sélection des contenus migrés

 

X

Réorganisation / Normalisation des contenus migrés

 

X

Migration des instances de Workflows en cours d’exécution

X

 

Migration incrémentielle

 

X

Migration avec conservation de l’ensemble des configurations et personnalisations

X

 

 

Migrer

La phase d’exécution de la migration n’est finalement qu’une nième répétition d’une migration à blanc, mais cette fois sur l’environnement de production. Les précédentes migrations sur des environnements de tests auront normalement mis en évidence et permis d’anticiper tous les points bloquants.

Le support de migration peut être techniquement au point, cela n’est néanmoins pas suffisant pour lancer la mise à niveau de la plateforme. Il doit en parallèle être formalisé un plan de bascule, dont l’objectif est de séquencer l’ensemble des actions qui encadrent la migration ainsi que les acteurs responsables de leur exécution.
On retrouve généralement parmi ces actions :

  • La mise en place de prérequis techniques (bases de données en lecture seule, désactivation de l’envoi d’email, etc.)
  • Diverses communications
  • L’exécution du support de migration
  • La vérification des logs de migration
  • Les Sanity checks post migration sur l’environnement cible
  • Les tests fonctionnels le cas échéants
  • Le Sign Off de migration par les responsables métiers et/ou acteurs identifiés
  • Les redirections DNS
  • L’exécution de plan de retour en arrière (« Roll Back ») en cas d’erreur bloquante de migration ou de résultats de tests fonctionnels infructueux

En synthèse

La mise à niveau d’une plateforme SharePoint est bien plus qu’une simple opération de maintenance technique. Il s’agit au contraire d’un réel projet avec des contraintes, des objectifs, des moyens.
Un tel projet nécessite une réelle planification au sens stratégique avec des prises de décisions techniques et opérationnelles qui conditionnent le succès de la migration. Cette stratégie repose par ailleurs sur bonne connaissance de l’existant et sur une expertise SharePoint forte. La conduite d’une analyse complète de la plateforme source s’avère un prérequis à toute stratégie.

Pour finir, la migration est finalement une formidable opportunité pour imposer des standards d’entreprises, pour renforcer l’application d’une gouvernance, ou pour repenser une architecture en place.

Didier CACCIOLA – .Net/SharePoint Specialist – SQLI Suisse.

Didier Cacciola

Spécialiste Net/SharePoint Specialist – SQLI Suisse

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !