Migration | The .NET Blog

Eliminando el Trabajo Tedioso de la Migración con Agentic Platform Engineering

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Removing the Monkey Work of Migration with Agentic Platform Engineering — un recorrido de Git-Ape (herramienta git de ingeniería de plataformas agéntica) que migra un repositorio Terraform real de AWS a Azure, centrándose en la extracción de intención en lugar de una conversión línea por línea.

La entrada: contoso-migration

La fuente es un proyecto Terraform real (contoso-migration) que despliega una aplicación Next.js en AWS — EC2 para cómputo, ALB para balanceo de carga, S3 para artefactos y claves IAM para identidad. Costo: ~34 $/mes. El objetivo no es reproducir la misma infraestructura en Azure; es descubrir qué intenta hacer realmente el despliegue y reconstruirlo con servicios nativos de Azure.

Paso 1: Validación y autenticación

Git-Ape comienza validando todas las herramientas CLI requeridas — az, aws, gh, jq, git — y confirmando las sesiones de autenticación activas antes de tocar nada. Sin ejecuciones parciales.

Paso 2: Extracción de intención

El agente lee todo el repositorio fuente a través de la API de GitHub y extrae la intención de despliegue: tiempo de ejecución (Node.js), tipo de cómputo, patrón de ingress, manejo de artefactos, modelo de identidad, red y monitoreo. Este es el paso clave — está construyendo un modelo semántico de lo que hace el despliegue, no qué palabras clave de Terraform utiliza.

Paso 3: Mapeo de servicios

Los servicios de AWS se mapean a equivalentes de Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceo de carga integrado de App Service
Roles/claves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Paso 4: Agente crítico

Antes de generar la salida, se ejecuta un agente crítico que detecta dos problemas bloqueantes:

Anti-patrón de build al inicio — el Terraform original ejecutaba npm install && npm run build en EC2 al arrancar. Solución: construir en CI, desplegar un artefacto listo.
Blob Storage innecesario — S3 se usaba para la preparación de artefactos que podría eliminarse con CI/CD adecuado. El agente crítico lo eliminó por completo.

Paso 5: Salida generada

El resultado son ~80 líneas de Bicep en lugar de las 200+ líneas originales de Terraform. El agente creó un nuevo repositorio GitHub con infra/main.bicep y .github/workflows/deploy.yml y eliminó todos los archivos específicos de AWS.

Comparación de postura de seguridad

La migración también produjo una mejora significativa de seguridad:

AWS original	Salida Azure
Solo HTTP	Solo HTTPS, TLS 1.2
SSH abierto a 0.0.0.0/0	Sin exposición SSH
Claves de acceso IAM	OIDC + Managed Identity
Sin monitoreo	Application Insights

Costo: ~13 $/mes vs los 34 $/mes originales.

Qué lo diferencia de un convertidor de sintaxis

El paso del agente crítico es lo que separa esto de una traducción mecánica. Detectó patrones que habrían funcionado en AWS pero serían incorrectos en Azure — y los corrigió en lugar de replicarlos. La salida no es “AWS en sintaxis de Azure”; es un despliegue nativo de Azure que logra el mismo objetivo de manera más limpia.

Consulta el recorrido completo para ver la traza completa del agente y los archivos generados.

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

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

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Migrar una aplicación legacy de .NET Framework a .NET moderno es una de esas tareas que todos saben que deberían hacer pero nadie quiere empezar. Nunca es solo “cambiar el target framework.” Son APIs que desaparecieron, paquetes que ya no existen, modelos de hosting que funcionan completamente diferente, y un millón de pequeñas decisiones sobre qué containerizar, qué reescribir y qué dejar como está.

Jeffrey Fritz acaba de publicar una inmersión profunda en la evaluación de modernización de GitHub Copilot, y honestamente, es el mejor tooling de migración que he visto para .NET. No por la generación de código — eso ya es estándar. Por el documento de evaluación que produce.

No es solo un motor de sugerencias de código

La extensión de VS Code sigue un modelo de Evaluar → Planificar → Ejecutar. La fase de evaluación analiza todo tu código base y produce un documento estructurado que captura todo: qué necesita cambiar, qué recursos de Azure aprovisionar, qué modelo de despliegue usar. Todo lo posterior — infraestructura como código, containerización, manifiestos de despliegue — fluye de lo que la evaluación encuentra.

La evaluación se almacena en .github/modernize/assessment/ en tu proyecto. Cada ejecución produce un reporte independiente, así que acumulas un historial y puedes rastrear cómo evoluciona tu postura de migración a medida que corriges issues.

Dos formas de empezar

Evaluación Recomendada — el camino rápido. Elige entre dominios curados (Actualización Java/.NET, Cloud Readiness, Seguridad) y obtén resultados significativos sin tocar configuración. Genial para una primera mirada a dónde está tu aplicación.

Evaluación Personalizada — el camino dirigido. Configura exactamente qué analizar: cómputo objetivo (App Service, AKS, Container Apps), SO objetivo, análisis de containerización. Elige múltiples destinos Azure para comparar enfoques de migración lado a lado.

Esa vista de comparación es genuinamente útil. Una app con 3 issues obligatorios para App Service podría tener 7 para AKS. Ver ambos ayuda a decidir el hosting antes de comprometerse con un camino de migración.

El desglose de issues es accionable

Cada issue viene con un nivel de criticidad:

Obligatorio — debe corregirse o la migración falla
Potencial — podría impactar la migración, necesita juicio humano
Opcional — mejoras recomendadas, no bloquean la migración

Y cada issue enlaza a archivos afectados y números de línea, proporciona una descripción detallada de qué está mal y por qué importa para tu plataforma objetivo, da pasos concretos de remediación (no solo “arregla esto”), e incluye enlaces a documentación oficial.

Puedes asignar issues individuales a desarrolladores y tienen todo lo que necesitan para actuar. Esa es la diferencia entre una herramienta que te dice “hay un problema” y una que te dice cómo resolverlo.

Las rutas de actualización cubiertas

Para .NET específicamente:

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

Cada ruta de actualización tiene reglas de detección que saben qué APIs fueron eliminadas, qué patrones no tienen equivalente directo, y qué issues de seguridad necesitan atención.

Para equipos que gestionan múltiples aplicaciones, también hay un CLI que soporta evaluaciones batch multi-repo — clona todos los repos, evalúalos todos, obtén reportes por app más una vista de portafolio agregada.

Mi opinión

Si estás sentado sobre aplicaciones legacy de .NET Framework (y seamos honestos, la mayoría de los equipos empresariales lo están), esta es la herramienta con la que empezar. Solo el documento de evaluación vale el tiempo — convierte un vago “deberíamos modernizar” en una lista concreta y priorizada de elementos de trabajo con caminos claros hacia adelante.

El flujo de trabajo colaborativo también es inteligente: exporta evaluaciones, compártelas con tu equipo, impórtalas sin re-ejecutar. ¿Revisiones de arquitectura donde los que toman decisiones no son los que ejecutan las herramientas? Cubierto.

Para cerrar

La evaluación de modernización de GitHub Copilot transforma la migración de .NET de un proyecto aterrador e indefinido en un proceso estructurado y rastreable. Empieza con una evaluación recomendada para ver dónde estás, luego usa evaluaciones personalizadas para comparar destinos Azure y construir tu plan de migración.

Lee el walkthrough completo y descarga la extensión de VS Code para probarlo en tu propio código.