Migrer de HFSQL vers PostgreSQL : ce qui coince vraiment

Changer de base de données paraît être le morceau le plus technique d’une modernisation. Dans les faits, la copie des données est la partie qui se passe le mieux. Ce qui coûte du temps, ce sont les hypothèses que l’ancienne application avait prises sans le dire.

Les rubriques qui n’ont jamais eu de type

Une rubrique texte qui contient tantôt une date, tantôt un commentaire, tantôt rien : c’est courant dans une application de vingt ans, et PostgreSQL le refuse. Il faut trancher, rubrique par rubrique, et écrire la règle de conversion. Cette liste se construit à l’audit, pas pendant la migration.

Les doublons que personne ne voyait

HFSQL tolère des clés que l’on croyait uniques. Au moment de poser la contrainte côté PostgreSQL, les doublons remontent — souvent quelques dizaines sur des centaines de milliers d’enregistrements. Ils doivent être arbitrés par quelqu’un qui connaît le métier, pas par un script.

Les traitements cachés dans les fenêtres

Un contrôle de cohérence écrit dans le code d’une fenêtre WinDev ne suit pas les données. Si la règle compte, elle doit être reposée : contrainte en base, ou traitement côté serveur. Sinon elle disparaît le jour où un autre écran écrit dans la même table.

Ce qu’on en retient

Le rapport d’écarts vaut plus que le script de migration. Tant que le nombre de lignes, les totaux par exercice et les cas limites ne correspondent pas des deux côtés, la migration n’est pas terminée — même si tout s’est copié sans erreur.