SQL Server a Snowflake sin parar el reporting

SQL Server ha sido durante años la columna vertebral analítica de muchas empresas en España. Funciona, es conocido y hay profesionales que lo dominan. Pero llega un punto en el que el modelo on-premise o la licencia Enterprise empiezan a pesar: los costes de escalar son altos, la elasticidad es nula y mantener el rendimiento con volúmenes crecientes requiere cada vez más esfuerzo.

Snowflake resuelve algunos de esos problemas con un modelo cloud-native que separa almacenamiento y computación, escala bajo demanda y elimina la gestión de infraestructura. Pero migrar no es simplemente volcar datos de un sitio a otro. Si se hace mal, puedes quedarte semanas con reporting degradado, datos que no cuadran y un equipo que pierde la confianza en los números.

Cuándo tiene sentido migrar de SQL Server a Snowflake

No todas las empresas necesitan migrar. SQL Server sigue siendo una opción sólida para muchos escenarios. Pero hay señales claras de que Snowflake puede aportar más valor.

• El volumen de datos analíticos crece y el rendimiento de las consultas se degrada, pero escalar verticalmente ya no es viable o es demasiado caro.
• Necesitas concurrencia: varios equipos ejecutan consultas pesadas a la vez y se pisan unos a otros. Snowflake permite warehouses virtuales independientes.
• Quieres consolidar datos de múltiples fuentes en un único warehouse cloud accesible desde cualquier herramienta de BI.
• Estás pagando licencias SQL Server Enterprise que no aprovechas al 100%, o el coste de mantenimiento de la infraestructura on-premise es desproporcionado.
• Tu equipo ya trabaja con herramientas del ecosistema moderno (dbt, Fivetran, Airbyte) que se integran de forma nativa con Snowflake.

Checklist previo a la migración

Antes de mover un solo dato, necesitas tener claros estos puntos. Saltarse esta fase es la causa principal de migraciones que se alargan o fallan.

1. 1Inventario de objetos: tablas, vistas, procedimientos almacenados, funciones, jobs programados, índices y permisos. Documenta qué hay en SQL Server y quién lo usa.
2. 2Mapa de dependencias de reporting: qué informes, dashboards y procesos dependen de cada tabla o vista. Esto define el orden de migración.
3. 3Perfil de carga: volumen de datos por tabla, frecuencia de actualización, patrón de consultas (cuántas, cuándo, cuánto tardan). Snowflake cobra por computación, así que necesitas estimar el consumo de créditos.
4. 4Análisis de T-SQL: identifica procedimientos almacenados y funciones con sintaxis específica de SQL Server (MERGE con OUTPUT, funciones de ventana no estándar, CTEs recursivos complejos). Estas piezas necesitan adaptación.
5. 5Estrategia de ingesta: define cómo llegarán los datos a Snowflake. Opciones habituales: Fivetran, Airbyte, Azure Data Factory, scripts personalizados con Python, o Snowpipe para cargas en streaming.
6. 6Entorno de pruebas: monta un entorno Snowflake de desarrollo antes de tocar producción. No cuesta mucho (pagas solo lo que usas) y permite validar sin riesgo.

Fases de migración: ejecución en paralelo y cutover controlado

El enfoque que reduce el riesgo es ejecutar ambos sistemas en paralelo durante un periodo de validación. Así, el reporting sigue funcionando sobre SQL Server mientras preparas y validas Snowflake.

Fase 1: Migración del esquema y carga histórica

Crea las tablas en Snowflake replicando la estructura de SQL Server. Snowflake no tiene índices en el sentido tradicional (usa micro-particiones y clustering automático), así que no se migran índices directamente. Carga los datos históricos usando COPY INTO desde ficheros en un stage (S3, Azure Blob o GCS) o mediante herramientas de ingesta. Para tablas grandes, la carga en formato Parquet suele ser la opción más eficiente.

En esta fase, SQL Server sigue siendo el sistema de producción. Nadie nota nada.

Fase 2: Sincronización continua

Configura un proceso de sincronización que mantenga Snowflake actualizado con los cambios que ocurren en SQL Server. Puede ser una carga incremental diaria, cada pocas horas o en near-real-time con CDC (Change Data Capture). SQL Server tiene CDC nativo que facilita capturar solo los cambios. Herramientas como Fivetran o Airbyte gestionan esto sin desarrollo propio.

Fase 3: Adaptación de la lógica de transformación

Los procedimientos almacenados, vistas materializadas y lógica T-SQL necesitan adaptarse. Este es el paso que más tiempo consume. La recomendación: en vez de traducir procedimientos almacenados literalmente, evalúa si la lógica puede trasladarse a dbt (data build tool). dbt permite definir transformaciones como SQL versionado y testeable, lo que mejora la mantenibilidad respecto a procedimientos almacenados monolíticos.

Fase 4: Ejecución en paralelo y validación

Esta es la fase crítica. Durante 2-4 semanas, ambos sistemas funcionan simultáneamente. Los informes de producción siguen apuntando a SQL Server, pero generas los mismos informes desde Snowflake y comparas resultados.

