Migration .NET 8 vers .NET 10 : le guide concret du freelance

.NET 8 et .NET 9 restent supportés jusqu’au 10 novembre 2026. À cette date, les mises à jour de maintenance et de sécurité de Microsoft s’arrêtent ; les applications continuent à fonctionner. Pour une application .NET 8, préparer une migration vers .NET 10 LTS demande de vérifier le code, les dépendances, l’hébergement et les parcours métier. Ce guide détaille les étapes et les preuves à réunir avant la bascule.

Support .NET 8, 9 et 10 : les dates vérifiées

• .NET 8 LTS, publié le 14 novembre 2023 : fin de support le 10 novembre 2026.
• .NET 9 STS, publié le 12 novembre 2024 : fin de support le 10 novembre 2026. La politique STS prévoit désormais 24 mois de support.
• .NET 10 LTS, publié le 11 novembre 2025 : support jusqu’en novembre 2028.

Ces informations ont été vérifiées le 23 octobre 2026 dans l’annonce Microsoft sur la fin de support de .NET 8 et 9. Le présent guide corrige son ancienne mention d’une fin de support de .NET 9 en mai. À l’approche du 10 novembre, commencez par identifier les applications exposées, les dépendances bloquantes et les fenêtres de recette disponibles. Un calendrier réaliste dépend de cet inventaire, pas d’une durée standard.

Pour obtenir ce premier inventaire, demandez un diagnostic de migration .NET : précisez les applications, leur hébergement, leurs dépendances sensibles et votre échéance.

Peut-on passer directement de .NET 8 à .NET 10 ?

Oui, une application peut cibler directement net10.0. Déployer .NET 9 en production n’est pas un prérequis, mais les changements introduits par les deux versions doivent être examinés. .NET 9 n’apporte plus de délai de support supplémentaire par rapport à .NET 8. Pour une bibliothèque partagée, un multi-ciblage temporaire peut permettre aux applications consommatrices de migrer séparément.

Une application .NET Framework 4.x relève d’un portage distinct : vérifier ses bibliothèques, ses API Windows et ses composants web avant de reprendre ce déroulé. La prestation de reprise et migration d’applications .NET commence par cette distinction.

Étape 1 : établir une référence avant modification

Relevez les solutions, projets, services externes, bases, tâches planifiées et plateformes d’exécution. Notez le SDK utilisé avec dotnet --info et les paquets directs et transitifs avec dotnet list package --include-transitive. Vérifiez leur maintenance et leur compatibilité ; une bibliothèque compatible n’a pas nécessairement besoin d’une montée majeure uniquement pour changer le runtime.

Sur la version actuelle, exécutez les parcours critiques et conservez les résultats attendus : réponses d’API, règles d’autorisation, exports et écritures en base. Mesurez les temps de réponse et les ressources sur un jeu de données représentatif. En l’absence de tests, sécurisez d’abord ces parcours par des tests d’intégration reproductibles.

Étape 2 : aligner SDK, projets, paquets et hébergement

• Installez un SDK .NET 10 maintenu sur les postes et agents CI ; alignez global.json sur la version réellement installée.
• Modifiez le TargetFramework en net10.0, ou sa variante de plateforme si nécessaire. Mettez à jour les références Microsoft et les fournisseurs EF Core concernés vers des versions compatibles entre elles.
• Exécutez dotnet restore, dotnet build et dotnet test. Analysez les avertissements, les dépendances transitives et les différences de comportement après compilation.
• Alignez l’hébergement : runtime ou Hosting Bundle, images de build et d’exécution Docker, système d’exploitation, architecture processeur et publication autonome le cas échéant.

Microsoft détaille la mise à niveau de .NET et celle d’ASP.NET Core vers .NET 10. Adaptez les étapes à vos workloads ; changer le fichier projet ne valide pas les échanges métier.

Étape 3 : traiter les ruptures de compatibilité de .NET 9 et 10

Parcourez les inventaires .NET 9 et .NET 10 par technologie. Pour chaque changement applicable, consignez le composant touché, le choix retenu et le test qui prouve le résultat. Les ruptures peuvent affecter le code source, le chargement de binaires ou le comportement à l’exécution : un build réussi n’écarte pas ces dernières.

• EF Core 9 : l’application des migrations lève une exception si le modèle présente des modifications non incluses dans une migration. Vérifiez le modèle et les scripts sur une copie de base représentative. Ruptures EF Core 9.
• EF Core 10 : les outils exigent --framework pour un projet multi-cible. Vérifiez les commandes de génération et d’application des migrations dans la CI. Examinez aussi les changements de SQL généré avec votre fournisseur. Ruptures EF Core 10.
• API, authentification et sérialisation : confrontez les changements applicables aux contrats réels. Testez les clients existants, les refus d’accès, les valeurs nulles et les formats de dates ; ne vous limitez pas aux réponses nominales.

Étape 4 : constituer le dossier de recette et de retour arrière

Le dossier doit associer chaque scénario à une version livrée, un jeu d’entrée, un résultat métier attendu et une preuve. Définissez les seuils de performance avec l’équipe avant de comparer les résultats, dans des conditions similaires. Aucun gain de vitesse n’est garanti par le seul changement de runtime.

• Parcours métier : lecture, création, modification et annulation, droits et refus, exports et traitements planifiés.
• Données et interfaces : migrations de schéma, concurrence, transactions, contrats JSON et erreurs des services externes.
• Exploitation : déploiement en préproduction, redémarrage, journaux, alertes, charge représentative et observation.
• Retour arrière : artefact précédent disponible, configuration restaurable, compatibilité du schéma et traitement des données déjà écrites. Testez la procédure ; revenir au binaire précédent ne restaure pas la base.

Ce que produit un diagnostic de migration

Un premier périmètre peut porter sur une solution et son chemin de livraison. Les livrables sont un inventaire des dépendances et blocages, une liste des ruptures applicables, un découpage de migration, les critères de recette et une estimation conditionnée aux risques identifiés. Les corrections et la mise en production sont ensuite définies sur cette base. Vous pouvez consulter la prestation .NET pour le déroulement d’une intervention.