6 étapes pour bien se préparer à une migration de données

6 étapes pour bien se préparer à une migration de données

08 Oct 2015 |  AMOA

Réussir une migration lors du passage d’une application à une autre est une étape importante et c’est souvent une source de stress. Est-ce que les données seront bien importées ? Est-ce que l’on ne va pas en perdre en route ? Est-ce que la migration marchera avant de passer le site en live ? Pourtant, lorsqu’une migration est bien préparée il n’y que très peu de raison de s’inquiéter. Pour cela, il faut passer du temps d’analyse avant de demander à l’équipe de développement de procéder à la migration des données. La rédaction d’un document de spécification permet de simplifier la compréhension de ce qui doit-être fait et permet de vérifier ce qui a été fait à la fin.

Plusieurs fois, j’ai eu la chance d’aider des entreprises à migrer leurs données d’un ancien site vers leur nouveau projet. Dans ce post, je vous livre quelques étapes que j’applique lors de la planification d’une migration.

Types de migrations

Il existe deux types d’imports de données, les migrations d’initialisation, celles que vous allez jouer une seule fois afin de remplir le site de données et les imports continus de façon à synchroniser votre application avec l’écosystème dans lequel elle se trouve. Chaque type de migration a ses zones de complexité, néanmoins rien d’insurmontable.

Avec les migrations « one shot » il faut souvent faire face à de gros jeux de données et des dépendances entre les imports de données. Il est donc important d’optimiser le code de façon à ne pas impacter ni les performances du site, ni a avoir un import qui dure des heures (ou des jours).

Les migrations quotidiennes imposent plus de réflexion car il ne s’agit bien souvent que d’ajouter et ou de modifier quelques informations. Tachez donc à bien penser l’écrasement des données de la base avec les nouvelles. Les migrations quotidiennes sont par expérience plus critiques pour l’application et doivent être bien contrôlées lors de la sauvegarde. C’est par exemple le cas lorsque vous importez les prix de vos produits chaque jour, il est nécessaire de vérifier que l’information à sauvegarder pour un produit soit bien positive, ou non nulle et qu’elle n’a pas varié d’un pourcentage donné.

Quel que soit le type de migration que vous devez faire, n’oubliez pas qu’une migration c’est le moment idéal pour transformer et nettoyer les données. Une fois injectées dans le nouveau système il sera plus complexe de les retravailler.

Action #1 : déterminez s’il s’agit d’un import quotidien ou d’un import d’initialisation.

Formats d’échanges et conventions de nommages

Il existe tout un tas de façon pour transférer de données, néanmoins le plus simple reste de générer des fichiers. La lecture directe en base de données ou la consommation d’une API requièrent plus de développement et de temps de traitement car il faut à la fois récupérer les données et les analyser. De plus les API sont limitées en nombre de requêtes ou/et limitées en nombre de résultats par requête pour des raisons d’impact sur les performances des serveurs. La mise à disposition d’une API dans le système d’information doit être mûrement réfléchi ! L’utilisation de fichiers a un côté « old school » lorsque je l’évoque pendant des ateliers de conception, pourtant c’est la façon la plus simple et sécurisante pour exporter des données.

Trois formats sont souvent utilisés, le CSV, le XML et le Json. * Le CSV est simple d’utilisation car les données sont à plat. Une ligne du fichier correspond à une entité dans votre système comme par exemple un produit, un utilisateur ou une commande. La taille d’un fichier CSV est faible et c’est rapide à analyser. Néanmoins ce format a ses limites quand l’import contient des références entre les entités ou des champs spéciaux. * XML est quant à lui très verbeux mais il est possible de réaliser des imports très complexes. Il devient possible de migrer dans un seul fichier des informations et leurs dépendances. Ainsi vous pouvez exporter une commande, le client de cette commande et toutes les lignes de commandes sans problème. * L’alternative aux deux précédentes solutions est le format Json. Il permet de réaliser des choses complexes sans pour autant augmenter drastiquement la taille générée par les fichiers d’exports. Le format Json est compris nativement par beaucoup de langages et est simple à lire, ce qui fait que n’importe quel développeur peut l’analyser.

Pour chaque migration vous devez déterminer le nom des fichiers qui seront utilisés ou les urls qui permettront de récupérer les données. Je vous conseille d’ajouter la date et l’heure dans le nom de vos fichiers. De cette façon, il vous sera plus facile de les archiver par la suite et vous éviterez de les écraser.

Action #2 : Définissez la manière dont vous allez fournir les données, les formats d’échanges et les noms des flux et fichiers.

Sources et Destinations

Toute la complexité de la préparation d’une migration réside dans l’analyse de la source (là ou sont les données) et de la destination (là ou il faut sauvegarder les données). En effet il est important de lister toutes les informations à disposition et de répertorier celles qui sont importantes.

La source de votre import c’est le système dans lequel sont stockées vos données, il faut donc parcourir et comprendre le modèle de données pour trouver où sont stockées les informations. Si les échanges entre l’ancien système et le nouveau seront fait à l’aide de fichier, je vous conseille de mettre le maximum de données dans les flux de sorties. Même si elles ne sont pas toutes utiles, il vaut mieux anticiper que devoir modifier les scripts d’exports quelques semaines ou mois après.

A ce stade vous devez ouvrir votre base de données, faire un état des lieux du modèle (nombre de tables et d’objets par table, lien entre les tables, chercher les éventuelles données mal formatées dont il va falloir améliorer la qualité, nettoyer…). Une fois terminé vous aurez une idée de l’ampleur du travail en terme de volume et de complexité.

