La migration nécessite des environnements stables

Pour mener à bien les opérations de migration, il est nécessaire de disposer de plusieurs environnements qui soient :

Stables, c’est-à-dire sur lesquels les données ne sont pas transformées et où les logiciels sont dans une version figée.
Dédiés aux opérations de migration.

Lorsque ces principes ne sont pas respectés, des difficultés sont rapidement rencontrées :

contrôles de masse et d’échantillon en anomalie, si les données sont modifiées ;
impossibilité d’utiliser les environnements pour tester toute la chaîne de migration.

Un environnement est composé :

de bases de données et fichiers ;
de tables de paramétrage ;
d’outils d’accès aux données (requêtage, vidage...) ;
des programmes transactionnels ;
des chaînes d’exploitation batch.

Chaque environnement doit pouvoir faire l’objet de sauvegardes et de restaurations (en distinguant applicatifs, paramétrage et données).

L’approche proposée ici fait état d’un certain nombre d’environnements.

Elle est fonction de l’expérience de migrations de Système d’Information de taille importante.

Cette approche devra être adaptée à chaque contexte, une migration...

Développement des programmes de migration

Dans la phase de développement de programmes, il faut pouvoir mettre à disposition tous les outils nécessaires au développement et aux tests unitaires.

Généralement, on utilise un environnement partagé avec d’autres équipes de développement car :

Les données utilisées sont des jeux de tests.
Les outils installés sur l’environnement servent au développement et à la mise au point de programmes.
Les tests unitaires des programmes de migration ne nécessitent pas d’utiliser les programmes transactionnels et batch de la nouvelle plate-forme.

Les points majeurs pour permettre la cohabitation sur cet environnement avec d’autres équipes sont :

La complétude des outils de tests

Comme pour tout développement, la qualité des tests unitaires garantit la performance des programmes.

Le développeur doit avoir à sa disposition :

des outils de debug pour lui permettre de trouver rapidement la solution aux problèmes rencontrés ;
l’ensemble des composants logiciels de la plate-forme entrant dans le périmètre de ses tests.

La complexité des Systèmes d’Information, répartis sur plusieurs machines, avec des logiciels disparates, augmente la difficulté de disposer d’environnement de tests complets.

La stabilisation...

Certification Statique

La Certification Statique doit permettre d’effectuer :

des contrôles d’échantillon, où l’on vérifie que, qualitativement, les données du système source ont bien été reprises dans le système cible ;
des contrôles de masse, où l’on s’assure que le nombre d’occurrences (ou de lignes) reprises dans le système cible est conforme au stock des données à reprendre (pas de perte d’informations lors de la migration).

Si les contrôles d’échantillon peuvent s’effectuer dans un premier temps sur des données de tests, en revanche les contrôles de masse, de par leur définition, obligent à disposer d’un environnement de données réelles à volume réel.

On peut également penser que les programmes (ou requêtes) de comptage se développent sur un environnement de test, mais la conformité du contrôle ne peut être vérifiée que sur le volume réel.

De plus, la préparation de l’environnement de certification et son chargement par la migration permet de mesurer :

la taille nécessaire pour stocker les données reprises ;
le temps de passage de la chaîne de migration, qui servira de référence pour le process de bascule.

Cette opération doit être...

Certification Dynamique

La Certification Dynamique doit également s’effectuer sur un environnement spécifique.

On rappelle que ce chantier doit permettre de faire fonctionner la plate-forme cible sur des données migrées.

Des scénarios de certification sont déroulés, simulant le fonctionnement du Système d’Information.

Les scénarios alternent des opérations effectuées en transactionnel avec des traitements batch.

Compte tenu de ces objectifs, l’environnement de Certification Dynamique doit ressembler au futur environnement de production.

C’est pourquoi il est courant d’utiliser l’environnement de production (quand cela est possible) pour la Certification Dynamique.

L’environnement est chargé des données reprises lors des Bascules à Blanc.

Les opérations de certification peuvent ainsi se dérouler entre deux Bascules à Blanc.

Il est également souvent nécessaire de mettre en œuvre d’autres environnements annexes, pour des applications périphériques à la plate-forme centrale (par exemple, dans les Systèmes d’Information bancaires, pour gérer les applicatifs crédits).

Bascule

La finalité de la Bascule est la mise en route de l’environnement de production.

Comme indiqué précédemment, cet environnement peut être utilisé lors des Bascules à Blanc, puis par la Certification Dynamique.

Lorsque la Bascule s’effectue en plusieurs étapes (Bascule incrémentale), il n’est plus possible d’utiliser l’environnement après la première Bascule.

Dans ce cas, un deuxième environnement doit être construit que l’on appelle environnement de préproduction.

D’autres environnements peuvent être nécessaires pour permettre le démarrage du nouveau système, en particulier l’environnement de formation.

Cet environnement doit être dédié, car la formation donne une image du système cible aux futurs utilisateurs.

D’autres opérations menées sur cet environnement pourraient entraîner une indisponibilité ou une dégradation du service, ce qui donnerait une image négative du futur système.

Charges de mise en place des environnements

L’étude des différents besoins en matière d’environnements montre qu’un nombre important d’environnements est nécessaire pour la bonne marche du projet.

La mise en place d’un environnement est consommatrice en charges :

pour la préparation des espaces physiques ;
pour l’installation des outils ;
pour l’initialisation des bases de données ;
pour la mise en place des processus de gestion de versions ;
pour l’organisation des sauvegardes.

Il faut donc prévoir une charge conséquente pour tous ces travaux, charge qui est rarement estimée à la bonne valeur en début de projet, car ces tâches interviennent plutôt en fin de process et ne sont pas bien identifiées en début de projet.

L’expérience montre que cette charge doit correspondre à 10 % de la charge MOE du projet Migration des données.

Elle est bien entendu à préciser quand le projet est plus avancé, mais c’est une prévision qui ne s’avère pas trop loin de la réalité.

Il faut également prévoir que ces environnements impliqueront des tâches de fonctionnement, confiées aux équipes exploitation.

De même que pour la mise en place des environnements, ces charges sont souvent sous-estimées.

Là...