Introducción
Migrar aplicaciones .NET legacy con dependencias en SQL Server a entornos cloud nativos siempre implicó un desafío clave: la necesidad de mantener una conexión activa con la base de datos fuente durante el proceso de transformación del esquema. Esto generaba restricciones operativas, riesgos en sistemas de producción y mayor complejidad logística para equipos de infraestructura. AWS Transform for full-stack Windows modernization resolvió este problema con el lanzamiento de soporte para offline schema transformation, permitiendo iniciar la modernización con solo los archivos DDL del esquema de SQL Server.
La nueva capacidad elimina la dependencia de una instancia de base de datos en línea, simplificando la planificación de migraciones y habilitando escenarios como evaluaciones previas con backups estáticos o el trabajo con bases de datos en entornos aislados. Esto es especialmente relevante para empresas con estrictas políticas de acceso a sistemas de producción o con restricciones de red entre entornos on-premises y la nube.
Qué ocurrió
AWS Transform amplió sus capacidades para incluir la transformación offline de esquemas SQL Server hacia Amazon Aurora PostgreSQL. La funcionalidad, ahora en general availability, permite a los equipos cargar directamente archivos DDL (Data Definition Language) extraídos de sus bases de datos SQL Server y obtener un plan de transformación personalizable sin requerir conexión alguna al origen.
El proceso abarca tanto objetos de almacenamiento (tablas, esquemas, etc.) como objetos de código (procedimientos almacenados, funciones), utilizando AWS Database Migration Service (DMS) para la conversión de los primeros y un enfoque basado en agentes para los segundos. Además, la misma herramienta puede transformar automáticamente las aplicaciones .NET dependientes, actualizando strings de conexión, llamadas ADO.NET y Entity Framework para que sean compatibles con Aurora PostgreSQL.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de DevOps e infraestructura, esta funcionalidad reduce significativamente la complejidad operativa de las migraciones. Ya no es necesario provisionar instancias intermedias ni configurar conexiones VPN o Direct Connect para conectar AWS Transform con el entorno fuente. Esto acelera las fases iniciales del proyecto y minimiza el riesgo de afectar sistemas críticos durante la evaluación.
En el ámbito de seguridad, la capacidad offline mejora el cumplimiento de normas corporativas al evitar la exposición de bases de datos de producción a servicios externo. Los equipos pueden trabajar con copies de esquemas extraídos de backups, en entornos de desarrollo o sandboxes aislados. Además, al eliminarse la necesidad de credenciales de acceso al origen durante la transformación, se reduce la superficie de ataque potencial.
Para los equipos de cloud, esta funcionalidad facilita la adopción de Aurora PostgreSQL como destino para cargas de trabajo Windows legacy. Aurora ofrece escalabilidad automática, alta disponibilidad y compatibilidad conPostgreSQL 13 y 14 (las versiones soportadas por AWS Transform), lo que permite modernizar la infraestructura de base de datos junto con la aplicación.
Detalles técnicos
La transformación offline en AWS Transform se basa en dos componentes principales:
- Conversión de objetos de almacenamiento: Implementada mediante AWS DMS, que analiza los archivos DDL de SQL Server y los traduce a el esquema equivalente en Aurora PostgreSQL. Soporte incluye:
– Restricciones (primary keys, foreign keys, unique, check)
– Índices
– Vistas
– Sinónimos
- Conversión de objetos de código: Un motor basado en agentes analiza procedimientos almacenados, funciones y triggers en T-SQL y los reescribe en PL/pgSQL. El proceso incluye:
TOP → LIMIT, @variable → variable)– Adaptación de funciones sistema (ej: GETDATE() → CURRENT_DATE)
– Manejo de cursores y transacciones
– Validación de equivalencia funcional mediante pruebas automáticas
El workflow completo consiste en los siguientes pasos:
- Extraer el DDL del esquema SQL Server (mediante SSMS,
sqlpackage.exeo queries comosp_help) - Cargar los archivos .sql en AWS Transform (hasta 500 MB por archivo)
- Analizar la complejidad del esquema y código (el tool genera un reporte con categorización de objetos: Automatically converted, Requires action, Not supported)
- Revisar y personalizar el plan de transformación en la consola web
- Opcionalmente, iterar sobre los objetos que requieren acción manual
- Desplegar el esquema convertido a una instancia Aurora PostgreSQL
Para los objetos que requieren ajustes manuales, AWS Transform ofrece dos opciones:
- Edición en consola: Interface web con editor de código y visualización de diferencias entre el original y la versión convertida.
- Hand-off a IDE: Mediante el AWS Transform MCP server, se puede exportar el proyecto a VS Code o otros IDEs con soporte para Model Context Protocol.
Adicionalmente, existe un synthetic data workflow que permite poblar la base de datos Aurora destino con datos de prueba generados automáticamente a partir del esquema, para validación end-to-end de la aplicación modernizada.
Actualmente, la funcionalidad está disponible solo en la región US East (N. Virginia). El soporte incluye SQL Server 2012 y versiones posteriores, y Aurora PostgreSQL 13 y 14.
Qué deberían hacer los equipos técnicos
Para evaluar esta nueva capacidad, los equipos pueden seguir estos pasos concretos:
- Preparar los archivos DDL:
– Opción 2: Ejecutar el comando sqlpackage.exe desde la línea de comandos:
sqlpackage.exe /Action:Extract /SourceServerName:mi-servidor /SourceDatabaseName:mi-base /TargetFile:"schema.sql" /p Storage=File /p ExtractAll=true /p ExcludeObjectTypes=Tables;Data;Blobs
– Opción 3: Generar scripts con queries como:
EXEC sp_help 'dbo.MiTabla';
- Crear un proyecto en AWS Transform:
– Seleccionar Offline source como tipo de fuente y cargar los archivos DDL.
- Analizar y planificar:
– Priorizar la conversión de esquemas menos complejos para validar el proceso.
- Validar la transformación:
– Ejecutar las pruebas de equivalencia funcional generadas automáticamente.
– Probar las aplicaciones .NET conectadas a la nueva base de datos (AWS Transform puede generar una versión compatibles de los binarios).
- Iterar y ajustar:
– Regenerar el esquema después de cada ajuste.
- Planificar la migración de datos:
Conclusión
La incorporación de transformación offline en AWS Transform elimina una barrera clave para la modernización de aplicaciones Windows legacy hacia Aurora PostgreSQL. Al permitir trabajar con archivos DDL estáticos, los equipos ganan flexibilidad, reducen riesgos y pueden acelerar las fases iniciales del proyecto. La integración con el workflow de modernización full-stack —que incluye la conversión automática de código .NET— ofrece un path completo desde SQL Server hasta una arquitectura cloud nativa.
Si bien la funcionalidad actual tiene limitaciones (región única, tamaño máximo de archivos), es un avance significativo para escenarios comunes en migraciones enterprise. Los equipos deberían evaluar su uso en projects de modernización, especialmente aquellos con restricciones de conectividad o requisitos de seguridad estrictos.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/7/aws-transform-windows-sql-schema-aurora
- https://aws.amazon.com/blogs/containers/