En trois ans, j'ai livré des applications sur .NET 5, 6, 8 et 10, et conduit plusieurs montées de version sur des projets déjà en production. La leçon la plus constante est contre-intuitive : la migration est rarement le problème. C'est l'attente qui l'est.
Une montée d'une version majeure sur une application maintenue se fait généralement en quelques jours. Le même saut sur une application laissée trois versions en arrière devient un projet à part entière, parce que les breaking changes s'accumulent et se combinent, et que les bibliothèques tierces ne suivent plus la même trajectoire.
L'approche qui a le mieux fonctionné est progressive plutôt que frontale : monter le framework cible en premier, laisser les avertissements de compilation guider le travail, et traiter les changements de comportement un par un plutôt que de réécrire. Sur un projet gouvernemental de gestion de permis, la migration de .NET 6 vers .NET 8 s'est faite ainsi, sur l'ensemble de la solution, avec en bénéfice direct une réduction des temps de build et de restauration des packages.
Entity Framework Core mérite une vigilance particulière. C'est la dépendance où les changements de comportement sont les plus silencieux : une requête qui compilait et s'exécutait produit soudain un SQL différent, ou bascule d'une évaluation côté serveur à une évaluation côté client. Sans tests d'intégration sur une vraie base, ce type de régression ne se voit qu'en production.
C'est d'ailleurs l'argument le plus solide en faveur des tests d'intégration avec une base réelle, sous Docker et Testcontainers : ils ne servent pas seulement à valider la fonctionnalité du jour, ils rendent la prochaine montée de version tenable.