Nos dois resgates de migração que conduzi, o projeto chegou até mim com meses de atraso. Em nenhum deles o problema era a ferramenta. Microsoft Fabric e Databricks funcionam bem. O que falhou foi o planejamento.
Aqui estão os erros que vi se repetirem e o que eu faria desde o primeiro dia. Vale para migrar Power BI e SQL Server para o Fabric, ambientes on-premise para Databricks ou uma plataforma para a outra.
1. Começar a migrar sem discovery e sem plano de rollout
Este é o erro que causa quase todos os outros. O projeto começa movendo workloads antes de alguém saber o que existe, o que é usado e quanto cada coisa consome. Sem essa base, cada onda descobre uma dependência nova e o cronograma escorrega.
O discovery precisa ser feito com dados de uso atuais, e não com entrevistas ou com a lista de relatórios que alguém lembra. Os artefatos que eu monto nessa fase são:
- Inventário com uso real: todos os relatórios, modelos semânticos e pipelines, com acessos por relatório e por usuário. No Power BI, esses dados vêm do log de atividades da API de administração.
- Consumo de capacidade: quanto cada workload consome e em que horários, por exemplo pelo app Microsoft Fabric Capacity Metrics.
- Mapa de dependências: de quais fontes e pipelines cada modelo e relatório depende.
- Matriz de priorização: uso, criticidade para o negócio, esforço de migração e impacto na capacidade.
- Lista do que não migrar: relatórios sem uso que podem ser desligados.
Com isso em mãos, o plano de rollout deixa de ser um chute: ondas definidas pela prioridade, critérios para cada onda começar e terminar, data de desligamento de cada relatório antigo, responsáveis e checkpoints de capacidade.
Num dos projetos, os dados de uso mostraram que os dashboards já entregues tinham adoção próxima de zero. Depois da correção, a adoção chegou a 83%. No outro, montei o plano de rollout antes de tocar em qualquer workload, e foi ele que permitiu caber numa capacidade fixa.
2. Dimensionar a capacidade só para os dados
No Microsoft Fabric, a capacidade (a F SKU contratada, como F64) é compartilhada: engenharia, atualização de modelos e uso dos relatórios disputam os mesmos recursos. Muitas migrações calculam a capacidade pelo volume de dados e esquecem quantas pessoas vão abrir os relatórios ao mesmo tempo.
Num dos projetos, cerca de 200 dashboards sobre 1 TB precisavam caber numa F64 fixa. O pico chegava a 98%. Depois de reorganizar o rollout e os modelos, caiu para 61%.
3. Fazer lift-and-shift do modelo antigo
Levar o modelo de dados exatamente como está parece mais rápido, mas leva junto todos os problemas: tabelas duplicadas, métricas calculadas em vários lugares e um modelo semântico pesado que continua lento no ambiente novo.
Num dos casos, a causa raiz do atraso era uma camada semântica mal modelada. Nenhum ajuste de infraestrutura resolveria.
4. Manter o legado vivo sem controle
É comum o time seguir atualizando os relatórios antigos enquanto os novos são construídos. Sem regra, as duas versões passam a mostrar números diferentes e o negócio continua usando a antiga.
5. Tentar refazer tudo
Quando a migração atrasa, a tentação é recomeçar do zero “do jeito certo”. Com capacidade e prazo limitados, isso quase sempre aumenta o atraso.
6. Deixar o time para o final
Se só a consultoria entende a nova plataforma, o projeto termina com uma dependência no lugar de uma solução. O risco aumenta quando o time interno muda durante o projeto, o que é comum.
Checklist antes de começar a migração
- Inventário de relatórios, modelos e pipelines com dados de uso atuais.
- Consumo de capacidade medido por workload e por horário.
- Mapa de dependências e matriz de priorização.
- Plano de rollout em ondas, com critérios e datas de desligamento do legado.
- Revisão do modelo semântico e das métricas principais.
- Padrões, documentação e responsáveis internos desde a primeira onda.
Se a sua migração para Microsoft Fabric ou Databricks já está atrasada, comece pelo discovery. Veja como funciona o serviço de migração para Databricks e Fabric ou leia o case de uma migração resgatada em 12 semanas.
Consultor de dados e fundador da Loucoud. Trabalha há mais de 10 anos com plataformas de dados e hoje se dedica a Databricks, Microsoft Fabric, Power BI e IA generativa sobre dados.
