Un logiciel vieillissant ne tombe pas en panne du jour au lendemain. Il ralentit, devient difficile à faire évoluer, ne reçoit plus de mises à jour de sécurité, et finit par dépendre d’une seule personne qui sait encore comment il fonctionne. La migration d’un logiciel vieillissant est alors inévitable — la vraie question est de la mener sans arrêter l’activité ni exploser le budget.
Les signes qu’un logiciel vieillissant doit être migré
- Le langage ou le framework n’est plus maintenu (PHP 5, anciennes versions de Symfony, Access, Windev…)
- Chaque évolution prend des semaines et casse autre chose
- Les données sont exportées dans Excel pour être exploitées
- Aucune documentation, et un seul développeur connaît le code
- Le logiciel ne peut pas se connecter à votre site, votre CRM ou vos outils IA
Deux ou trois de ces signes suffisent à justifier un audit. Attendre augmente le coût : plus la dette technique s’accumule, plus la migration est longue.
Étape 1 : auditer avant de décider
Une migration réussie commence par un état des lieux de deux à trois semaines : cartographie des fonctionnalités réellement utilisées, qualité du code, structure et volume des données, dépendances avec les autres outils. On découvre presque toujours qu’une partie des fonctionnalités n’est plus utilisée — autant ne pas la migrer.
Étape 2 : choisir la bonne stratégie de migration
Moderniser l’existant
Si l’architecture est saine, on monte de version, on ajoute des tests, on remplace les briques obsolètes une à une. C’est la voie la moins risquée, par exemple pour une application Symfony restée sur une ancienne version — un travail de reprise que mène régulièrement notre agence Symfony.
Réécrire progressivement
Si le code est trop fragile, on reconstruit module par module à côté de l’ancien logiciel, en partageant la même base de données ou en synchronisant les deux. Chaque module migré remplace l’ancien, sans « grand soir ».
Remplacer par un autre outil
Si vos besoins sont devenus standards, un logiciel du marché peut suffire. Notre guide développer ou acheter un logiciel aide à trancher. Pour un outil de gestion central, la refonte passe souvent par un ERP sur mesure : voir ERP sur mesure ou ERP du marché.
Étape 3 : migrer les données sans arrêter l’activité
Les données sont le cœur de la migration d’un logiciel vieillissant. Nous les nettoyons, dédoublonnons et transformons vers un nouveau modèle, puis organisons une période de double fonctionnement : l’ancien et le nouveau système tournent en parallèle le temps de valider les résultats. Nous avons décrit cette approche dans migrer depuis Excel sans arrêter l’activité.
Une migration se juge à un critère simple : vos équipes ont continué à travailler pendant toute sa durée.
Quels coûts pour la migration d’un logiciel vieillissant ?
Le coût dépend moins de l’âge du logiciel que de quatre facteurs :
- Le périmètre fonctionnel réellement utilisé — d’où l’importance de l’audit
- La qualité et le volume des données à reprendre
- Le nombre d’intégrations avec d’autres outils (comptabilité, site, CRM, partenaires)
- La stratégie choisie : moderniser coûte généralement moins que réécrire, qui coûte moins qu’un remplacement mal préparé
Il faut aussi chiffrer le coût de ne rien faire : temps perdu, risques de sécurité, dépendance à une personne, opportunités manquées faute d’intégration. Un chiffrage par lot, livré toutes les deux semaines, permet de maîtriser le budget et d’arrêter ou réorienter le projet à tout moment.
Les erreurs à éviter
- Tout réécrire d’un coup, avec une bascule unique
- Reproduire à l’identique des fonctionnalités que personne n’utilise
- Migrer les données à la fin plutôt que dès le début
- Oublier de former les utilisateurs
Migration d’un logiciel vieillissant : questions fréquentes
Combien de temps dure la migration d’un logiciel vieillissant ?
Cela dépend du périmètre et de la stratégie. Une modernisation peut se faire en quelques semaines ; une réécriture progressive s’étale sur plusieurs mois, module par module, sans interruption de l’activité.
Faut-il tout réécrire ?
Rarement. L’audit montre souvent qu’une partie du logiciel peut être modernisée et qu’une autre n’est plus utilisée. On ne réécrit que ce qui le justifie.
Que faire si personne ne connaît plus le code ?
C’est une situation courante. L’audit de code, l’ajout de tests sur les fonctions critiques et la documentation au fil de l’eau permettent de reprendre la main avant toute évolution.
Par où commencer
Commencez par l’inventaire : ce que le logiciel fait, ce qu’il coûte et ce qu’il empêche. Pour un regard extérieur, faites l’audit en 2 minutes ou parlez à un expert : nous vous proposerons la stratégie de migration la moins risquée pour votre cas.