Migrar datos a la nube: governance antes de migrar

La razon principal es que migrar datos sin conocerlos amplifica los problemas existentes. Si no sabes que tablas estan obsoletas, migraras tablas obsoletas. Si no sabes que campos contienen PII, expondras PII en un entorno cloud potencialmente mas accesible. Si no conoces las dependencias entre tablas, romperas pipelines downstream que no sabias que existian.

El coste de limpiar y organizar datos despues de migrar es entre 3 y 5 veces mayor que hacerlo antes. En la nube, cada tabla almacenada tiene un coste (storage), cada query tiene un coste (compute), y cada dato mal migrado genera trabajo de correccion en un entorno nuevo donde el equipo aun esta aprendiendo. Migrar con governance significa migrar solo lo que necesitas, bien documentado y correctamente clasificado.

Ademas, las plataformas cloud (BigQuery, Snowflake, Redshift, Databricks) ofrecen capacidades nativas de governance (etiquetas, politicas de acceso, audit logs) que son mucho mas faciles de configurar correctamente durante la migracion que retroactivamente. Si llegas a la nube con un inventario limpio y clasificaciones de sensibilidad, puedes aprovechar estas capacidades desde el primer dia.

El inventario pre-migracion responde a tres preguntas: ¿que datos tenemos?, ¿cuales son necesarios? y ¿cuales podemos dejar atras? Un catalogo de datos conectado a tus fuentes on-premise extrae automaticamente la metadata de todas tus tablas: nombre, esquema, volumen, ultima actualizacion, columnas y relaciones.

Con el inventario completo, clasifica cada activo en una de tres categorias. "Migrar": activos activos, con consumidores conocidos y valor de negocio. "Archivar": activos historicos que se necesitan por compliance pero no por operacion (moverlos a cold storage en la nube). "Eliminar": activos obsoletos sin consumidores ni requisitos de retencion. En una migracion tipica, entre un 20% y un 40% de los activos se pueden archivar o eliminar, reduciendo el alcance y coste de la migracion.

Para cada activo clasificado como "migrar", documenta: el owner responsable, los consumidores conocidos (equipos y dashboards), los requisitos de frescura (¿debe actualizarse en real-time, diario, semanal?), y los requisitos de seguridad (¿contiene PII? ¿cual es el nivel de confidencialidad?). Esta documentacion guia las decisiones de arquitectura en la nube.

El lineage de datos es critico antes de una migracion porque revela las dependencias que no son obvias. Una tabla que parece poco importante puede estar alimentando 15 vistas y 3 dashboards ejecutivos. Si migras esa tabla de forma incorrecta o con un cambio de esquema, 15 procesos downstream se rompen sin aviso.

El lineage pre-migracion se construye analizando las queries SQL que se ejecutan contra tus fuentes de datos, las definiciones de vistas, los jobs de ETL y las conexiones de herramientas de BI. El resultado es un grafo de dependencias que muestra, para cada tabla, que la alimenta (upstream) y que consume de ella (downstream). Este grafo es la base para planificar el orden de migracion.

El orden de migracion debe seguir las dependencias: primero las tablas fuente (sin dependencias upstream dentro del alcance de migracion), luego las tablas derivadas que dependen de ellas, y finalmente los consumidores (dashboards, reportes, APIs). Migrar en orden inverso genera ventanas de tiempo donde los procesos downstream apuntan a una fuente que ya no existe o que tiene un esquema diferente.

Migrar datos a la nube sin clasificar su sensibilidad es un riesgo regulatorio directo. Los datos PII que en un entorno on-premise estaban protegidos por el perimetro de la red corporativa quedan expuestos a un modelo de acceso diferente en la nube. Las politicas de acceso, cifrado y retencion deben definirse antes de que los datos lleguen al nuevo entorno.

La clasificacion pre-migracion identifica cada campo que contiene datos personales (nombre, email, DNI, telefono, direccion IP), datos financieros sensibles, datos de salud u otros datos regulados. Para cada campo clasificado, se define: nivel de sensibilidad (publico, interno, confidencial, restringido), politica de acceso (que roles pueden verlo), politica de cifrado (en reposo y en transito) y politica de retencion (cuanto tiempo se conserva).

Las herramientas de deteccion automatica de PII pueden escanear todo el inventario y marcar automaticamente los campos que contienen datos personales. Esto convierte un proceso manual de semanas (revisar cada columna de cada tabla) en un escaneo de horas. El resultado es un mapa de sensibilidad que guia la configuracion de politicas de acceso en el entorno cloud desde el primer momento.

Un plan de migracion con governance integrado tiene cuatro fases. Fase 1 (semana 1-2): inventario y clasificacion. Conecta un catalogo de datos a tus fuentes on-premise, extrae metadata completa, clasifica activos (migrar/archivar/eliminar), identifica PII y asigna owners. Resultado: alcance de migracion definido y documentado.

Fase 2 (semana 3-4): mapeo de dependencias y plan de orden. Construye el lineage de todas las tablas en alcance, identifica dependencias criticas, define el orden de migracion (fuentes primero, derivadas despues, consumidores al final). Valida con los owners de cada dominio que el plan es correcto. Resultado: secuencia de migracion validada.

Fase 3 (semana 5-8): migracion por oleadas. Migra en oleadas siguiendo el orden del lineage. Para cada oleada, verifica: esquema correcto en destino, datos completos (conteo de registros), reglas de calidad pasando, politicas de acceso configuradas, y pipelines downstream reconectados. Usa el catalogo como fuente de verdad para el estado de cada activo.

Fase 4 (semana 9-10): validacion y decommission. Ejecuta reglas de calidad en paralelo (on-premise vs nube) para verificar consistencia. Confirma con los consumidores que los dashboards y reportes funcionan correctamente. Desconecta las fuentes on-premise solo cuando la validacion esta completa. Documenta la arquitectura final en el catalogo.

La migracion no termina cuando los datos llegan a la nube. El periodo post-migracion (primeros 3-6 meses) es critico para detectar problemas que no aparecieron en la validacion inicial: queries mas lentas de lo esperado, costes de compute que exceden las proyecciones, reglas de calidad que fallan intermitentemente, y nuevos datos que se crean sin governance.

Configura monitoring activo para los primeros meses: alertas de calidad de datos en las tablas migradas, monitoring de costes de storage y compute por dominio, deteccion automatica de nuevas tablas o columnas que aparezcan sin documentar y seguimiento del uso real de los activos migrados (para identificar tablas que se migraron pero nadie consume).

Establece el proceso de governance para el nuevo entorno desde el primer dia. Cada tabla nueva debe tener un owner, una descripcion y una clasificacion de sensibilidad antes de pasar a produccion. Las reglas de calidad deben configurarse como parte del pipeline, no como un anadido posterior. El catalogo de datos debe ser la primera parada para cualquier persona que quiera encontrar, entender o usar datos en el nuevo entorno cloud.