Migration | The .NET Blog

Eliminare il Lavoro Ripetitivo della Migrazione con l'Agentic Platform Engineering

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Removing the Monkey Work of Migration with Agentic Platform Engineering — una guida passo per passo di Git-Ape (strumento git di ingegneria di piattaforma agentiva) che migra un vero repository Terraform AWS verso Azure, concentrandosi sull’estrazione dell’intenzione piuttosto che sulla conversione riga per riga.

L’input: contoso-migration

La fonte è un vero progetto Terraform (contoso-migration) che distribuisce un’app Next.js su AWS — EC2 per il computing, ALB per il bilanciamento del carico, S3 per gli artefatti e chiavi IAM per l’identità. Costo: ~34 $/mese. L’obiettivo non è riprodurre la stessa infrastruttura su Azure; è capire cosa il deployment sta effettivamente cercando di fare e ricostruirlo con servizi nativi Azure.

Passo 1: Validazione e autenticazione

Git-Ape inizia validando tutti gli strumenti CLI richiesti — az, aws, gh, jq, git — e confermando le sessioni di autenticazione attive prima di toccare qualsiasi cosa. Nessuna esecuzione parziale.

Passo 2: Estrazione dell’intenzione

L’agente legge l’intero repository sorgente tramite l’API GitHub ed estrae l’intenzione del deployment: runtime (Node.js), tipo di computing, modello di ingress, gestione degli artefatti, modello di identità, rete e monitoraggio. Questo è il passaggio chiave — sta costruendo un modello semantico di cosa fa il deployment, non quali parole chiave Terraform usa.

Passo 3: Mappatura dei servizi

I servizi AWS vengono mappati agli equivalenti Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Bilanciamento del carico integrato di App Service
Ruoli/chiavi IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente critico

Prima di generare l’output, viene eseguito un agente critico che individua due problemi bloccanti:

Anti-pattern di build all’avvio — il Terraform originale eseguiva npm install && npm run build su EC2 all’avvio. Fix: costruire in CI, distribuire un artefatto pronto.
Blob Storage non necessario — S3 veniva usato per lo staging degli artefatti che poteva essere eliminato con un CI/CD appropriato. L’agente critico lo ha rimosso completamente.

Passo 5: Output generato

Il risultato è ~80 righe di Bicep invece delle 200+ righe originali di Terraform. L’agente ha creato un nuovo repository GitHub con infra/main.bicep e .github/workflows/deploy.yml e rimosso tutti i file specifici di AWS.

Confronto della postura di sicurezza

La migrazione ha anche prodotto un significativo miglioramento della sicurezza:

AWS originale	Output Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH aperto a 0.0.0.0/0	Nessuna esposizione SSH
Chiavi di accesso IAM	OIDC + Managed Identity
Nessun monitoraggio	Application Insights

Costo: ~13 $/mese vs i 34 $/mese originali.

Cosa lo differenzia da un convertitore di sintassi

Il passaggio dell’agente critico è ciò che separa questo da una traduzione meccanica. Ha individuato pattern che avrebbero funzionato su AWS ma sarebbero stati sbagliati su Azure — e li ha corretti invece di replicarli. L’output non è “AWS in sintassi Azure”; è un deployment nativo Azure che raggiunge lo stesso obiettivo in modo più pulito.

Vedi la guida completa per la traccia completa dell’agente e i file generati.

La valutazione di modernizzazione di GitHub Copilot è il miglior strumento di migrazione che non stai ancora usando

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

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Migrare un’app legacy .NET Framework a .NET moderno è una di quelle attività che tutti sanno di dover fare ma che nessuno vuole iniziare. Non è mai solo “cambiare il target framework.” Sono API che sono scomparse, pacchetti che non esistono più, modelli di hosting che funzionano in modo completamente diverso, e un milione di piccole decisioni su cosa containerizzare, cosa riscrivere e cosa lasciare così.

