Introducción
En el proceso de migración del cliente, enfrentamos el desafío de migrar múltiples bases de datos SQL Server desde Azure SQL Database a Amazon RDS para SQL Server. La motivación principal fue económica, pero también surgieron oportunidades para revisar la arquitectura, automatizar procesos y consolidar entornos.
En Azure, las bases de datos estaban distribuidas por producto o servicio, lo que inicialmente nos brindó flexibilidad para realizar pruebas. Sin embargo, al llevar esa arquitectura a AWS, descubrimos que el modelo implicaba un costo elevado en licencias, ya que AWS cobra la licencia de SQL Server por instancia.
Este artículo relata el proceso completo desde la evaluación de herramientas como SQL Data Sync, hasta la implementación final usando sqlpackage, incluyendo decisiones sobre consolidación de bases, resolución de problemas técnicos y ajustes manuales que surgieron en pleno proceso de migración.
Evaluación inicial: herramientas de migración
Al planear la migración, nuestra prioridad era encontrar una herramienta que nos permitiera migrar los datos de forma confiable, con bajo impacto en los entornos actuales y que nos ofreciera visibilidad sobre lo que estaba ocurriendo en cada paso.
Opción inicial: SQL Data Sync
Iniciamos el proceso evaluando SQL Data Sync, una herramienta integrada en Azure que permite sincronizar datos entre instancias de SQL Server, ya sea locales o en la nube.
Ventajas percibidas al inicio:
- Totalmente administrada desde el portal de Azure.
- Configuración relativamente simple para sincronizaciones periódicas.
- Capacidad de replicar datos de forma bidireccional.
Problemas detectados durante las pruebas e implementación:
- Errores de compatibilidad con tipos de datos avanzados como hierarchyid, geometry, sql_variant y columnas computadas.
- Problemas en la sincronización parcial: algunos datos no se transferían correctamente y los registros eran inconsistentes.
- Falta de visibilidad: no había logs detallados para analizar por qué fallaba una tabla específica.
- Complejidad de configuración para múltiples orígenes y destinos.
- Dependencia de Azure para todo el proceso, lo cual limitaba la autonomía durante la migración.
- Demoras de 8 a 15 horas en realizar syncs con datos reales.
Después de varias semanas de pruebas, descartamos esta opción. Aunque útil para sincronizaciones simples, no era adecuada para un proceso controlado de migración de múltiples bases con estructuras complejas y de gran tamaño como eran las productivas.
Cambio de estrategia: adopción de sqlpackage
Con solo dos semanas antes de la fecha límite de migración, necesitábamos una herramienta rápida, confiable y con capacidad de automatización. Aquí es donde entró sqlpackage, una utilidad de línea de comandos desarrollada por Microsoft para trabajar con archivos .dacpac.
¿Qué es un .dacpac?
Un archivo .dacpac contiene el esquema y, opcionalmente, los datos de una base de datos SQL Server. Es útil para exportar una base desde un origen y publicarla en un destino con una estructura idéntica.
Flujo de trabajo con sqlpackage
1. Extracción del .dacpac desde Azure SQL:
sqlpackage /Action:Extract \\
/TargetFile:”$TARGET_DIR/${DB_NAME_AZURE}.dacpac” \\
/DiagnosticsFile:”$TARGET_DIR/dacpac_extract.log” \\
/p:ExtractAllTableData=true \\
/p:VerifyExtraction=true \\
/p:IgnoreUserLoginMappings=false \\
/p:IgnorePermissions=false \\
/SourceConnectionString:”Server=${SQL_SERVER_AZURE},1433;Initial Catalog=${DB_NAME_AZURE};Encrypt=True;TrustServerCertificate=True;Connection Timeout=60;User ID=${SQL_USER_AZURE};Password=${SQL_PASS_AZURE}”
2. Publicación del .dacpac en AWS RDS:
sqlpackage /Action:Publish \\
/SourceFile:”$TARGET_DIR/${DB_NAME_AZURE}.dacpac” \\
/TargetConnectionString:”Server=${SQL_SERVER_AWS},1433;Initial Catalog=${DB_NAME_AWS};User ID=${SQL_USER_AWS};Password=${SQL_PASS_AWS};Encrypt=True;TrustServerCertificate=True;” \\
/p:AllowIncompatiblePlatform=true
Este enfoque nos dio control total sobre la migración, visibilidad detallada a través de logs, y la posibilidad de automatizar múltiples migraciones en paralelo.
Unificación de bases de datos: estrategia en DEV
Una de las decisiones más importantes fue consolidar las bases SQL Server del entorno de desarrollo. En Azure, cada microservicio tenía su propia base de datos. Al migrar a AWS, mantener ese modelo significaba pagar licencias por cada instancia, lo cual no era sostenible.
Solución: consolidación de múltiples bases en una sola instancia RDS
Beneficios obtenidos:
| Métrica | Antes (Azure) | Después (AWS – Consolidado) |
| Número de instancias SQL Server | 12 | 4 |
| Costo mensual aproximado | 11000 | 7000 |
Problemas enfrentados durante la migración
Aunque sqlpackage resolvió muchas limitaciones técnicas, no fue una solución perfecta.
Falta de migración automática de índices performantes
Durante la migración notamos la ausencia de elementos. Al revisar la estructura, descubrimos que algunos índices generados automáticamente por Azure (índices performantes) no se habían incluido en el .dacpac.
Solución aplicada:
- Se exportaron los índices críticos desde Azure mediante scripts customs.
- Se aplicaron los índices, creados por Azure,manualmente en AWS durante la ventana de mantenimiento.
Conclusión
La migración, en este proyecto, de SQL Server desde Azure a AWS no fue simplemente una cuestión técnica: fue una oportunidad para revisar y mejorar la arquitectura de datos y optimizar costos.
Gracias a una evaluación detallada, pruebas exhaustivas y un cambio de estrategia a tiempo, pudimos cumplir con los plazos y obtener un entorno sostenible y performante en AWS.
Próximos pasos
Enlaces útiles
¿Está tu empresa lista para migrar a AWS?
Migrar a la nube es una oportunidad para modernizar su infraestructura y preparar su negocio para el crecimiento. En Craftech, brindamos soporte integral a las empresas, combinando experiencia técnica con planificación estratégica.
👉 Contáctanos hoy para una revisión técnica o acompañamiento inicial en tu camino a la nube.
