Migrer une base HFSQL vers SQL Server

SQL Server est la cible naturelle des entreprises déjà équipées Microsoft : licences souvent en place, compétences d'administration présentes, intégration native avec l'écosystème Windows et .NET. Cette page décrit le chemin depuis HFSQL, avec un accent sur le cas fréquent des bases décentralisées à centraliser.

Le cas typique : parc Microsoft existant

Quand une DSI opère déjà des instances SQL Server pour d'autres applications, y rapatrier les données HFSQL réduit le nombre de technologies à maintenir : mêmes sauvegardes, même supervision, mêmes compétences. C'est aussi la trajectoire cohérente avec une cible applicative .NET, l'ensemble restant dans un écosystème unique et bien documenté. Si aucun existant Microsoft ne préexiste, comparez avec PostgreSQL : à fonctionnalités comparables pour une application de gestion, la question des licences peut faire pencher la balance.

Conception du schéma cible

Le schéma SQL Server se conçoit, il ne se photocopie pas depuis l'analyse HFSQL. Les règles : typage strict (dates en date/datetime2, montants en decimal, plus de numériques stockés en texte), clés primaires et étrangères déclarées partout, conventions de nommage lisibles, et contraintes d'unicité posées dans la base. Vingt ans de souplesse HFSQL se corrigent à cette étape ; les écarts détectés deviennent la liste de nettoyage des données.

Scripts de migration et rejeu

La migration s'outille avec des scripts versionnés et rejouables : extraction depuis HFSQL, transformations documentées dans un dictionnaire de mapping, chargement en masse côté SQL Server (bcp, BULK INSERT ou SSIS selon les habitudes de l'équipe), journalisation des rejets. L'objectif est qu'une bascule complète se rejoue à l'identique, à blanc, autant de fois que nécessaire : la migration réelle n'est alors que le dernier rejeu.

Adaptation du code applicatif

Deux situations. Si l'application WinDev reste en service pendant la transition, elle peut pointer vers SQL Server via les connecteurs, à condition de reprendre les traitements qui exploitaient des particularités HFSQL : parcours ligne à ligne, recherches implicites, requêtes non standards. Si la migration de base accompagne une réécriture applicative, le nouveau code (généralement C#/.NET avec Entity Framework) naît directement sur le schéma cible, ce qui est plus simple. Dans les deux cas, l'inventaire des requêtes dépendantes de HFSQL, mesuré pendant l'audit, dimensionne l'effort réel.

Centraliser des bases décentralisées

Beaucoup de parcs HFSQL vivent éclatés : une base par site, par agence ou par client. La centralisation vers SQL Server est l'occasion de consolider, à condition de traiter deux sujets. L'identité des données : les identifiants locaux entrent en collision à la fusion, il faut des clés globales et des règles de dédoublonnage des référentiels. Le rythme : on centralise par vagues, site par site, chaque vague étant rejouable et réversible, jamais en une bascule unique de tout le parc.

Erreurs fréquentes sur une migration vers SQL Server

• Sous-estimer le travail de dédoublonnage des référentiels lors d'une centralisation de bases décentralisées : deux clients ou deux articles créés sous le même libellé dans deux agences différentes ne sont pas automatiquement la même entité.
• Basculer tout le parc en une seule opération plutôt que par vagues : une centralisation en un bloc multiplie le risque et rend le retour arrière quasiment impossible en cas d'incident.
• Conserver des types texte pour des montants ou des dates par simple prudence : cela reporte le nettoyage au lieu de le faire, et prive la nouvelle base de la rigueur qu'on est venu chercher.
• Oublier de tester les traitements applicatifs critiques sur la nouvelle base avant d'éteindre l'ancienne : la recette technique des données ne remplace pas la recette fonctionnelle des traitements qui s'appuient dessus.

La plupart de ces erreurs se révèlent tardivement si elles ne sont pas anticipées, souvent au moment où l'ancienne base est déjà éteinte. C'est ce qui justifie une phase de recette exigeante avant toute décision d'extinction définitive du système source.

Recette de non-régression

• Comparaison automatisée des comptages et agrégats entre chaque base source et la cible consolidée.
• Contrôles métier sur les documents sensibles : totaux de facturation, stocks, soldes clients.
• Tests des traitements applicatifs critiques sur la nouvelle base avant toute extinction de l'ancienne.
• Conservation des bases sources en lecture seule le temps de la période de garantie.