Migrar dados para a nuvem: governance antes de migrar
Migrar dados para a nuvem sem governance é como mudar de casa sem saber o que há em cada caixa. O resultado é previsível: dados duplicados, tabelas órfãs, PII exposta em ambientes que não cumprem as normas regulatórias, dependências quebradas e meses de limpeza pós-migração que podiam ter sido evitados.
Este guia propõe uma abordagem diferente: estabelecer os fundamentos de governance antes de migrar, não depois. O inventário pré-migração, o mapeamento de dependências e a classificação de dados sensíveis são etapas que a maioria das organizações descobre que precisava quando já é tarde demais. Fazê-las antes reduz o risco, o custo e o tempo de migração.
Por que governance antes de migrar, não depois
A razão principal é que migrar dados sem os conhecer amplifica os problemas existentes. Se não sabe que tabelas estão obsoletas, vai migrar tabelas obsoletas. Se não sabe que campos contêm PII, vai expor PII num ambiente de nuvem potencialmente mais acessível. Se não conhece as dependências entre tabelas, vai quebrar pipelines a jusante que não sabia que existiam.
O custo de limpar e organizar dados após a migração é entre 3 e 5 vezes superior a fazê-lo antes. Na nuvem, cada tabela armazenada tem um custo (armazenamento), cada query tem um custo (computação) e cada dado mal migrado gera trabalho de correção num ambiente novo onde a equipa ainda está a aprender. Migrar com governance significa migrar apenas o que precisa, bem documentado e corretamente classificado.
Além disso, as plataformas de nuvem (BigQuery, Snowflake, Redshift, Databricks) oferecem capacidades nativas de governance (etiquetas, políticas de acesso, registos de auditoria) que são muito mais fáceis de configurar corretamente durante a migração do que retroativamente. Se chegar à nuvem com um inventário limpo e classificações de sensibilidade, pode aproveitar estas capacidades desde o primeiro dia.
Inventário pré-migração: o que tem e o que precisa
O inventário pré-migração responde a três perguntas: que dados temos, quais são necessários e quais podemos deixar para trás? Um catálogo de dados ligado às suas fontes on-premise extrai automaticamente os metadados de todas as suas tabelas: nome, esquema, volume, última atualização, colunas e relações.
Com o inventário completo, classifique cada ativo numa de três categorias. "Migrar": ativos ativos, com consumidores conhecidos e valor de negócio. "Arquivar": ativos históricos necessários por conformidade mas não por operação (movê-los para cold storage na nuvem). "Eliminar": ativos obsoletos sem consumidores nem requisitos de retenção. Numa migração típica, entre 20% e 40% dos ativos podem ser arquivados ou eliminados, reduzindo o âmbito e custo da migração.
Para cada ativo classificado como "migrar", documente: o owner responsável, os consumidores conhecidos (equipas e dashboards), os requisitos de frescura (precisa de ser atualizado em tempo real, diário, semanal?) e os requisitos de segurança (contém PII? qual é o nível de confidencialidade?). Esta documentação orienta as decisões de arquitetura na nuvem.
Mapeamento de dependências com linhagem
A linhagem de dados é crítica antes de uma migração porque revela as dependências não óbvias. Uma tabela que parece pouco importante pode estar a alimentar 15 vistas e 3 dashboards executivos. Se migrar essa tabela de forma incorreta ou com uma alteração de esquema, 15 processos a jusante quebram sem aviso.
A linhagem pré-migração constrói-se analisando as queries SQL que se executam contra as suas fontes de dados, as definições de vistas, os jobs de ETL e as ligações das ferramentas de BI. O resultado é um grafo de dependências que mostra, para cada tabela, o que a alimenta (a montante) e o que consome dela (a jusante). Este grafo é a base para planear a ordem de migração.
A ordem de migração deve seguir as dependências: primeiro as tabelas fonte (sem dependências a montante no âmbito da migração), depois as tabelas derivadas que dependem delas e, por fim, os consumidores (dashboards, relatórios, APIs). Migrar em ordem inversa cria janelas de tempo em que os processos a jusante apontam para uma fonte que já não existe ou que tem um esquema diferente.
Classificação de dados sensíveis antes de migrar
Migrar dados para a nuvem sem classificar a sua sensibilidade é um risco regulatório direto. Os dados PII que num ambiente on-premise estavam protegidos pelo perímetro da rede corporativa ficam expostos a um modelo de acesso diferente na nuvem. As políticas de acesso, cifragem e retenção devem definir-se antes de os dados chegarem ao novo ambiente.
A classificação pré-migração identifica cada campo que contém dados pessoais (nome, e-mail, NIF, telefone, endereço IP), dados financeiros sensíveis, dados de saúde ou outros dados regulamentados. Para cada campo classificado, define-se: nível de sensibilidade (público, interno, confidencial, restrito), política de acesso (que funções podem consultá-lo), política de cifragem (em repouso e em trânsito) e política de retenção (quanto tempo se conserva).
As ferramentas de deteção automática de PII podem analisar todo o inventário e marcar automaticamente os campos que contêm dados pessoais. Isto converte um processo manual de semanas (rever cada coluna de cada tabela) numa análise de horas. O resultado é um mapa de sensibilidade que orienta a configuração de políticas de acesso no ambiente de nuvem desde o primeiro momento.
Plano de migração com governance integrado
Um plano de migração com governance integrado tem quatro fases. Fase 1 (semanas 1 e 2): inventário e classificação. Ligue um catálogo de dados às suas fontes on-premise, extraia metadados completos, classifique ativos (migrar/arquivar/eliminar), identifique PII e atribua owners. Resultado: âmbito de migração definido e documentado.
Fase 2 (semanas 3 e 4): mapeamento de dependências e plano de ordem. Construa a linhagem de todas as tabelas no âmbito, identifique dependências críticas, defina a ordem de migração (fontes primeiro, derivadas depois, consumidores por último). Valide com os owners de cada domínio que o plano está correto. Resultado: sequência de migração validada.
Fase 3 (semanas 5 a 8): migração por vagas. Migre em vagas seguindo a ordem da linhagem. Para cada vaga, verifique: esquema correto no destino, dados completos (contagem de registos), regras de qualidade a passar, políticas de acesso configuradas e pipelines a jusante reconectados. Utilize o catálogo como fonte de verdade para o estado de cada ativo.
Fase 4 (semanas 9 e 10): validação e descomissionamento. Execute regras de qualidade em paralelo (on-premise vs. nuvem) para verificar a consistência. Confirme com os consumidores que os dashboards e relatórios funcionam corretamente. Desconecte as fontes on-premise apenas quando a validação estiver completa. Documente a arquitetura final no catálogo.
Pós-migração: monitorização e governance contínuo
A migração não termina quando os dados chegam à nuvem. O período pós-migração (primeiros 3 a 6 meses) é crítico para detetar problemas que não apareceram na validação inicial: queries mais lentas do que o esperado, custos de computação que excedem as projeções, regras de qualidade que falham intermitentemente e novos dados que se criam sem governance.
Configure monitorização ativa nos primeiros meses: alertas de qualidade de dados nas tabelas migradas, monitorização de custos de armazenamento e computação por domínio, deteção automática de novas tabelas ou colunas que apareçam sem documentar e acompanhamento do uso real dos ativos migrados (para identificar tabelas que foram migradas mas que ninguém consome).
Estabeleça o processo de governance para o novo ambiente desde o primeiro dia. Cada tabela nova deve ter um owner, uma descrição e uma classificação de sensibilidade antes de entrar em produção. As regras de qualidade devem configurar-se como parte do pipeline, não como um acrescento posterior. O catálogo de dados deve ser a primeira paragem para qualquer pessoa que pretenda encontrar, compreender ou utilizar dados no novo ambiente de nuvem.
Migrar dados para a nuvem com governance não é um luxo: é a forma mais eficiente de o fazer. O inventário pré-migração reduz o âmbito (e o custo) ao eliminar ativos obsoletos. O mapeamento de dependências previne incidentes ao definir a ordem correta. A classificação de sensibilidade garante conformidade desde o primeiro dia. E a monitorização pós-migração deteta problemas antes que afetem o negócio.
As organizações que integram governance no seu plano de migração reportam 30 a 40% menos incidentes pós-migração, uma redução de 20 a 30% nos custos de armazenamento (por não migrarem dados obsoletos) e um time-to-value significativamente menor porque as equipas conseguem encontrar e utilizar dados desde o primeiro dia no novo ambiente.