El error más caro que hemos visto en una migración de warehouse no estaba en el código: estaba en el contrato.
El equipo que firmó no pidió el inventario de objetos, nadie presupuestó la validación de paridad y el doble running se improvisó la semana del corte. Tres meses después, los dashboards de negocio seguían tirando del sistema antiguo. Esa lección estructura esta guía.
Para contratar un equipo experto en una migración de datos a Snowflake o BigQuery: dimensiona roles por fase, compara consultora partner, freelance certificado y blended team, y exige evidencia verificable (certificaciones SnowPro o Google Professional Data Engineer, proyectos con sistema origen equivalente, plan de rollback y validación de paridad). El directorio de partners del proveedor no sustituye esa evaluación.
TL;DR. Una migración de datos a Snowflake o BigQuery no necesita un equipo plano: necesita roles core por fase (arquitecto, data engineers, validación) y capacidad flexible. Compara tres modelos: consultora partner, freelance certificado y blended team. Evalúa con criterios verificables: certificaciones oficiales, proyectos comparables, plan de rollback y paridad de datos como criterio de cierre.
¿Por qué migrar a Snowflake o BigQuery?
Se migra por tres motivos medibles, no por moda:
- El coste de licencias y hardware de plataformas legacy: Teradata, Oracle, SQL Server o un Redshift que se quedó corto.
- La elasticidad de separar cómputo y almacenamiento: el gasto fijo pasa a variable auditable.
- La base analítica que la IA necesita debajo para salir del piloto.
El tercer motivo es el que menos se audita y el que más pesa. Según BCG (enero 2025), el 75% de las empresas probó IA y solo el 25% vio resultados: ese es el implementation gap. La migración del warehouse es la infraestructura previa, y contratar mal al equipo que la ejecuta es la primera causa evitable de ese gap. Si tu organización apunta a dominios distribuidos, contrasta antes el enfoque de data mesh en empresas: cambia el equipo que necesitas.
Práctica recomendada: escribe el caso de uso de IA que justifica la migración antes de pedir la primera propuesta.
¿Snowflake o BigQuery? Qué implica cada destino para el equipo
En términos de equipo, Snowflake vs BigQuery es una pregunta sobre perfiles. Snowflake exige administrar warehouses virtuales y gobernar el consumo de créditos. BigQuery exige dominar el modelo serverless de Google Cloud y el coste por consulta. La plataforma se elige por arquitectura; el equipo cambia con el destino.
| Dimensión | Snowflake | BigQuery |
|---|---|---|
| Perfil núcleo | Data engineer con administración de warehouses virtuales y FinOps de créditos | Data engineer con experiencia en Google Cloud y control de coste por consulta |
| Certificación verificable | SnowPro Core y SnowPro Advanced | Google Professional Data Engineer |
| Conversión asistida | SnowConvert (esquemas y SQL) | BigQuery Migration Service (traducción de SQL) |
Las herramientas de migración de datos automatizan la traducción de esquemas y consultas. No migran la lógica de orquestación ni validan resultados. Eso es trabajo de personas. Si la decisión de plataforma sigue abierta, el análisis de fondo está en nuestra comparativa enterprise sobre cómo decidir entre Fabric y Azure Databricks.
¿Qué equipo necesita una migración de datos a Snowflake o BigQuery?
Una migración de datos a Snowflake o BigQuery se cubre con cuatro roles core (arquitecto de datos, dos data engineers y un perfil de calidad de datos que firme la paridad) más capacidad flexible que entra y sale por fase. El equipo plano de principio a fin encarece sin acelerar.
| Fase | Rol core al mando | Capacidad flexible | Riesgo si se omite |
|---|---|---|---|
| Assessment e inventario | Arquitecto de datos | Especialista en el sistema origen | Estimación a ciegas |
| Rebuild de pipelines | Data engineers | Analytics engineer para el modelado | Deuda técnica heredada del origen |
| Validación de paridad | Perfil de calidad de datos | Apoyo de negocio para casos de prueba | Cierre sin criterio objetivo |
| Cutover con doble running | Arquitecto y data engineers | Soporte puntual del proveedor origen | Downtime que negocio no aceptó |
| FinOps post-migración | Data engineer asignado | Especialista FinOps puntual | Sobrecoste de cómputo silencioso |
Core no significa plantilla: significa continuidad desde el assessment hasta el apagado del origen.
¿Consultora partner, marketplace freelance o blended team?
Ningún modelo gana en todo. La decisión se toma sobre cinco variables: velocidad de arranque, lock-in, retención del conocimiento, conflicto de interés y estructura de coste. Esta tabla las compara sin favorito.
| Criterio | Consultora partner | Marketplace freelance | Blended team |
|---|---|---|---|
| Velocidad de arranque | Alta: equipo empaquetado | Media: seleccionas perfil a perfil | Media: exige diseñar el equipo mixto |
| Lock-in | Alto si el código queda en sus repositorios | Bajo, con contratos por proyecto | Bajo: el ownership queda en tu equipo |
| Retención del conocimiento | Se va con el equipo al cerrar | Depende de la documentación pactada | Alta: tus ingenieros operan desde el día uno |
| Conflicto de interés | Posible: incentivos de revenue del vendor | Bajo | Bajo |
| Estructura de coste | Tarifa empaquetada con margen sobre cada hora | Tarifa por perfil | Tarifa por perfil más coordinación interna |
Un blended team de migración de datos mezcla tus ingenieros con especialistas externos certificados que transfieren código y contexto antes de salir. Funciona si existe un interlocutor interno con horas reales dedicadas; sin esa figura, degenera en un proyecto externo con otro nombre. Es la opción cuando quieres que el conocimiento se quede en tu casa.
La lectura honesta del otro lado: si necesitas arrancar en dos semanas y tu equipo no puede ceder horas, la consultora partner es razonable; si el alcance es acotado, contratar un consultor Snowflake freelance certificado cubre el pico sin montar estructura de más. Paga el sobrecoste sabiendo qué compras. La página de soluciones de análisis de datos detalla los perfiles habituales de estos equipos.
¿Cómo evaluar a un proveedor de migración de datos?
Con un checklist verificable que aplique igual a una consultora partner, a un freelance o a esta misma plataforma: certificaciones oficiales vigentes, proyectos comparables con un sistema origen equivalente al tuyo, ownership de código e IaC, plan de rollback escrito y paridad de datos como definición de done.
| Criterio | Cómo verificarlo |
|---|---|
| Certificación oficial | ID de credencial vigente en las certificaciones SnowPro o en Google Professional Data Engineer |
| Proyectos comparables | Referencias contrastables con tu mismo sistema origen |
| Ownership de código e IaC | Repositorio entregado a tu organización desde el primer sprint |
| Plan de rollback | Documento con criterios de activación, no una intención verbal |
| Paridad de datos | Partida propia en la propuesta, con umbrales de aceptación y casos de prueba |
Añade un criterio que casi nadie escribe: el conflicto de interés. La propia página de partners de Snowflake documenta incentivos de revenue y programas de co-sell para su red de implementadores. Esto no descalifica a nadie; explica desde dónde te recomiendan. Pregunta a cada proveedor cuánto factura del vendor que te propone y decide con esa respuesta delante.
En nuestra experiencia validando perfiles de datos, el filtro que más candidatos descarta no es el examen de certificación: es pedir el código del último proyecto y comprobar quién lo escribió. La misma lógica que aplicamos al talento certificado en skills IA vale para cualquier proveedor.
¿Qué red flags descalifican una propuesta de migración?
Cuatro señales descartan una propuesta sin más análisis: ausencia de discovery del inventario de objetos, presupuesto sin partida de validación de paridad, ausencia de estrategia de doble running y una estimación cerrada antes de ver tu volumetría.
- Sin discovery del inventario: nadie dimensiona lo que no ha contado. Los esquemas incompatibles y las dependencias ocultas viven ahí.
- Sin partida de validación de paridad: la integridad de los datos pasa a ser tu problema, no el del proveedor.
- Sin doble running: el cutover se convierte en un salto sin red, con dashboards apagados que negocio nunca aceptó.
- Estimación cerrada sin volumetría: o el precio viene inflado para cubrirse, o viene bajo para entrar y renegociar después.
Quinta señal, más sutil: prometer que SnowConvert o BigQuery Migration Service automatizan la migración entera. Convierten esquemas y consultas; no reconstruyen la orquestación ni las herramientas para DataOps que sostendrán los pipelines tras el corte. En una migración que acompañamos, las vistas materializadas sin inventariar duplicaron la fase de rebuild. Desde entonces no aceptamos estimación sin inventario. Ni propia ni de terceros.
¿Cuánto cuesta un equipo de migración de datos en España?
Depende de tres variables: el inventario de objetos, el modelo de contratación y la duración del doble running. Para presupuestar tarifas freelance, parte del salario base del rol y multiplícalo por 1,5-1,8: es el ajuste que cubre RETA, IRPF y la no ocupación entre proyectos.
Las horquillas salariales de referencia se consultan, no se estiman: Manfred (Guía Salarial 2026), Glassdoor, Malt, Talent.com e Indeed. Compara medianas, no medias, y descarta cualquier fuente que no publique el tamaño de su muestra. Las tarifas en dólares de marketplaces internacionales, trasladadas a España sin ajuste fiscal, distorsionan la comparación.
La tarifa-hora es la variable equivocada para decidir. El coste que decide es el total del proyecto y el coste de contratar mal: un equipo barato que entrega sin paridad validada obliga a repetir la migración pagando dos veces. Práctica recomendada: presupuesta el proyecto completo con la partida de validación dentro, nunca la tarifa-hora aislada.
¿Cuánto dura una migración a Snowflake o BigQuery?
Desconfía de cualquier plazo dado antes de contar objetos. La duración se estima multiplicando inventario por complejidad y por estrategia de cutover; ese cálculo exige assessment previo. Un plan de migración de datos serio no promete una fecha: entrega un desglose por partidas que puedas auditar.
| Partida | Qué debe explicitar la propuesta |
|---|---|
| Inventario de objetos | Conteo por tipo: tablas, vistas, procedimientos, jobs y dependencias |
| Conversión de esquemas y SQL | Qué porcentaje asume la herramienta y qué queda en manual |
| Rebuild de pipelines | Lista de cargas afectadas y orden de migración |
| Validación de paridad | Umbrales de aceptación y quién firma el cierre |
| Cutover y doble running | Duración de la convivencia y criterios de apagado del origen |
| Estabilización y FinOps | Ventana de ajuste de costes tras el corte |
Si una partida falta, la pregunta no es cuánto dura. Es quién pagará la diferencia.
RGPD y residencia de datos: el criterio eliminatorio para Europa
Snowflake y Google Cloud ofrecen regiones de procesamiento en la UE, pero eso no resuelve el RGPD por sí solo. El criterio eliminatorio es contractual: dónde residen los datos, qué transferencias a terceros países existen y qué subencargados intervienen en el tratamiento. El texto canónico es el Reglamento (UE) 2016/679.
El régimen sancionador llega hasta 20 millones de euros o el 4% de la facturación anual global, según el artículo 83.5 del propio reglamento. Para un comité de dirección, esa horquilla convierte la residencia y el gobierno del dato en criterio de descarte, no en preferencia.
Tres preguntas de RGPD antes de firmar
- ¿En qué región física de la UE se procesan y almacenan los datos, y quién puede cambiarla?
- ¿Existen transferencias a terceros países y bajo qué mecanismo del capítulo V del RGPD se amparan?
- ¿Qué subencargados intervienen en el tratamiento y cómo se notifica su sustitución?
Fuente: Reglamento (UE) 2016/679, EUR-Lex
Si el proveedor no sabe responderlas, no es tu proveedor: la responsabilidad del tratamiento no se subcontrata. Para cláusulas de transferencias internacionales, valida con un experto legal humano antes de firmar.
Preguntas frecuentes sobre la migración de datos a Snowflake o BigQuery
- ¿Cómo hacer una migración de datos?
Una migración de datos se ejecuta en cinco fases: assessment del inventario de objetos, conversión de esquemas y SQL, rebuild de los pipelines de carga, validación de paridad entre origen y destino, y cutover con doble running. La fase que define el éxito es la validación de paridad: sin ella no existe criterio objetivo de cierre.
- ¿Cómo se transfieren 100 GB de datos a Snowflake?
Para ese volumen, el mecanismo habitual es la carga por lotes desde un almacenamiento intermedio en la nube, con compresión y particionado previos. Más útil que memorizar el procedimiento: pedir al equipo que explique su estrategia de particionado y de verificación de cargas. Quien responde con criterio propio ha migrado antes.
- ¿Cómo importar datos de SQL a Snowflake?
La importación desde una base SQL es una migración de bases de datos en miniatura: exportar a formato plano o columnar, cargar en un área intermedia y reconstruir esquemas y tipos en destino. La conversión automática cubre la sintaxis; los tipos y los procedimientos almacenados exigen revisión humana. La referencia es la documentación oficial de Snowflake, no tutoriales de terceros.
- ¿Por qué Snowflake es mejor que SQL?
La comparación está mal planteada: SQL es un lenguaje de consulta y Snowflake es un warehouse analítico que lo utiliza. La pregunta útil es warehouse analítico frente a base de datos transaccional. El primero separa cómputo y almacenamiento para consultas masivas; la segunda gestiona transacciones concurrentes. No compiten: una alimenta, el otro analiza.
- ¿Puedo aprender Snowflake en 2 días?
Los fundamentos de la interfaz, sí. El criterio para migrar producción, no. Por eso al contratar pesan más una certificación oficial como SnowPro y proyectos previos con tu mismo sistema origen que cualquier curso exprés. Un fin de semana da vocabulario; no da cicatrices de cutover ni criterio de validación de paridad.
- ¿Dónde contratar consultoría para migración de datos?
Puedes acudir al directorio de partners del vendor, a un marketplace freelance o a una infraestructura de contratación que certifique skills y proyectos previos. Compara las propuestas con el mismo checklist: inventario, paridad, rollback y doble running. En Shakers puedes solicitar consultoría para migración de datos con perfiles validados por proyecto.
- ¿Dónde contratar expertos en Snowflake o BigQuery?
Depende del destino elegido. Para Snowflake puedes contratar expertos en Snowflake verificados por certificación y proyecto; para Google Cloud, expertos en BigQuery. En ambos casos, exige experiencia con un sistema origen equivalente al tuyo y paridad validada como criterio de cierre.
La guía cabe en una frase: exige inventario, paridad y rollback antes de firmar, y elige el modelo que deje el conocimiento en tu casa. Es la vara de medir de cualquier infraestructura de contratación en la era de la IA: que sus criterios funcionen aunque la respuesta no le favorezca.