Quelques principes avant de commencer

Analyse des données source/cible dans la phase de spécifications

Une des premières phases de la migration de données est la spécification des règles de migration. Lors de cette phase, on doit s’intéresser à la description des données source et à celle des données cible.

Question : Faut-il commencer par la cible ou par la source ?

Premier principe : il faut toujours partir du système cible pour ensuite s’intéresser au système source.

C’est-à-dire qu’il faut commencer par comprendre le fonctionnement du système cible et comment sont organisées les données, pour ensuite identifier dans la source les données qui permettront de les alimenter.

Ce point est primordial, car il ne faut pas oublier que l’objectif final est de faire fonctionner correctement le système cible. De ce fait, il faut vérifier que toutes les données cible sont bien alimentées, ou si elles ne le sont pas, que cela soit en connaissance de cause.

Cette approche est souvent difficile à mettre en œuvre, car lors de la construction d’un nouveau système, le modèle de données cible évolue et n’est stabilisé que peu de temps avant la bascule.

Il est courant de voir des projets de migration dont l’analyse débute par le système source, et où...

Lotissement du projet

Deuxième principe : un projet de migration doit être organisé par lots de migration. 

Il est recommandé de définir un premier lot sur un périmètre restreint. Ce lot va servir de lot pilote qui permet de dérouler tout le process de reprise des données en avance de phase par rapport au reste du périmètre.

On peut ainsi valider très rapidement la démarche et détecter des problèmes en fin de process, en Certification Statique par exemple, qui engendreraient des modifications de l’organisation et/ou de la démarche en amont. Mieux vaut s’en rendre compte au plus vite...

Pour effectuer le lotissement, il faut partir du modèle de données cible et définir des groupes de tables cohérentes entre elles d’un point de vue fonctionnel.

Si le lotissement est effectué à partir du modèle source, on risque de ne pas pouvoir dérouler tout le process de migration, jusqu’au chargement des données cible.

En effet, l’alimentation d’une table cible peut nécessiter des données de plusieurs tables source. De ce fait, cette table ne pourra être chargée et contrôlée que lorsque toutes les tables source contenant des données nécessaires à sa migration auront été étudiées....

Déchargement des données source et rechargement des données cible

Pour illustrer notre démarche, il faut décomposer le process de migration des données en suivant ce schéma :

Les données source sont déchargées dans des fichiers à plat. Ce sont ces fichiers qui sont en entrée de la migration.

Troisième principe : réaliser les programmes de migration sur des données déchargées du système source et non directement sur les données source.

De même, la migration génère les données cible dans des fichiers à plat qui sont ensuite chargés sur le système cible. Les programmes de reprise ne chargent pas directement les données dans les tables cible.

Quatrième principe : les programmes de migration génèrent les données cibles dans des fichiers à plat et non directement sur les données cible. Les fichiers à plat sont chargés ensuite dans les tables cible.

Cette approche permet :

Rejets ou anomalies

Lors de la formalisation de spécifications des règles, on est amené à effectuer des contrôles sur les données source qui vont permettre d’alimenter les données cible.

Ces contrôles peuvent faire l’objet de rejets ou d’anomalies.

Ces notions de rejets et d’anomalies sont à définir clairement.

Documentation projet

Le cinquième principe concerne la documentation projet.

Il est essentiel que soit organisé l’ensemble des informations utilisées dans le process de migration, à savoir :

L’expérience montre très souvent des données cible et source dont les formats de description sont différents. Certaines sont sous forme de fichiers Word et d’autres sous forme de fichier Excel.

Une bonne démarche consiste à centraliser toutes ces informations dans un même espace de stockage, de façon cohérente.

On verra par la suite que l’idéal est de disposer d’un outil (par exemple sous Access) permettant d’intégrer l’ensemble des informations recensées.

Avec un tel outil :