AWS anunció el 16 de octubre de 2026 la disponibilidad general de una función de AWS Transform que convierte código de aplicaciones .NET vinculado a servicios de Microsoft Azure para ejecutarlo con servicios equivalentes de AWS. La novedad se dirige a equipos que quieren modernizar aplicaciones cloud sin reescribir manualmente cada llamada a los SDK del proveedor de origen.
El agente de modernización para .NET examina el código fuente enviado, localiza usos de SDK de Azure y presenta una evaluación con opciones de transformación. El usuario puede aceptar o ajustar esas propuestas. A continuación, la herramienta modifica el código e incorpora una fase de validación. AWS cita tres rutas disponibles: Azure Functions hacia AWS Lambda, Azure Blob Storage hacia Amazon S3 y Azure Queue Storage hacia Amazon SQS.
La conversión de Azure Cosmos DB hacia Amazon DynamoDB aparece en vista previa, con un grado de madurez distinto. La capacidad general está disponible en ocho regiones de AWS: Norte de Virginia, Mumbai, Tokio, Seúl, Sídney, Canadá Central, Fráncfort y Londres. El anuncio abre una vía concreta para reducir trabajo repetitivo durante una migración, aunque el proyecto completo sigue incluyendo decisiones y tareas fuera del alcance del conversor.
Una mesa de transformación para el código de aplicación
El interés técnico de AWS Transform está en su foco sobre dependencias reales del código. Una aplicación .NET puede contener llamadas específicas a almacenamiento, colas o ejecución serverless que condicionan su despliegue en una nube. Sustituir esas llamadas exige identificar el patrón usado, escoger un servicio de destino, adaptar tipos y configuración, y comprobar que la aplicación conserva su comportamiento esperado.
La herramienta organiza ese trabajo como un proceso asistido. Primero descubre referencias a los SDK compatibles. Después muestra la evaluación y las opciones de modernización para que una persona decida qué cambios aplicar. Ese punto de control evita tratar la conversión como una caja negra. El equipo puede revisar el alcance antes de alterar el repositorio y conservar criterio sobre decisiones que afectan al diseño y a la operación.
Las equivalencias anunciadas resultan fáciles de reconocer, pero cada pareja encierra diferencias. Una función serverless puede usar modelos de eventos, límites de ejecución y mecanismos de configuración propios. Los servicios de objetos gestionan permisos, metadatos y eventos con convenciones distintas. Las colas también difieren en semántica de entrega, visibilidad, reintentos y tratamiento de mensajes fallidos. La sustitución del SDK resuelve parte del cambio; las pruebas deben verificar los supuestos que rodean cada integración.
La validación incorporada por AWS aporta una comprobación dentro del flujo de transformación, aunque su existencia no equivale a una certificación del resultado. Cada aplicación conserva reglas de negocio, dependencias internas y condiciones de carga particulares. Los responsables del producto necesitan revisar el código generado, ejecutar sus suites automatizadas y añadir casos específicos para las rutas migradas.
Portabilidad con límites concretos
La disponibilidad general convierte esta función en una opción utilizable dentro del servicio, y WebProNews la sitúa en el debate sobre dependencia tecnológica y esfuerzo de migración. El avance reduce fricción en una capa muy visible: el código .NET que invoca servicios de Azure. Esa capa puede acumular cientos de referencias y patrones repetidos, de modo que automatizar una parte ofrece ahorro potencial de tiempo y una base más uniforme para la revisión.
El alcance comunicado está delimitado por los SDK y las correspondencias admitidas. AWS Transform no traslada por sí mismo la infraestructura, los datos almacenados, las redes, la identidad, los permisos, la observabilidad ni las cadenas de integración y despliegue. Tampoco reconstruye toda la arquitectura ni garantiza que el comportamiento, el rendimiento o el coste permanezcan iguales después del cambio. Una migración real debe tratar esos frentes como líneas de trabajo coordinadas.
La distinción tiene consecuencias prácticas. Convertir una llamada de Blob Storage a S3 deja pendientes la transferencia de objetos, las políticas de acceso, el cifrado, la residencia de datos, los eventos asociados y la estrategia de corte. Mover una función hacia Lambda exige preparar su empaquetado, variables, roles, disparadores, monitorización y límites operativos. En colas, el equipo tendrá que revisar tiempos de visibilidad, reintentos, duplicados y colas de mensajes fallidos.
Cosmos DB requiere todavía más prudencia porque su conversión hacia DynamoDB continúa en vista previa. Los modelos de datos, las claves de partición, las consultas y los patrones de consistencia condicionan el diseño de ambas bases. Un cambio automático puede ayudar con código compatible, mientras el modelado, la migración de datos y las pruebas de capacidad necesitan un plan técnico propio.
Cómo evaluar la herramienta en una migración real
Un piloto útil debería comenzar con un repositorio representativo y acotado, preferiblemente una aplicación con pruebas fiables y una dependencia clara de uno de los servicios compatibles. El primer objetivo consiste en medir cuántas referencias detecta AWS Transform, qué modificaciones propone, qué archivos altera y cuánto trabajo manual queda después de la conversión. Esa evidencia permite comparar el proceso asistido con una adaptación convencional.
La revisión humana merece un criterio explícito. El equipo puede exigir compilación limpia, análisis estático, pruebas unitarias, pruebas de integración contra servicios de destino y revisión por pares. También conviene probar errores, reintentos, concurrencia, límites y recuperación. La equivalencia funcional debe demostrarse con casos observables, mientras las pruebas de rendimiento y coste revelan cambios que una revisión de código difícilmente anticipa.
La arquitectura de destino necesita su propio diseño. AWS Transform puede acelerar modificaciones dentro de la aplicación, pero las decisiones sobre cuentas, regiones, redes, identidad, cifrado, copias, registros, alarmas y despliegue permanecen en manos de la organización. Los equipos que separen estas responsabilidades podrán aprovechar la automatización sin confundir velocidad de conversión con finalización de la migración.
Esta función también ofrece una señal útil para la estrategia de portabilidad. El código acoplado a un proveedor deja un coste visible cuando llega el momento de cambiar. Inventariar dependencias, encapsular integraciones y mantener pruebas sobre comportamiento reduce ese coste incluso si la migración nunca ocurre. Con AWS Transform, las empresas ganan una herramienta para acelerar transformaciones compatibles; el valor final se medirá en código revisado, sistemas probados y una operación estable en el destino.