Jeffrey Fritz ha appena pubblicato un approfondimento sulla valutazione di modernizzazione di GitHub Copilot, e onestamente? È il miglior tooling di migrazione che abbia visto per .NET. Non per la generazione di codice — quello è ormai standard. Per il documento di valutazione che produce.

Non è solo un motore di suggerimenti di codice

L’estensione VS Code segue un modello Valuta → Pianifica → Esegui. La fase di valutazione analizza l’intero codebase e produce un documento strutturato che cattura tutto: cosa deve cambiare, quali risorse Azure provisionare, quale modello di deployment usare. Tutto ciò che segue — infrastructure as code, containerizzazione, manifesti di deployment — deriva da ciò che la valutazione trova.

La valutazione viene salvata in .github/modernize/assessment/ nel tuo progetto. Ogni esecuzione produce un report indipendente, così accumuli uno storico e puoi monitorare come la tua postura di migrazione evolve man mano che risolvi gli issue.

Due modi per iniziare

Valutazione Consigliata — il percorso veloce. Scegli tra domini curati (Upgrade Java/.NET, Cloud Readiness, Sicurezza) e ottieni risultati significativi senza toccare la configurazione. Ottimo per un primo sguardo a dove si trova la tua app.

Valutazione Personalizzata — il percorso mirato. Configura esattamente cosa analizzare: compute target (App Service, AKS, Container Apps), OS target, analisi della containerizzazione. Scegli più target Azure per confrontare gli approcci di migrazione fianco a fianco.

Quella vista di confronto è genuinamente utile. Un’app con 3 issue obbligatori per App Service potrebbe averne 7 per AKS. Vedere entrambi aiuta a guidare la decisione sull’hosting prima di impegnarsi in un percorso di migrazione.

La suddivisione degli issue è azionabile

Ogni issue viene con un livello di criticità:

Obbligatorio — deve essere risolto o la migrazione fallisce
Potenziale — potrebbe impattare la migrazione, necessita di giudizio umano
Opzionale — miglioramenti raccomandati, non bloccano la migrazione

E ogni issue linka ai file interessati e numeri di riga, fornisce una descrizione dettagliata di cosa c’è che non va e perché conta per la tua piattaforma target, dà passaggi concreti di remediation (non solo “sistema questo”), e include link alla documentazione ufficiale.

Puoi assegnare singoli issue agli sviluppatori e hanno tutto ciò di cui hanno bisogno per agire. Questa è la differenza tra uno strumento che ti dice “c’è un problema” e uno che ti dice come risolverlo.

I percorsi di upgrade coperti

Per .NET specificamente:

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

Ogni percorso di upgrade ha regole di rilevamento che sanno quali API sono state rimosse, quali pattern non hanno un equivalente diretto e quali problemi di sicurezza richiedono attenzione.

Per i team che gestiscono più applicazioni, c’è anche un CLI che supporta valutazioni batch multi-repo — clona tutti i repo, valutali tutti, ottieni report per app più una vista aggregata del portfolio.

La mia opinione

Se sei seduto su applicazioni legacy .NET Framework (e siamo onesti, la maggior parte dei team enterprise lo è), questo è lo strumento con cui iniziare. Il solo documento di valutazione vale il tempo — trasforma un vago “dovremmo modernizzare” in una lista concreta e prioritizzata di elementi di lavoro con percorsi chiari in avanti.

Il workflow collaborativo è intelligente anche: esporta le valutazioni, condividile con il tuo team, importale senza rieseguire. Review di architettura dove chi decide non è chi esegue gli strumenti? Coperto.

Conclusione

La valutazione di modernizzazione di GitHub Copilot trasforma la migrazione .NET da un progetto spaventoso e indefinito in un processo strutturato e tracciabile. Inizia con una valutazione consigliata per vedere a che punto sei, poi usa valutazioni personalizzate per confrontare i target Azure e costruire il tuo piano di migrazione.

Leggi il walkthrough completo e scarica l’estensione VS Code per provarla sul tuo codebase.