Une migration de base de données semble parfois être une étape technique derrière une refonte : exporter, transformer, importer, vérifier. Dans une application métier, c’est rarement aussi simple. La base contient l’histoire des décisions, les preuves d’exécution, les exceptions, les rattachements, les droits, les exports et les erreurs anciennes que le nouveau système devra assumer.
Le risque n’est pas seulement de perdre une ligne. Le risque est de changer le sens d’une donnée, de casser une relation, de rendre un historique moins lisible, de créer des doublons, d’altérer un calcul ou de rendre impossible l’explication d’un dossier après la bascule.
Cet article détaille les risques souvent sous-estimés dans une migration BDD avant refonte. Ces risques deviennent critiques dans une migration application legacy vers Symfony, surtout quand un audit technique application web révèle des données mal comprises ou mal historisées.
Le but n’est pas de dramatiser la migration. Le but est de la traiter comme un chantier de développement web sur mesure à part entière, avec des responsabilités métier, des preuves et un plan de reprise.
Pourquoi la migration BDD porte le risque métier
Une base de données applicative n’est pas un simple stockage. Elle encode souvent des règles implicites : statuts, dates, priorités, relations, exceptions, historiques et drapeaux qui déclenchent des traitements. Quand ces règles ne sont pas documentées, la migration peut les modifier sans que personne ne s’en aperçoive immédiatement.
Le risque apparaît plus tard, au moment où un utilisateur cherche un dossier, où un client conteste une information, où un reporting change ou où une intégration consomme une donnée dans un format légèrement différent. La migration a alors l’air terminée, mais la confiance dans la donnée est déjà fragilisée.
La donnée migrée devient une promesse
Quand une donnée entre dans le nouveau système, l’entreprise promet implicitement qu’elle est fiable, exploitable et défendable. Cette promesse doit être proportionnée : certaines données doivent être parfaites, d’autres seulement consultables, d’autres archivées avec une mention claire de leur origine.
La migration doit donc hiérarchiser les enjeux. Une adresse de livraison active, un statut de facture ou un droit utilisateur n’a pas le même niveau d’exigence qu’une note ancienne consultée une fois par an.
Inventorier la donnée avant les scripts
L’erreur classique consiste à commencer par les scripts de transformation. Avant d’écrire une ligne, il faut savoir quelles tables comptent vraiment, quelles colonnes portent du sens, quelles données sont obsolètes, quelles exceptions sont connues et quelles zones ne doivent pas être migrées telles quelles.
Cet inventaire doit associer technique et métier. Les développeurs voient les relations, formats et contraintes. Les utilisateurs savent quelles données servent à décider, lesquelles sont historiques et lesquelles sont devenues inutiles mais restent dans la base par habitude.
Identifier les données actives, historiques et parasites
Les données actives alimentent encore le run. Les historiques doivent rester consultables et opposables. Les données parasites viennent d’anciens tests, de doublons, de colonnes abandonnées ou de contournements. Migrer ces trois catégories de la même manière recrée la dette dans la cible.
La bonne migration documente ce qui est repris, transformé, archivé, purgé ou laissé en lecture seule. Cette décision évite de présenter un nouveau système propre qui contient déjà les ambiguïtés de l’ancien.
Identifiants, relations et correspondances
Les identifiants sont sous-estimés parce qu’ils semblent techniques. Pourtant, ils relient les dossiers, fichiers, logs, exports, intégrations, emails et références externes. Une mauvaise stratégie d’identifiants peut casser la traçabilité longtemps après la bascule.
Il faut décider si les identifiants historiques sont conservés, mappés, remplacés ou exposés différemment. Il faut aussi conserver une table de correspondance quand des systèmes tiers, des liens anciens ou des exports continuent à référencer l’ancien monde.
Les relations cassées coûtent plus cher que les colonnes manquantes
Une colonne oubliée se repère souvent assez vite. Une relation cassée peut produire des effets plus subtils : un document rattaché au mauvais dossier, un historique incomplet, une facture orpheline, une permission absente ou un reporting qui additionne les mauvais périmètres.
Les contrôles de migration doivent donc vérifier les volumes et les relations, pas seulement les valeurs. Nombre de dossiers avec documents, commandes avec lignes, clients avec adresses, actions avec auteur et statuts avec historique doivent être comparés avant validation.
Historique, audit trail et preuve métier
L’historique est rarement agréable à migrer. Il contient des formats anciens, des trous, des actions non structurées, des logs incomplets et des décisions qui ne suivent plus la nomenclature cible. Pourtant, c’est souvent lui qui permet de comprendre un dossier après incident ou contestation.
Il faut décider ce que l’historique doit prouver : qui a fait quoi, quand, depuis quel état, avec quel résultat et quelle pièce jointe éventuelle. Cette question est plus importante que la reproduction exacte de toutes les colonnes legacy.
Ne pas transformer l’historique en donnée active
Tout historique n’a pas vocation à vivre dans le nouveau modèle métier. Une archive consultable, filtrable et protégée peut être suffisante si elle permet de répondre aux besoins de support, d’audit et de preuve.
Ce choix limite le coût de migration et évite de polluer le modèle cible avec des règles qui ne doivent plus guider les nouveaux parcours. Il rejoint les enjeux de source de vérité applicative.
Performance, volumes et fenêtres de bascule
Une migration qui fonctionne sur un échantillon peut échouer en conditions réelles. Volumes, index, contraintes, fichiers associés, transactions, verrous et temps de transformation peuvent modifier complètement la faisabilité d’une bascule.
Il faut tester la migration sur des volumes proches de la production, mesurer les temps d’exécution, prévoir les reprises partielles et définir la fenêtre acceptable pour l’activité. Une migration de nuit n’est pas une stratégie si personne ne sait quoi faire à trois heures du matin en cas d’écart.
La performance cible dépend du modèle de lecture
Le nouveau modèle peut être plus propre mais plus lent si les requêtes réelles n’ont pas été anticipées. Listes, filtres, exports, recherches, tableaux de bord et API doivent guider les index et les projections nécessaires.
Une migration BDD ne se termine donc pas au succès de l’import. Elle doit vérifier que les usages critiques restent rapides, compréhensibles et supervisés après la bascule.
Rollback, reprise et données modifiées
Le rollback d’une base est plus délicat que le rollback du code. Dès que des utilisateurs créent ou modifient des données dans le nouveau système, revenir à l’ancien état implique de traiter des écritures récentes, des fichiers, des emails, des jobs et parfois des intégrations déjà notifiées.
Le plan de rollback doit donc préciser ce qui est annulable, compensable ou seulement gelable. Certaines actions doivent être bloquées pendant la fenêtre de bascule. D’autres peuvent être rejouées. D’autres encore demandent une procédure métier.
Prévoir des points de contrôle métier
Les points de contrôle ne doivent pas être uniquement techniques. Avant d’ouvrir le nouveau système, les équipes doivent valider quelques cas représentatifs : dossier simple, dossier complexe, historique sensible, document, export, recherche, permission et reporting.
Ces validations réduisent le risque de découvrir après ouverture qu’une donnée “techniquement migrée” n’est pas utilisable par ceux qui en dépendent.
Recette de migration : contrôler ce qui compte
Une recette de migration efficace mélange contrôles automatiques, échantillons métier et scénarios de bout en bout. Les totaux sont utiles, mais insuffisants. Il faut aussi vérifier des cas limites, des dossiers anciens, des statuts rares et des objets liés à plusieurs systèmes.
Les contrôles doivent être décidés avant la migration, pas improvisés après. Sinon l’équipe valide ce qu’elle sait mesurer facilement, au lieu de mesurer ce qui protège vraiment le run.
Documenter les écarts acceptés
Toute migration produit des écarts : données purgées, formats normalisés, doublons fusionnés, historiques archivés ou statuts renommés. Ces écarts doivent être documentés, validés et expliquables.
Un écart connu et assumé n’est pas un incident. Un écart découvert par un utilisateur trois semaines après la bascule devient un problème de confiance.
Guides complémentaires à lire ensuite
Ces guides prolongent le sujet avec des angles migration progressive, reprise de données et arbitrage legacy.
Découper une migration progressive
Le guide Migration progressive : découper un outil historique aide à replacer la migration BDD dans un plan de reprise par lots.
Maîtriser les imports, exports et reprises
Le guide Import, export et migration de données détaille les contrôles à prévoir autour des fichiers, exports et historiques.
Arbitrer le legacy avant la refonte
Le guide Legacy : refaire ou faire évoluer aide à décider si la migration BDD s’inscrit dans une stabilisation ou dans une refonte plus large.
Conclusion : migrer une base, c’est migrer une responsabilité
Une migration BDD réussie ne se limite pas à déplacer des tables. Elle préserve le sens des données, les relations, les preuves, les historiques, les performances et la capacité de reprise. Elle distingue ce qui doit devenir actif, ce qui doit rester consultable et ce qui doit être nettoyé.
Avant une refonte logiciel métier, ce chantier doit être cadré avec autant de sérieux que les écrans ou l’architecture. Une base mal migrée peut rendre le nouveau système moins fiable que l’ancien, même si le code est plus moderne.
Dawap peut vous accompagner dans une trajectoire de développement web sur mesure qui relie audit, stratégie de données, migration legacy vers Symfony, contrôles de reprise, recette métier, rollback et sécurisation progressive du run.
