Migration | The .NET Blog

Supprimer le Travail Répétitif de la Migration avec l'Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Removing the Monkey Work of Migration with Agentic Platform Engineering — une présentation de Git-Ape (outil git d’ingénierie de plateforme agentique) qui migre un vrai dépôt Terraform AWS vers Azure, en se concentrant sur l’extraction d’intention plutôt que sur une conversion ligne par ligne.

L’entrée : contoso-migration

La source est un vrai projet Terraform (contoso-migration) qui déploie une application Next.js sur AWS — EC2 pour le calcul, ALB pour l’équilibrage de charge, S3 pour les artefacts, et des clés IAM pour l’identité. Coût : ~34 $/mois. L’objectif n’est pas de reproduire la même infrastructure sur Azure ; c’est de comprendre ce que le déploiement essaie réellement de faire et de le reconstruire avec des services natifs Azure.

Étape 1 : Validation et authentification

Git-Ape commence par valider tous les outils CLI requis — az, aws, gh, jq, git — et en confirmant les sessions d’authentification actives avant de toucher quoi que ce soit. Pas d’exécutions partielles.

Étape 2 : Extraction d’intention

L’agent lit l’intégralité du dépôt source via l’API GitHub et extrait l’intention de déploiement : runtime (Node.js), type de calcul, modèle d’ingress, gestion des artefacts, modèle d’identité, réseau et surveillance. C’est l’étape clé — elle construit un modèle sémantique de ce que fait le déploiement, pas quels mots-clés Terraform il utilise.

Étape 3 : Correspondance de services

Les services AWS sont mappés vers leurs équivalents Azure :

EC2 → App Service (Linux, Node 20 LTS)
ALB → Équilibrage de charge intégré d’App Service
Rôles/clés IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Étape 4 : Agent de critique

Avant de générer la sortie, un agent de critique s’exécute et détecte deux problèmes bloquants :

Anti-modèle de build au démarrage — le Terraform original exécutait npm install && npm run build sur EC2 au démarrage. Correction : construire dans CI, déployer un artefact prêt.
Blob Storage inutile — S3 était utilisé pour la mise en attente d’artefacts qui pouvait être éliminé avec un CI/CD approprié. L’agent de critique l’a supprimé entièrement.

Étape 5 : Sortie générée

Le résultat est ~80 lignes de Bicep au lieu des 200+ lignes originales de Terraform. L’agent a créé un nouveau dépôt GitHub avec infra/main.bicep et .github/workflows/deploy.yml et supprimé tous les fichiers spécifiques à AWS.

Comparaison de la posture de sécurité

La migration a également produit une amélioration significative de la sécurité :

AWS original	Sortie Azure
HTTP uniquement	HTTPS uniquement, TLS 1.2
SSH ouvert à 0.0.0.0/0	Pas d’exposition SSH
Clés d’accès IAM	OIDC + Managed Identity
Pas de surveillance	Application Insights

Coût : ~13 $/mois vs les 34 $/mois originaux.

Ce qui le distingue d’un convertisseur de syntaxe

L’étape de l’agent de critique est ce qui sépare ceci d’une traduction mécanique. Il a détecté des modèles qui auraient fonctionné sur AWS mais seraient incorrects sur Azure — et les a corrigés plutôt que de les répliquer. La sortie n’est pas “AWS en syntaxe Azure” ; c’est un déploiement natif Azure qui atteint le même objectif plus proprement.

Consultez le guide complet pour la trace complète de l’agent et les fichiers générés.

L'évaluation de modernisation de GitHub Copilot est le meilleur outil de migration que vous n'utilisez pas encore

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Migrer une application legacy .NET Framework vers .NET moderne est l’une de ces tâches que tout le monde sait devoir faire mais que personne ne veut commencer. Ce n’est jamais juste « changer le framework cible ». Ce sont des API qui ont disparu, des packages qui n’existent plus, des modèles d’hébergement qui fonctionnent totalement différemment, et un million de petites décisions sur ce qu’il faut containeriser, réécrire ou laisser tel quel.

