Casi todas las migraciones a Azure con SQL Server llegan a esta bifurcación, y el giro equivocado sale caro de una forma concreta: descubres la función que falta después de migrar, en producción, con una fecha detrás.
La decisión va sobre todo de superficie — cuánto de SQL Server usa realmente tu aplicación.
Las tres opciones
SQL Database (base única o pool elástico) — la oferta PaaS. Totalmente gestionada, parcheado automático, alta disponibilidad integrada, niveles serverless e hyperscale. No tiene SQL Agent, consultas entre bases dentro del servidor, CLR, Service Broker, servidores vinculados ni varias otras funciones de nivel instancia.
SQL Managed Instance — compatibilidad casi completa con una instancia de SQL Server como servicio gestionado. SQL Agent, consultas entre bases, Service Broker, CLR y servidores vinculados funcionan. Se despliega dentro de tu VNet, admite copia y restauración nativas desde una URL, y el Database Migration Service puede moverte con cambios mínimos. Cuesta más que SQL Database y tarda bastante más en desplegarse o escalar.
SQL Server en una VM — lo gestionas todo, lo tienes todo, incluidas funciones que los productos gestionados no exponen y la posibilidad de ejecutar una versión que Microsoft ya no soporta en PaaS. También: lo parcheas tú, configuras Always On tú y las copias son tuyas.
El árbol de decisión
Empieza en SQL Database. Si la aplicación funciona ahí, tómalo: es lo más barato en la gama baja, la superficie operativa es la menor y los niveles serverless hacen que una base de staging no cueste casi nada cuando nadie la usa.
Pasa a Managed Instance si te topas con alguno de estos: trabajos de SQL Agent que no puedes sustituir por un planificador externo, consultas entre bases, Service Broker, ensamblados CLR, servidores vinculados, o una aplicación de terceros con una configuración soportada por el proveedor que exige acceso de nivel instancia. Managed Instance existe precisamente para el traslado tal cual de un SQL Server real, y para ese trabajo es la herramienta correcta.
Ve a una VM solo si necesitas una función que ninguno ofrece (FileStream, ciertas topologías de replicación, una versión no soportada), tienes un acuerdo de licencias que lo abarata drásticamente, o un proveedor no soporta otra cosa. Trátalo como la excepción que es — una VM significa que el parcheado y el failover son tuyos, y casi todos los equipos subestiman lo que eso cuesta en tres años.
Ejecuta el Data Migration Assistant contra tu base actual antes de nada. Informa exactamente de qué funciones bloquean qué destino, lo que convierte el debate en una lista.
Coste, y las palancas que se pasan por alto
- El Beneficio Híbrido de Azure se aplica a las tres y es el mayor descuento individual para licencias de SQL Server Enterprise con Software Assurance. Comprueba tus derechos antes de cotizar nada, como en el artículo de la factura de Azure.
- El nivel serverless de SQL Database es de verdad bueno para desarrollo, herramientas internas y cualquier cosa con periodos tranquilos — se pausa y dejas de pagar cómputo.
- Los pools elásticos cuando tienes muchas bases pequeñas con picos no correlacionados. Es el caso del SaaS multiinquilino y el ahorro es sustancial.
- Reservas sobre el cómputo de las bases en modelo vCore, una vez el tamaño es estable.
- Hyperscale para bases muy grandes, donde la arquitectura de almacenamiento cambia por completo la historia de copia y restauración — restauraciones casi instantáneas con independencia del tamaño.
La migración
Para Managed Instance, el camino que deja la parada corta es el Database Migration Service en modo online: restaura tus copias y después replica cambios hasta el corte. La parada es el corte en sí, típicamente minutos.
Para SQL Database, replicación transaccional o DMS en modo online, con la misma forma.
En cualquier caso, tres cosas deciden si sale bien:
- Ejecuta el Data Migration Assistant pronto y arregla los bloqueos antes del fin de semana de migración, no durante.
- Prueba las consultas más lentas contra el destino antes del corte. Las diferencias de nivel de compatibilidad y de estimación de cardinalidad producen regresiones, y se encuentran ejecutando la consulta, no leyendo documentación.
- Deja el origen funcionando en solo lectura una semana. El plan de vuelta atrás es reapuntar la cadena de conexión, y solo existe si el origen sigue ahí.
Después de aterrizar
Activa la auditoría hacia un workspace de Log Analytics, Microsoft Defender for SQL, endpoints privados con el acceso de red público desactivado y Transparent Data Encryption con clave gestionada por el cliente si tu marco de cumplimiento lo exige. Comprueba que la retención de copias automáticas coincide de verdad con lo que prometiste al negocio — el valor por defecto es más corto de lo que casi todos suponen, y la retención a largo plazo es un ajuste aparte.
Recorremos esta decisión en la fase de migración de los proyectos cloud, normalmente con el informe del Data Migration Assistant sobre la mesa para que la conversación sea de hechos y no de preferencias.
Qué hacer esta semana
Ejecuta el Data Migration Assistant contra tu base de datos de producción con SQL Database como destino. La lista de bloqueos que produce responde a toda la pregunta en unos veinte minutos, y es el documento que hay que llevar a la discusión de arquitectura.