Como migrar um Data Warehouse legado para um Lakehouse de alta performance

Muitas empresas têm um Data Warehouse que funcionou bem por anos, mas hoje sofre com custo de licença, janelas de carga longas e dificuldade de atender dados semiestruturados e IA. Migrar para um Lakehouse resolve boa parte disso — desde que a migração seja tratada como projeto de negócio, não só de tecnologia.

Por que migrar

• Armazenamento de baixo custo com formato aberto, sem dependência de um fornecedor.
• Uma única plataforma para BI, engenharia e machine learning.
• Escala elástica de processamento.
• Suporte a dados estruturados, semiestruturados e streaming.

Para entender as diferenças conceituais, veja Data Warehouse vs. Data Lake.

Roteiro em 6 etapas

1. Inventário

Liste fontes, tabelas, procedures, jobs de ETL, relatórios e usuários. Identifique o que é usado de fato: é comum encontrar grande parte dos objetos sem acesso recente.

2. Arquitetura alvo

Defina camadas (bronze para dados brutos, prata para dados limpos e integrados, ouro para modelos de consumo), padrões de nomenclatura, segurança e catálogo. A escolha de plataforma está em Microsoft Fabric vs. Databricks.

3. Estratégia por ondas

Evite o “big bang”. Migre por domínio de negócio (financeiro, comercial, operações), começando por um de valor visível e complexidade moderada.

4. Reescrita das transformações

Procedures e ETLs legados raramente devem ser copiados linha a linha. É a oportunidade de reescrever em SQL versionado e testado — veja pipelines com Airflow e dbt. Preserve o modelo dimensional que os usuários conhecem.

5. Validação e convivência

Rode o legado e o novo em paralelo e compare contagens, somas e indicadores-chave por período. Só troque a fonte dos relatórios quando os números baterem.

6. Desligamento

Defina data de congelamento do legado, migre os últimos consumidores e desligue. Sem esse passo, a empresa paga duas plataformas indefinidamente.

Riscos comuns

• Subestimar regras de negócio escondidas em procedures.
• Migrar sem testes de qualidade — veja qualidade de dados.
• Não planejar custo de processamento na nova plataforma — veja FinOps para dados.

Veja a arquitetura completa no Guia de Engenharia e Arquitetura de Dados.