Que ce soit pour passer d’un système propriétaire à un système ouvert ou pour modifier la stratégie d’entreprise, les évolutions du système informatique nécessitent parfois de changer de base de données. Ainsi, le groupement d’intérêt économique (GIE) Agora, lors du passage de GCOS 8 en environnement propriétaire Bull à des systèmes ouverts Unix, a dû migrer de la base navigationnelle IDS2, vers le SGBD relationnel Informix. Ce GIE est chargé du développement et de la maintenance du système informatique unique des quatre-vingt-une mutualités sociales agricoles. “Nous avons choisi le mode relationnel parce que, tôt ou tard, il aurait fallu aller vers cette technologie. Nous voulions faire une migration par portage isofonctionnel. Un moyen de faire des économies en ayant un minimum de choses à réécrire “, explique Jacques Byé, directeur des développements et des études techniques au GIE Agora.
Une méthodologie de migration également choisie par Bayard Presse, lors du passage de SQL Server 6. 5 vers Oracle 8i. Au total, 120 Go sont répartis sur trois bases. “Nous aurions pu profiter de la migration pour réunir ces trois bases en une seule. Mais l’opération était trop complexe. Sans compter un budget supérieur, il y avait un risque de perturber l’exploitation “, raconte Antoine Corman, directeur informatique de Bayard Presse. Seul Nordson, leader mondial des équipements de collage (85 personnes et 200 millions de francs – 30,49 millions d’euros – de chiffre d’affaires pour la filiale française), parti également sur un portage à 100 % des fonctions, change de stratégie en cours de route. “Nous devions faire migrer les 400 Mo d’une base de données Paradox vers Access 97. Une opération simple qui aurait dû se dérouler sans difficulté. Cette base recueillait les informations de suivi des machines installées chez nos clients. Ce n’était pas une base stratégique pour notre entreprise “, précise Pascal Fonteneau, directeur administratif et financier de Nordson.
Nettoyer la base sans la modifier
Le cahier des charges spécifiait une migration isofonctionnelle. Mais l’entreprise décide d’en profiter pour interfacer la base avec la nouvelle application SAP, et d’éliminer les requêtes désormais inutiles. Hélas, le prestataire évalue mal la charge de travail supplémentaire induite par ces améliorations. “Il a perdu du temps à développer les nouveautés au détriment de la migration des données “, explique Pascal Fonteneau. S’il vaut mieux éviter d’ajouter de nouvelles fonctions, telles que de nouveaux champs d’indexation, rien n’empêche cependant d’en optimiser certaines. Ainsi, au GIE Agora, aucune requête d’accès n’a été modifiée manuellement, et des fonctions d’ISD2 qui n’avaient pas lieu d’être dans le SGBDR ont été supprimées. “Certes, nous n’utilisons pas tous les avantages de notre base de données, mais au moins, ça fonctionne “, constate Jacques Byé. “Toute modification qui n’influe pas sur les opérations ultérieures ne pose pas de problème, estime, quant à lui, Pascal Fonteneau, ainsi, l’amélioration des interfaces doit pouvoir se faire sans soucis.”
Migrer du navigationnel au relationnel
Lorsque l’on passe d’une base navigationnelle à une base relationnelle, les opérations de migration sont parfois complexes. “Le problème principal était de porter les modules d’accès d’une base à l’autre, explique Jacques Byé, nous avons défini des règles génériques du type : telle structure IDS2 correspond à telle structure Informix, pour retrouver 100 % des fonctions.” Autre difficulté : définir les index en nombre et qualité et établir des règles automatiques de migration de DML (langage IDS2) vers SQL. Cette tâche aura duré un mois.
Une fois cette étape terminée, vient la phase de tests. Essentielle, elle permet de vérifier que toutes les fonctions sont bien récupérées dans la nouvelle base, mais aussi que les temps d’accès sont au moins équivalents à l’ancien système. “Pendant dix mois, nous avons testé un prototype avec 5 % des logiciels et 35 % des données migrées “, illustre Jacques Byé. Chez Bayard Presse, le calendrier prévu pour la migration a été dépassé d’une vingtaine de jours. En effet, les temps de rapports sur les tests ont été sous-estimés. “La période des tests est une période très délicate, remarque Antoine Corman, il faut, en effet, pouvoir tester tous les scripts et toutes les requêtes possibles. Dans notre cas, nous en avons 100.” La phase de tests à permis de détecter et de corriger des anomalies sur des requêtes développées au fur et à mesure. Au GIE Agora, les tests ont permis d’affiner certaines règles de migration. Si de manière générale, les requêtes générées SQL n’ont pas été modifiées, quelques interventions ponctuelles et manuelles ont été nécessaires pour retrouver les mêmes performances. Nordson a choisi de ne pas mettre en place une longue phase pilote : “Cette opération de migration simple ne nécessitait pas six mois de tests !, s’exclame Pascal Fonteneau. Mais une fois la migration complète effectuée, nous nous sommes rendus compte que 0,3 % des données étaient mal passées. Par exemple, des données interfacées avec l’ancienne application Nixdorf avaient un code client qui ne correspondait plus à rien dans notre nouvelle application SAP. Il y avait également des contrôles plus verrouillés dans Access que dans Paradox, et certains éléments étaient rejetés.” Une expérience riche d’enseignements, qui confirme le ca- ractère délicat des opérations de migration.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
