Migrar dades al núvol: governance abans de migrar
Migrar dades al núvol sense governance és com mudar-se de casa sense saber què hi ha a cada caixa. El resultat és previsible: dades duplicades, taules òrfenes, camps PII exposats en entorns que no compleixen la normativa, dependències trencades i mesos de neteja post-migració que podrien haver-se evitat.
Aquesta guia proposa un enfocament diferent: establir els fonaments de governance abans de migrar, no després. L'inventari pre-migració, el mapatge de dependències i la classificació de dades sensibles són passos que la majoria d'organitzacions descobreixen que necessitaven quan ja és tard. Fer-los abans redueix el risc, el cost i el temps de migració.
Per què governance abans de migrar, no després
La raó principal és que migrar dades sense conèixer-les amplifica els problemes existents. Si no saps quines taules estan obsoletes, migraràs taules obsoletes. Si no saps quins camps contenen PII, exposaràs PII en un entorn cloud potencialment més accessible. Si no coneixes les dependències entre taules, trencaàs pipelines downstream que no sabies que existien.
El cost de netejar i organitzar dades després de migrar és entre 3 i 5 vegades major que fer-ho abans. Al núvol, cada taula emmagatzemada té un cost (storage), cada query té un cost (compute), i cada dada mal migrada genera treball de correcció en un entorn nou on l'equip encara està aprenent. Migrar amb governance significa migrar únicament el que necessites, ben documentat i correctament classificat.
A més, les plataformes cloud (BigQuery, Snowflake, Redshift, Databricks) ofereixen capacitats natives de governance (etiquetes, polítiques d'accés, audit logs) que són molt més fàcils de configurar correctament durant la migració que retroactivament. Si arribes al núvol amb un inventari net i classificacions de sensibilitat, pots aprofitar aquestes capacitats des del primer dia.
Inventari pre-migració: el que tens i el que necessites
L'inventari pre-migració respon a tres preguntes: quines dades tenim?, quines són necessàries? i quines podem deixar enrere? Un catàleg de dades connectat a les teves fonts on-premise extreu automàticament la metadada de totes les teves taules: nom, esquema, volum, darrera actualització, columnes i relacions.
Amb l'inventari complet, classifica cada actiu en una de tres categories. "Migrar": actius actius, amb consumidors coneguts i valor de negoci. "Arxivar": actius històrics que es necessiten per compliance però no per operació (moure'ls a cold storage al núvol). "Eliminar": actius obsolets sense consumidors ni requisits de retenció. En una migració típica, entre un 20% i un 40% dels actius es poden arxivar o eliminar, reduint l'abast i el cost de la migració.
Per a cada actiu classificat com a "migrar", documenta: l'owner responsable, els consumidors coneguts (equips i dashboards), els requisits de frescor (s'ha d'actualitzar en temps real, diari, setmanal?), i els requisits de seguretat (conté PII? quin és el nivell de confidencialitat?). Aquesta documentació guia les decisions d'arquitectura al núvol.
Mapatge de dependències amb lineage
El lineage de dades és crític abans d'una migració perquè revela les dependències que no són òbvies. Una taula que sembla poc important pot estar alimentant 15 vistes i 3 dashboards executius. Si migreixes aquesta taula de forma incorrecta o amb un canvi d'esquema, 15 processos downstream es trenquen sense avís.
El lineage pre-migració es construeix analitzant les queries SQL que s'executen contra les teves fonts de dades, les definicions de vistes, els jobs d'ETL i les connexions d'eines de BI. El resultat és un graf de dependències que mostra, per a cada taula, quina l'alimenta (upstream) i qui en consumeix (downstream). Aquest graf és la base per planificar l'ordre de migració.
L'ordre de migració ha de seguir les dependències: primer les taules font (sense dependències upstream dins de l'abast de migració), després les taules derivades que en depenen, i finalment els consumidors (dashboards, informes, APIs). Migrar en ordre invers genera finestres de temps on els processos downstream apunten a una font que ja no existeix o que té un esquema diferent.
Classificació de dades sensibles abans de migrar
Migrar dades al núvol sense classificar la seva sensibilitat és un risc regulatori directe. Les dades PII que en un entorn on-premise estaven protegides pel perímetre de la xarxa corporativa queden exposades a un model d'accés diferent al núvol. Les polítiques d'accés, xifratge i retenció s'han de definir abans que les dades arribin al nou entorn.
La classificació pre-migració identifica cada camp que conté dades personals (nom, email, DNI, telèfon, adreça IP), dades financeres sensibles, dades de salut o altres dades regulades. Per a cada camp classificat, es defineix: nivell de sensibilitat (públic, intern, confidencial, restringit), política d'accés (quins rols el poden veure), política de xifratge (en repòs i en trànsit) i política de retenció (quant de temps es conserva).
Les eines de detecció automàtica de PII poden escanejar tot l'inventari i marcar automàticament els camps que contenen dades personals. Això converteix un procés manual de setmanes (revisar cada columna de cada taula) en un escaneig d'hores. El resultat és un mapa de sensibilitat que guia la configuració de polítiques d'accés en l'entorn cloud des del primer moment.
Pla de migració amb governance integrat
Un pla de migració amb governance integrat té quatre fases. Fase 1 (setmana 1-2): inventari i classificació. Connecta un catàleg de dades a les teves fonts on-premise, extreu metadada completa, classifica actius (migrar/arxivar/eliminar), identifica PII i assigna owners. Resultat: abast de migració definit i documentat.
Fase 2 (setmana 3-4): mapatge de dependències i pla d'ordre. Construeix el lineage de totes les taules en abast, identifica dependències crítiques, defineix l'ordre de migració (fonts primer, derivades després, consumidors al final). Valida amb els owners de cada domini que el pla és correcte. Resultat: seqüència de migració validada.
Fase 3 (setmana 5-8): migració per onades. Migra en onades seguint l'ordre del lineage. Per a cada onada, verifica: esquema correcte a la destinació, dades completes (recompte de registres), regles de qualitat passant, polítiques d'accés configurades, i pipelines downstream reconnectats. Utilitza el catàleg com a font de veritat per a l'estat de cada actiu.
Fase 4 (setmana 9-10): validació i decommission. Executa regles de qualitat en paral·lel (on-premise vs. núvol) per verificar consistència. Confirma amb els consumidors que els dashboards i informes funcionen correctament. Desconnecta les fonts on-premise únicament quan la validació és completa. Documenta l'arquitectura final al catàleg.
Post-migració: monitoring i governance continu
La migració no acaba quan les dades arriben al núvol. El període post-migració (primers 3-6 mesos) és crític per detectar problemes que no van aparèixer en la validació inicial: queries més lentes del que s'esperava, costos de compute que excedeixen les projeccions, regles de qualitat que fallen intermitentment, i noves dades que es creen sense governance.
Configura monitoring actiu per als primers mesos: alertes de qualitat de dades en les taules migrades, monitoring de costos de storage i compute per domini, detecció automàtica de noves taules o columnes que apareguin sense documentar i seguiment de l'ús real dels actius migrats (per identificar taules que es van migrar però que ningú consumeix).
Estableix el procés de governance per al nou entorn des del primer dia. Cada taula nova ha de tenir un owner, una descripció i una classificació de sensibilitat abans de passar a producció. Les regles de qualitat s'han de configurar com a part del pipeline, no com un afegit posterior. El catàleg de dades ha de ser la primera parada per a qualsevol persona que vulgui trobar, entendre o usar dades en el nou entorn cloud.
Migrar dades al núvol amb governance no és un luxe: és la forma més eficient de fer-ho. L'inventari pre-migració redueix l'abast (i el cost) en eliminar actius obsolets. El mapatge de dependències prevé incidents en definir l'ordre correcte. La classificació de sensibilitat garanteix el compliance des del dia u. I el monitoring post-migració detecta problemes abans que impactin el negoci.
Les organitzacions que integren governance en el seu pla de migració reporten un 30-40% menys d'incidents post-migració, un 20-30% de reducció en costos de storage (en no migrar dades obsoletes) i un time-to-value significativament menor perquè els equips poden trobar i usar dades des del primer dia en el nou entorn.