La base de destination, est plus flexible parce que bien souvent en parce en cours de développement. Néanmoins il faut éviter de modifier le système de destination en accord avec les flux de migration, à la place, il est préférable de modifier les données pendant l’import. N’hésitez pas à combiner plusieurs données lors de l’import. A l’inverse de la réalisation des flux de sortie de données, évitez d’importer des données inutiles dans votre site.

Pour procéder à une préparation de migration j’utilise un document type tableur, Excel ou Gdoc font très bien l’affaire. Je créé un onglet par migration et je liste tous les informations source et destination. Une fois terminé il ne me reste plus qu’à relier les données que je veux migrer vers la où je veux les stocker.

Action #3 : Listez les données sources et les champs de destination pour stocker les données. Réalisez le tableau de mapping source et données.

L’import

Une fois que vous avez déterminé ce que vous voulez importer, que vous savez comment exporter les données et que vous avez défini où stocker les informations, vous avez fait le plus gros du travail.

Dans le cas d’une migration de données régulière vous devez déterminer la fréquence de l’import et l’heure d’exécution. Tous les jours ? Une fois par semaine ? A midi ou à minuit ? Pour ce faire, analysez les statistiques d’utilisation de votre site afin de déterminer la période où le trafic utilisateur est le moins important.

Si vous devez réaliser un import d’initialisation, l’heure ou le jour n’est pas vraiment un problème. Néanmoins, vous devez quand même prévoir un plan d’import lorsque vous allez faire la bascule entre les deux sites. Bien souvent on coupe le site A, on bascule sur le site B avec l’affichage d’une page de maintenance. On réalise la migration, on attend, on teste le site et on ouvre l’accès au public doucement (évitez le fiasco de voir votre site HS 5 minutes après l’ouverture parce que la campagne marketing a été bien faite. Rappelez vous de France.fr). Bon ok, c’est le scénario idéal qui fonctionne lorsque vous n’avez pas beaucoup de données à importer. Dans le cas où vous avez des millions d’informations à transférer il vous faut une stratégie plus robuste et qui ne vous coûtera pas des heures de site hors-ligne. Pour ce faire, l’import doit être fait en deux temps, le premier import quelques jours avant la mise en ligne de votre site afin d’importer 99% des données et le deuxième pendant la bascule entre les deux sites. De cette façon vous avez réduit au minimum le temps de d’indisponibilité de votre service.

Action #4 : Réfléchissez à votre import, sa fréquence, l’heure d’exécution, la mise en place d’alertes et la gestion d’archives

Gestion des erreurs

Dans l’informatique en général il est impossible de prévoir tous les cas d’échec d’une application. On a donc pris l’habitude de faire des tests de montée en charge, des tests de performance, on imaginer des scénarios et on crée du code pour anticiper les aléas.

Les migrations n’échappent pas à cette règle. Il est compliqué de tout prévoir car bien souvent un très faible pourcentage de données dans la base représente un problème et l’on ne s’en aperçoit pas toujours pendant la phase de développement. Au lieu de perdre du temps à tester, je suis convaincu qu’il est préférable de concevoir une application résistante aux erreurs et qui est capable de fonctionner même en mode dégradé. Il s’agit du « Design for failure ». L’idée est d’attraper les erreurs, de les analyser et d’apporter des correctifs a posteriori.

Dans votre préparation de migration, vous devez vous interroger sur la gestion des erreurs. Qu’est-ce que doit faire l’application en cas d’erreur lors de l’import : * Est-ce que la source de données doit-être repassée ? * Faut-il envoyer un email en cas d’erreur ? A qui ? quelles infos ? * Faut-il permettre de repasser la source de données à la main ? * Est-ce qu’un rapport de migration doit être envoyé à la fin d’un import ?

Action #5 : Réfléchissez à la gestion des erreurs et les mesure à prendre si quelque chose se passe mal. Définissez les informations qui doivent être remontées après chaque migration.

L’équipe

Pas de surprise pour ce dernier point, la réussite de votre projet (et de tout projet en général) passe par une bonne communication et une implication des personnes concernées. N’espérez pas que des personnes travaillent main dans la main si ce n’est pas naturel pour elles.

Identifiez les différents acteurs utiles à votre projet de façon à ce que les développeurs, les décideurs et les futurs utilisateurs puissent échanger sur leurs problématiques. Pensez donc à impliquer le service marketing, les services financiers, le service info et vos utilisateurs/modérateurs.

La constitution de groupe de travail avec beaucoup de personnes est souvent improductif, privilégiez donc des petits groupes de 7 ou 8 personnes maximum.

** Action #6 : Impliquez tous les acteurs utiles et concernés par les migrations des données.**

Réalisez votre analyse de migration

En résumé, voici les actions que vous devez entreprendre afin de réussir vos migrations :

  • Définissez le type d’échange que vous voulez mettre en place (Fichiers, API…)
  • Déterminez pour chaque migration le nom du fichier ou du flux de données
  • Définissez le format ou les normes que respecteront les données.
  • Indiquez la fréquence d’import de chaque migration
  • Listez les champs de source et de destination de vos systèmes
  • Réalisez le mapping des champs et les potentielles modifications à apporter aux données.
  • Imaginez les erreurs possibles et les solutions à mettre en place
  • Impliquez votre équipe technique, les utilisateurs (administrateurs) du site et pourquoi pas votre équipe marketing dans l’analyse et la préparation des migrations
Julien Dubreuil

Vous avez une idée, un projet web à réaliser ?

Ensemble, mettons en oeuvre sa réussite. Je vous accompagne dans vos projets, depuis l'élaboration du cahier des charges jusqu'à la mise en production. Pour plus d'information n'hésitez pas à me contacter.

Contactez-moi