Jeffrey Fritz vient de publier une plongée approfondie dans l’évaluation de modernisation de GitHub Copilot, et honnêtement ? C’est le meilleur outillage de migration que j’ai vu pour .NET. Pas à cause de la génération de code — c’est devenu standard maintenant. À cause du document d’évaluation qu’il produit.

Ce n’est pas qu’un moteur de suggestions de code

L’extension VS Code suit un modèle Évaluer → Planifier → Exécuter. La phase d’évaluation analyse l’intégralité de votre codebase et produit un document structuré qui capture tout : ce qui doit changer, quelles ressources Azure provisionner, quel modèle de déploiement utiliser. Tout en aval — infrastructure as code, containerisation, manifestes de déploiement — découle de ce que l’évaluation trouve.

L’évaluation est stockée sous .github/modernize/assessment/ dans votre projet. Chaque exécution produit un rapport indépendant, vous construisez ainsi un historique et pouvez suivre l’évolution de votre posture de migration au fur et à mesure que vous corrigez les issues.

Deux façons de commencer

Évaluation Recommandée — la voie rapide. Choisissez parmi des domaines curatés (Mise à jour Java/.NET, Cloud Readiness, Sécurité) et obtenez des résultats significatifs sans toucher à la configuration. Idéal pour un premier regard sur l’état de votre application.

Évaluation Personnalisée — la voie ciblée. Configurez exactement ce qu’il faut analyser : compute cible (App Service, AKS, Container Apps), OS cible, analyse de containerisation. Choisissez plusieurs cibles Azure pour comparer les approches de migration côte à côte.

Cette vue de comparaison est véritablement utile. Une app avec 3 issues obligatoires pour App Service pourrait en avoir 7 pour AKS. Voir les deux aide à prendre la décision d’hébergement avant de s’engager sur un chemin de migration.

Le détail des issues est actionnable

Chaque issue est accompagné d’un niveau de criticité :

Obligatoire — doit être corrigé sinon la migration échoue
Potentiel — pourrait impacter la migration, nécessite un jugement humain
Optionnel — améliorations recommandées, ne bloque pas la migration

Et chaque issue renvoie aux fichiers affectés et numéros de lignes, fournit une description détaillée de ce qui ne va pas et pourquoi c’est important pour votre plateforme cible, donne des étapes concrètes de remédiation (pas juste « corrigez ceci ») et inclut des liens vers la documentation officielle.

Vous pouvez confier des issues individuelles à des développeurs et ils ont tout ce dont ils ont besoin pour agir. C’est la différence entre un outil qui vous dit « il y a un problème » et un qui vous dit comment le résoudre.

Les chemins de mise à jour couverts

Pour .NET spécifiquement :

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Chaque chemin de mise à jour a des règles de détection qui savent quelles API ont été supprimées, quels patterns n’ont pas d’équivalent direct et quels problèmes de sécurité nécessitent une attention particulière.

Pour les équipes gérant plusieurs applications, il y a aussi un CLI qui supporte les évaluations batch multi-repo — clonez tous les repos, évaluez-les tous, obtenez des rapports par application plus une vue agrégée du portfolio.

Mon avis

Si vous êtes assis sur des applications legacy .NET Framework (et soyons honnêtes, la plupart des équipes enterprise le sont), c’est l’outil par lequel commencer. Le document d’évaluation seul vaut le temps — il transforme un vague « on devrait moderniser » en une liste concrète et priorisée d’éléments de travail avec des chemins clairs vers l’avant.

Le workflow collaboratif est malin aussi : exportez les évaluations, partagez-les avec votre équipe, importez-les sans relancer. Revues d’architecture où les décideurs ne sont pas ceux qui exécutent les outils ? Couvert.

Pour conclure

L’évaluation de modernisation de GitHub Copilot transforme la migration .NET d’un projet effrayant et indéfini en un processus structuré et traçable. Commencez avec une évaluation recommandée pour voir où vous en êtes, puis utilisez des évaluations personnalisées pour comparer les cibles Azure et construire votre plan de migration.

Lisez le walkthrough complet et récupérez l’extension VS Code pour l’essayer sur votre propre codebase.