02 / Migration
Java 8 vers 21, Spring Boot 2 vers 3, Wildfly vers Tomcat. Je prends en charge la migration complète avec un audit de risques en amont, une progression documentée et un plan de rollback — pour que la montée de version ne se transforme pas en incident de production.
Le contexte
Une version obsolète ne fait pas mal tout de suite. Elle se paie plus tard, d'un coup, et rarement au moment choisi.
Fin de support Votre version ne reçoit plus de correctifs de sécurité. Chaque audit, chaque questionnaire client et chaque appel d'offres le fait remonter.
Dépendances gelées Vous ne pouvez plus monter une librairie sans casser autre chose. Les vulnérabilités remontées par les scanners s'accumulent sans solution.
Recrutement difficile Les candidats se détournent d'une stack figée depuis dix ans, et les développeurs en poste s'en lassent.
Une tentative déjà abandonnée
Quelqu'un a commencé la migration, s'est heurté au mur javax vers
jakarta, et la branche dort depuis des mois.
Périmètre
Chaque migration a ses pièges propres. Voici ceux que je rencontre le plus souvent et sur lesquels j'interviens.
Le vrai travail est rarement dans la syntaxe. Il est dans la suppression du mécanisme d'accès interne au JDK, la disparition des modules Java EE du JDK, le changement de comportement du garbage collector par défaut et les librairies de génération de bytecode trop anciennes pour démarrer.
Le passage de javax.* à jakarta.* touche l'ensemble
des imports, mais aussi les dépendances tierces qui n'ont pas suivi. S'y ajoutent
la refonte de la configuration de Spring Security, les changements sur Hibernate 6
et les propriétés de configuration renommées ou supprimées.
Sortir d'un Wildfly, d'un JBoss ou d'un WebLogic pour un exécutable autonome : reprise des ressources déclarées côté serveur, des sources de données, de la sécurité conteneur et des accès JNDI, puis passage d'un déploiement d'archive à un artefact autoporté.
Hibernate et Spring Data réservent des changements de comportement discrets — stratégies de nommage, gestion des séquences, chargement différé — qui ne cassent pas la compilation mais changent les données produites. C'est là que les tests de non-régression prennent tout leur sens.
Quand la migration backend s'accompagne d'un front vieillissant, je traite aussi les montées de version Angular et la reprise des appels d'API impactés.
Livrables
Cartographie des dépendances bloquantes, inventaire des points de rupture identifiés, estimation de charge et classement des risques. Ce rapport a une valeur en soi : même si vous décidez de ne pas poursuivre, vous savez où vous en êtes et ce que la migration coûtera.
Pas un commit unique de dix mille lignes. La migration progresse par étapes cohérentes et testables, chacune justifiée, pour que votre équipe puisse suivre le raisonnement et reprendre la main à tout moment.
Le risque d'une migration n'est pas que ça ne compile pas — c'est que ça compile et que le comportement ait changé. Je consolide la couverture sur les zones sensibles avant de migrer, pour disposer d'un filet de sécurité pendant.
La procédure de bascule, les points de vérification, et surtout la marche à suivre pour revenir en arrière si quelque chose se passe mal le jour J. Une migration sans plan de retour n'est pas une migration, c'est un pari.
Déroulé
Je ne chiffre jamais une migration sans avoir vu le projet. L'audit inventorie les dépendances, repère les blocages réels et produit une estimation défendable. C'est aussi le moment où je vous dis si la migration est prématurée.
Le périmètre et le prix sont posés à partir de faits constatés, pas d'une estimation à l'aveugle. C'est la raison pour laquelle l'audit précède toujours l'engagement.
Votre branche principale reste intacte et livrable pendant toute l'opération. Vos développements en cours ne sont jamais bloqués par la migration.
Phase de recette sur votre environnement de test, accompagnement le jour de la mise en production, puis 7 jours de disponibilité pour les effets de bord.
Cadre
Stack
Questions
Entre 5 et 15 jours dans le cadre de ce forfait, selon la
taille du projet et surtout selon ses dépendances tierces. Ce qui allonge une
migration, ce n'est presque jamais le code applicatif : c'est une librairie non
maintenue qui n'a jamais été portée sur jakarta et pour laquelle il
faut trouver un remplaçant. L'audit sert précisément à identifier ces cas avant
de s'engager sur un délai.
Oui, et c'est le mode par défaut. La migration se fait sur une branche dédiée, régulièrement resynchronisée avec la vôtre. Il faut en revanche prévoir une fenêtre courte de gel au moment de la fusion finale, pour éviter les conflits sur un changement qui touche presque tous les fichiers.
C'est exactement ce que le plan de rollback prévoit. La procédure de retour arrière est écrite et vérifiée avant la bascule, pas improvisée le jour J. C'est aussi pourquoi je consolide les tests de non-régression avant de migrer : détecter un changement de comportement en recette coûte infiniment moins cher qu'en production.
Non, et c'est souvent déconseillé. Sur un système découpé en services, on migre service par service, en commençant par le moins critique pour valider la démarche. L'audit propose un ordre de passage argumenté.
Oui, l'audit est une prestation à part entière et il est chiffré comme telle — mais vous en gardez le livrable, qui reste utile : vous savez ce que la migration coûterait et quels risques vous portez en attendant. Il m'arrive de conclure qu'il vaut mieux attendre, et je le dis.
Décrivez-moi votre stack actuelle et sa version. Je réponds sous 24 h avec un premier avis sur la faisabilité et le cadre à prévoir.
Autres offres