Vous changez d’ERP, vous faites évoluer votre modèle de données, vous passez sur le cloud, …Quelles que soient les circonstances, vous aurez besoin de vérifier et valider la migration des données.
Vérifier et valider la migration des données est une étape critique dans tout projet. Il est nécessaire de s’assurer que l’ensemble des données a été migré correctement et précisément depuis les systèmes sources vers les systèmes cibles.
1 étape prérequis et 3 étapes communes à tous les types de migration :
Prérequis – Audit de la qualité des données existantes
1-Extraction des systèmes sources
2-Transformation des données
3-Injection/intégration dans les systèmes cibles
Pour chacune de ces étapes, quelle que soit la stratégie de migration des données, Big Bang[1]ou Trickle[2], les étapes de tests sont indispensables ; c’est le séquencement et/ou la répétition de ces étapes de tests qui s’adaptent au contexte et à la complexité de la migration.
Cette activité n’est pas précisément une activité de data-migration mais elle est indispensable au bon déroulement de celle-ci. Il n’est pas pertinent de migrer des données de mauvaise qualité.
Pour chaque type de donnée à migrer, il est indispensable de vérifier que le système source contient des données de bonne qualité ; par exemple qu’il n’y a pas un genre dans un numéro de téléphone (oui, j’en ai eu l’expérience), que les dates sont cohérentes (une date de naissance dans le futur !!), et tout ce que vous pouvez imaginer.
De plus, généralement, cette étape permet de déterminer avec précision le périmètre des données à migrer ainsi que le volume prévisionnel de ces données.
Il est préférable de faire cet audit sur l’ensemble des données à migrer même si la migration est lotie, cela évite d’avoir des surprises avec des données spécifiques non prises en compte dans la transformation et qui génère un besoin de test de régression sur les lots précédents.*
Une vérification quantitative
Le périmètre de l’extraction doit être défini et clair afin de dénombrer précisément chaque type de donnée et de décrire les liens entre les types de donnée :
La quantité de référence et la quantité à migrer peuvent être différentes mais les différences doivent être explicables et expliquées. La quantité à migrer sert de base pour les vérifications quantitatives après la transformation et post injection.
Dans le cas d’une migration partielle (historique restreint ou sources concurrentes), il est très important de définir le périmètre de(s) extraction(s) ; i.e les données extraites doivent être cohérentes en termes de profondeur d’historique, de lien entre les types de données. Sans cette cohérence, les données migrées ne seront pas utilisables dans le système cible.
Une vérification qualitative
Sur un échantillon représentatif des données, il faut vérifier unitairement que les données sont identiques (si possible) dans la source et dans l’extraction. Attention, des mapping complexes dès la phase d’extraction risquent de rendre difficile ces vérifications, il est préférable de dissocier extraction et transformation.
Les outils sont très utiles dans cette étape (notepad++, sql, python, …) et l’industrialisation voire l’automatisation de ces étapes peut être envisagée dans le cas d’une migration par lot. En effet, si on prend l’exemple d’un déploiement à l’international, les gestes et procédures sont à réitérer pour chaque pays, une automatisation ou l’utilisation du RPA permet d’optimiser l’effort et de sécuriser cette étape.
Une vérification quantitative
Les règles de gestion de la transformation ou mapping doivent être définies et claires afin de vérifier qu’aucune donnée n’est perdue ou corrompue.
La quantité à migrer (issue de la phase d’extraction) est vérifiée par type de donnée quand la notion d’enregistrement n’est pas pertinente ; en effet, dans le cas par exemple d’une migration entre ERP, les informations sont diffuses dans le modèle de donnée, il faudra donc vérifier que les quantités sont cohérentes pour chaque type de donnée et que les liens entre les types de donnée sont conservés post-transformation.
Une vérification qualitative
Sur un échantillon représentatif des données, il faut vérifier unitairement que les données sont conformes aux règles de gestion de la transformation (mapping).
Les vérifications de la transformation sont à réitérer à chaque modification du process de transformation et dans le cas de données spécifiques à un lot.
Pour que les tests de la transformation se déroulent de façon optimisée, la phase d’audit de la qualité de la donnée est primordiale et permet d’éviter au maximum des tests de régression à répétition.
Une bonne pratique pour cette phase est d’utiliser les outils standard du système cible ; en effet, le modèle de données peut être très complexe et la vérification unitaire quasi impossible, en tout cas très chronophage.
Par expérience, sur SAP, il est plus que conseillé d’utiliser les outils d’injection standard SAP (BAPI) qui permettent de s’affranchir de la vérification des liens entre type de données.
Une vérification quantitative
La quantité à migrer (issue de la phase d’extraction) amendée par la transformation sera vérifiée par type de donnée dénombrable (ex : nb de commandes, nb de téléphones, …) ou par enregistrement dans une table si cela est pertinent.
Par exemple dans le cas d’une migration de données client, le nombre total de commandes client migrées est probablement accessible simplement, a contrario déterminer le nombre de commandes par client demandera une requête un peu plus complexe mais nécessaire.
Une validation qualitative
Notez le changement de vocabulaire, c’est une validation qualitative car c’est une étape où les utilisateurs finaux interviennent et donnent ainsi leur validation. Cette étape se déroule généralement sur un environnement de préprod ou seuls les utilisateurs finaux sont habilités pour respecter la conformité RGPD.
De même que précédemment, il faut vérifier unitairement que les données migrées sont comparables aux données des systèmes sources et complètes pour une utilisation dans le système cible ; en effet, des données migrées incomplètes ne pourront être utilisées dans le système cible.
Pour cela, il est indispensable de prévoir d’utiliser des données migrées comme jeu de donnée en entrée dans les tests fonctionnels bout en bout du système cible. Lors de phase d’UAT, les utilisateurs finaux pourront utiliser leurs données réelles migrées pour tester les process métier bout en bout et valider dans son ensemble la datamigration.
De mon expérience hétéroclite en termes de migration (Cf. Références) les principaux facteurs de succès sont :
A l’ère de l’IA générative, on peut se demander si toute cette démarche pourrait être prise en charge par des robots. Qu’en pensez-vous ?
[1] Transfert complet sur une durée courte : les 2 systèmes source et cible sont arrêtés le temps du transfert
[2] Transfert goutte à goutte : les 2 systèmes source et cible sont opérationnels en même temps, les données sont migrées en continu.
Références :
Auteur : Nathalie Turquet
Leader Test.IT