• Validación de recuento de filas por tabla: diferencias superiores al 0,01% deben investigarse.
• Validación de agregados: sumas, medias y conteos de los KPIs principales deben coincidir exactamente.
• Validación de rendimiento: las consultas de reporting deben ejecutarse en tiempos iguales o mejores.
• Validación por parte de negocio: el equipo que consume los datos confirma que los números tienen sentido.

Esto es exactamente el hábito que aprendí como data engineer antes de fundar MERIDIAN: una migración o una transformación no se da por buena solo porque se ejecuta sin errores, hay que comprobar volumen, consistencia y valores concretos antes de confiar en el resultado. Saltarse esta validación para ir más rápido es la forma más habitual de acabar con un Snowflake que 'funciona' pero con cifras que nadie ha verificado de verdad.

Fase 5: Cutover

Cuando la validación es satisfactoria, redirige los informes y dashboards a Snowflake. Conviene hacerlo por bloques: primero los informes menos críticos, después los operativos y por último los financieros. Mantén SQL Server accesible durante 2-4 semanas más como respaldo.

Mitigación de riesgos durante la migración

Toda migración tiene riesgos. La diferencia entre un proyecto que sale bien y uno que se convierte en un problema está en cómo los anticipas.

Qué conviene mantener en SQL Server

No todo tiene que moverse a Snowflake. Hay cargas de trabajo donde SQL Server sigue siendo la mejor opción, y forzar la migración genera más problemas que beneficios.

• Bases de datos transaccionales (OLTP): aplicaciones que necesitan escrituras rápidas, transacciones ACID y baja latencia en lecturas puntuales.
• Aplicaciones legacy con dependencias fuertes: sistemas que usan funciones específicas de SQL Server (Service Broker, Linked Servers, SSRS con suscripciones complejas).
• Volúmenes pequeños sin necesidad de escala: si la base de datos analítica tiene pocas tablas, poco volumen y los informes van bien, migrar genera coste sin beneficio claro.
• Entornos regulados con requisitos de localización estrictos: si necesitas que los datos estén en un servidor físico concreto, el modelo cloud puede no encajar (aunque Snowflake permite elegir región).

El enfoque híbrido, con SQL Server para lo transaccional y Snowflake para lo analítico, es el patrón más habitual en empresas que migran por fases. En nuestra página de plataforma de datos detallamos cómo abordamos este tipo de arquitecturas.

Comparativa de costes: SQL Server vs Snowflake

El coste es uno de los factores clave y uno de los más mal estimados. SQL Server tiene un modelo de licencia (o pago por uso en Azure SQL). Snowflake tiene un modelo de consumo por créditos (computación) más almacenamiento.

Para empresas con cargas analíticas intermitentes (consultas unas horas al día), Snowflake suele ser más económico porque no pagas cuando no usas. Para cargas continuas 24/7, el coste de créditos puede ser comparable o superior a una licencia SQL Server. El cálculo hay que hacerlo con tu perfil de uso real, no con estimaciones genéricas.

La migración como oportunidad para mejorar la arquitectura

Una migración no debería ser solo un cambio de motor de base de datos. Es una oportunidad para revisar la arquitectura de datos completa: eliminar tablas que nadie usa, reorganizar los modelos de datos, implementar una capa de transformación con dbt, documentar el linaje y establecer pruebas de calidad automatizadas.

Las empresas que aprovechan la migración para hacer limpieza y mejorar procesos suelen obtener un retorno mucho mayor que las que simplemente replican lo que tenían en SQL Server dentro de Snowflake.

Checklist de cierre de migración

Antes de dar la migración por completada, asegúrate de cubrir estos puntos.

• Todos los informes y dashboards apuntan a Snowflake y los datos cuadran.
• Los procesos de ingesta incrementales funcionan de forma estable desde hace al menos 2 semanas.
• Los usuarios de negocio han validado los KPIs principales.
• Los resource monitors de Snowflake están configurados para evitar sorpresas en la factura.
• La documentación de la nueva arquitectura está actualizada.
• El equipo sabe cómo escalar warehouses, pausarlos y monitorizar el consumo.
• SQL Server se mantiene accesible como respaldo durante el periodo de gracia definido.

Si estás valorando una migración de SQL Server a Snowflake y quieres hacerlo sin interrumpir la operativa, podemos ayudarte a planificarlo. Empezamos siempre por entender tu situación actual antes de proponer nada.

Para más información, puedes consultar la reviews de Gartner para plataformas cloud de datos.

Preguntas frecuentes

¿Se pueden migrar los SSIS packages a Snowflake?

No directamente. SSIS (SQL Server Integration Services) es una herramienta de ETL propia de Microsoft. En Snowflake, la capa de ingesta se gestiona con herramientas como Fivetran, Airbyte o scripts de Snowpipe. La lógica de transformación que estaba en SSIS suele trasladarse a dbt o a Snowflake Tasks. Requiere reescritura, pero el resultado suele ser más mantenible.

¿Power BI funciona bien con Snowflake?

Sí. Power BI tiene un conector nativo para Snowflake que soporta DirectQuery e Import Mode. El rendimiento es bueno, aunque conviene ajustar el tamaño del warehouse de Snowflake según la frecuencia y complejidad de las consultas que lanza Power BI. Muchas empresas migran su backend a Snowflake y mantienen Power BI como capa de visualización sin problemas.