English
El 14 de julio de 2026 terminó el soporte extendido de SQL Server 2016. Para muchos bancos, aseguradoras y grandes empresas de América Latina, eso abrió una conversación que venía postergándose: pagar actualizaciones de seguridad extendidas para sostener la plataforma actual o usar el vencimiento para modernizarla. Snowflake aparece con frecuencia en esa conversación, y con buenos motivos. Pero la calidad de una migración a Snowflake se define antes de mover el primer dato, en un puñado de decisiones que ninguna herramienta toma por la organización.
La conversión técnica ya no es el cuello de botella. El AIM Agent for Data Warehouses de Snowflake convierte código, despliega objetos por olas y valida los datos migrados desde SQL Server, Oracle, Teradata, Redshift y PostgreSQL. Lo que sigue en manos del CTO, del Chief Data Officer o del Chief Data & AI Officer es definir qué problema resuelve la migración, qué se traslada, dónde viven los datos, quién certifica los resultados y cómo se controla el gasto.
Qué suele disparar una migración a Snowflake
En empresas grandes, la migración rara vez nace de una evaluación abstracta de plataformas. Suele llegar con un disparador concreto: el fin de soporte de una base de datos, la renovación de licencias o de hardware de Teradata u Oracle Exadata, un data lake en Hadoop cada vez más caro de mantener y más difícil de sostener con el talento disponible, la integración de una empresa adquirida o una iniciativa de IA frenada porque los datos están fragmentados entre filiales.
El disparador importa porque condiciona el caso de negocio. Una migración motivada por un vencimiento tiene un plazo impuesto y tiende a priorizar el traslado rápido. Una migración motivada por IA necesita, en cambio, rediseñar definiciones y gobierno. Confundir una con otra produce proyectos que cumplen el plazo y no resuelven el problema que justificó la inversión.
El caso de negocio también tiene que comparar modelos económicos distintos. Las licencias y el hardware on-premise son costos fijos y conocidos. Snowflake cobra por consumo. La comparación honesta incluye el período en que ambos sistemas conviven, la capacitación de los equipos y el costo de retirar lo que ya no se usa, además del precio de la plataforma.
Las cinco decisiones que definen el proyecto
1. Migrar todo o convivir
No toda la arquitectura actual tiene que desaparecer. Algunas organizaciones llegan con parte de su analítica o de su ingeniería de datos en Databricks, en un lakehouse propio o en otra nube. Con tablas Apache Iceberg, Snowflake puede leer y escribir sobre formatos abiertos que otros motores también utilizan, lo que habilita esquemas de convivencia en lugar de un reemplazo total.
La decisión depende de dónde está el valor. Consolidar todo en una plataforma simplifica el gobierno, el soporte y la negociación comercial. Convivir preserva inversiones recientes y capacidades que funcionan, pero exige definir con precisión qué sistema es autoritativo para cada dominio de datos. Lo que conviene evitar es la convivencia por omisión, donde dos plataformas calculan las mismas métricas porque nadie decidió cuál debía hacerlo.
2. Qué se retira, qué se traslada y qué se rediseña
Un data warehouse con quince o veinte años de historia acumula tablas sin consumidores, reportes que nadie abre y procesos nocturnos que existen para compensar limitaciones de rendimiento que en Snowflake ya no aplican. Las herramientas de migración convierten todo eso con la misma fidelidad que lo valioso.
Por eso la primera etapa del proyecto debería ser un inventario cruzado con datos de uso real, que clasifique cada componente en tres grupos. Lo estable y bien modelado se traslada. Lo que funciona mal por diseño, como la lógica de negocio escondida en procedimientos almacenados o los cálculos duplicados entre áreas, se rediseña. El resto se retira. Cada objeto que se retira es un objeto menos para convertir, validar, gobernar y pagar.
3. Dónde viven los datos y quién puede acceder a ellos
Para una entidad financiera, esta decisión suele ser la más sensible. Snowflake tiene hoy dos regiones en América Latina: AWS en São Paulo y Azure en México Central. Un banco con operación en Argentina, Colombia o Chile debe evaluar si su regulación y sus políticas internas le permiten alojar datos en otro país, qué información puede replicarse entre regiones y cómo documentar esa decisión ante auditores y reguladores.
El acceso plantea preguntas equivalentes dentro de la organización. En un grupo con filiales en varios países, no todos los equipos deberían ver los mismos datos, y los entornos de desarrollo no deberían contener información personal real. Snowflake ofrece controles por rol y enmascaramiento dinámico de columnas, pero la política que esos controles aplican tiene que diseñarse con seguridad, compliance y los dueños de cada dominio antes de la migración. Agregarla después suele significar que alguien ya tuvo acceso a información que no correspondía.
4. Quién certifica que los números son correctos
La validación técnica compara conteos, sumas y esquemas entre el sistema anterior y Snowflake, y es donde la automatización aporta más. La validación de negocio responde otra pregunta: si el reporte regulatorio, el cálculo de mora o la posición consolidada de un cliente dan el mismo resultado que antes, o si las diferencias están explicadas y aprobadas.
Esa segunda validación necesita dueños con nombre y apellido, criterios de aceptación definidos antes de empezar y un período de convivencia en el que ambos sistemas operan en paralelo. En servicios financieros, donde un número distinto en un reporte al regulador tiene consecuencias, conviene planificar la puesta en producción por dominios, con un plan de reversión para cada ola. Empezar por un dominio acotado y de alto valor, como riesgo o finanzas, permite ajustar el método antes de escalarlo.
5. Cómo se controla el gasto por consumo
El modelo por consumo le da flexibilidad a la organización y le traslada una responsabilidad nueva. Un warehouse sobredimensionado, una carga que no se suspende o un equipo que ejecuta consultas ineficientes empiezan a costar desde el primer día.
El control del gasto se diseña junto con la arquitectura: warehouses separados por tipo de carga, suspensión automática, monitores de recursos que limitan el consumo de créditos y etiquetas que permiten asignar costos por área. Para el CFO, la previsibilidad no depende tanto del precio unitario como de que exista un mecanismo de gobierno del consumo con responsables claros.
Por qué estas decisiones definen la capacidad de hacer IA
En servicios financieros, la migración suele estar conectada con casos que van más allá del reporting: modelos de riesgo y scoring crediticio, detección de fraude, prevención de lavado, vista integral del cliente entre productos y filiales, o intercambio seguro de datos con fintechs y socios comerciales.
Todos dependen de las decisiones anteriores. Los agentes de IA de Snowflake generan consultas a partir de vistas semánticas que definen métricas y dimensiones de negocio, de modo que una definición ambigua de cliente activo o de cartera vencida se convierte en una respuesta incorrecta en lenguaje natural. Los controles de acceso determinan qué puede consultar un agente en nombre de cada usuario. Y un entorno sin gobierno del consumo vuelve impredecible el costo de las cargas de IA, que suelen ser intensivas.
Por eso la preparación para IA se resuelve dentro de la migración, en cada una de las decisiones anteriores.
Un ejemplo de consolidación multi-país
La migración de Samsonite LATAM ilustra varias de estas decisiones en un entorno de siete mercados, ocho marcas, más de 350 tiendas físicas y 20 tiendas online. La información estaba distribuida entre Shopify, Google Analytics 4, Oracle OMS, LINX, Retail Pro Prism, JasperX PIM y Gorgias, cada uno con su propio modelo de datos.
Exomindset diseñó una arquitectura en capas de landing, trusted y semántica, con ingesta orquestada en Apache Airflow sobre AWS MWAA, transformaciones organizadas en ocho proyectos de dbt y más de 15 pipelines automatizados con alertas de falla. El gobierno formó parte del diseño desde el inicio, con enmascaramiento de datos en desarrollo, políticas de acceso dinámicas por rol en producción y un inventario de columnas sensibles. En unos cuatro meses, desde el diseño hasta la implementación, la compañía pasó a contar con una vista unificada de los siete mercados y datos transaccionales actualizados a diario para sus campañas.
Cómo trabaja Exomindset en migraciones a Snowflake
Exomindset es Snowflake Select Partner, Matillion Silver Partner y AWS Partner. Esa combinación permite cubrir la plataforma, la capa de integración y la nube sobre la que corre, algo relevante cuando las fuentes incluyen sistemas legacy, aplicaciones operativas y servicios SaaS de distintos países.
La compañía cuenta con certificación ISO 9001 e ISO/IEC 42001, la norma internacional de sistemas de gestión de inteligencia artificial. Para una entidad regulada que migra con el objetivo de desarrollar IA sobre sus datos, esa segunda certificación aporta un marco auditable sobre cómo se diseñan, controlan y supervisan los sistemas de IA. Exomindset también desarrolla agentes de IA, sistemas de conocimiento empresarial y modelos predictivos, de modo que la plataforma migrada puede extenderse a casos de IA con el mismo partner. Cada proyecto se ejecuta junto con los equipos internos, documentando las decisiones y transfiriendo el conocimiento necesario para operar y ampliar la plataforma.
Decidir antes de migrar
La automatización redujo el costo y el riesgo de la parte mecánica de una migración a Snowflake. Eso vuelve más visible lo que siempre definió su resultado: por qué se migra, qué se deja atrás, bajo qué reglas se alojan y consultan los datos, quién responde por los números y cómo se gobierna el consumo.
Para un CTO o un Chief Data Officer, esas decisiones son las que determinan si la inversión termina en una plataforma que el negocio usa con confianza y que soporta nuevos casos de IA, o en una réplica moderna de los problemas anteriores. Si tu organización está evaluando una migración a Snowflake, o revisando el alcance de una ya en curso, podemos ayudarte a ordenar esas decisiones antes de empezar.