Repousser une montée de version est une décision rationnelle à court terme. Le site fonctionne, la mise à jour prend du temps, et rien ne presse. Le problème est que la facture n'arrive pas au moment où la décision est prise.
Le coût réel se paie en une fois
Une migration faite à l'heure est un travail de quelques jours : on suit les notes de version, on corrige les appels dépréciés, on teste. Une migration repoussée trois ans est un chantier : plusieurs versions majeures d'écart, des dépendances qui ne suivent plus, et du code dont les auteurs ont quitté le projet.
Le même travail, fait au mauvais moment, coûte cinq à dix fois plus cher. Et il se fait alors en urgence, donc mal.
La fin du support n'est pas une date administrative
Quand une version cesse d'être maintenue, elle ne devient pas « un peu moins sûre » : elle cesse simplement de recevoir les correctifs. Une faille publiée après cette date reste ouverte indéfiniment. L'écart avec les versions supportées ne cesse plus de se creuser.
C'est le scénario que redoutent les équipes d'exploitation : une vulnérabilité critique rendue publique, un correctif disponible pour tout le monde sauf pour vous.
Ce qu'on recommande
Tenez un inventaire des versions en production — langage, base de données, dépendances principales — avec leur date de fin de support. Un tableau suffit. Dès qu'une échéance passe sous les douze mois, la migration entre au planning plutôt que dans les regrets.
Ce n'est pas du perfectionnisme. C'est la différence entre choisir son calendrier et le subir.