Checklist de migração de plataforma de BI

Trocar de plataforma de BI é um projeto de risco, não uma reinstalação de software#

Quando uma empresa decide sair de Qlik, Tableau, Cognos, SSRS, SAP BusinessObjects ou de uma teia de planilhas Excel rumo ao Power BI e ao Microsoft Fabric, a tentação é tratar tudo como uma troca de ferramenta: instala a nova, recria as telas antigas, desliga a velha. É aí que os projetos descarrilam. Migração de BI é migração de regra de negócio, de segurança de acesso, de agendamentos e de confiança da diretoria nos números. Um bom checklist migração de BI existe justamente para transformar esse risco difuso em uma sequência de itens verificáveis, fase a fase, de modo que nada essencial fique para trás.

Este material organiza um plano de migração de BI em sete fases, da descoberta inicial até a sustentação depois do go-live. Cada fase traz uma lista de itens que você pode marcar como concluídos, além de duas tabelas práticas: uma que conecta fase, entregável e responsável, e outra dedicada à validação de dados no dia da virada. Vale um aviso desde já: prazos variam muito conforme o escopo. Um departamento com trinta relatórios não se compara a uma empresa com centenas de painéis e dezenas de fontes. Use o checklist como estrutura, não como cronograma fixo.

Um bom checklist migração de BI se organiza por fases, não por telas#

O maior engano é começar pela recriação visual. Antes de abrir o Power BI Desktop, você precisa saber o que existe, o que vale a pena manter e como a fundação de dados vai ser desenhada. As sete fases a seguir seguem uma ordem lógica de dependência: cada uma só faz sentido depois que a anterior entregou o seu resultado. A tabela abaixo resume o que cada fase produz e qual papel costuma ser o responsável principal, para você distribuir a dona e o dono de cada frente antes de começar.

Fase	Entregável principal	Responsável (papel)
1. Descoberta e inventário	Catálogo de relatórios, fontes, usuários e agendamentos	Analista de BI e ponto focal de TI
2. Racionalização	Lista de decisão: migra, consolida, aposenta, redesenha	Donos de negócio e líder do projeto
3. Arquitetura e modelagem	Modelo estrela, camada semântica e escolha de conexão	Engenheiro de dados e modelador DAX
4. Governança e segurança	RLS, workspaces, catálogo e regras de LGPD	Governança de dados e segurança da informação
5. Desenvolvimento e validação	Relatórios recriados e validados número a número	Desenvolvedor de BI e analista de negócio
6. Adoção e go-live	Cutover executado, treinamento e plano de rollback	Líder do projeto e gestão de mudança
7. Sustentação	Monitoramento, backlog de evolução e legado desativado	Time de sustentação e área de dados

Fase 1: a descoberta e o inventário revelam o tamanho real do projeto#

Nenhuma decisão boa é tomada sem inventário. Ambientes de BI antigos acumulam camadas de relatórios, versões duplicadas por área e painéis que ninguém mais abre. Levantar isso com precisão é o que separa uma estimativa realista de uma surpresa cara no meio do caminho.

• Liste todos os relatórios e dashboards existentes, com dono, área e finalidade de cada um.
• Cruze o inventário com os logs de acesso da plataforma atual para medir o uso real, não o uso percebido.
• Mapeie todas as fontes de dados: bancos transacionais, ERPs, planilhas, APIs e extrações manuais.
• Documente a camada semântica atual: cálculos, definições de métrica e transformações escondidas em scripts.
• Registre os agendamentos de atualização, os horários e as dependências entre cargas.
• Levante o modelo de segurança vigente: quem enxerga o quê, e por qual regra.
• Identifique os usuários e os perfis de acesso, separando consumidores de autores.

Fase 2: a racionalização decide o que migra, consolida, aposenta e redesenha#

Migrar tudo por padrão é o erro que mais infla prazo e orçamento. A racionalização é a fase em que você olha o inventário de frente e decide, item por item, o destino de cada relatório. Cada painel descartado aqui é um que não vai exigir reconstrução, validação nem treinamento depois.

• Classifique cada relatório em uma de quatro categorias: migra como está, consolida com outros, aposenta ou redesenha.
• Junte relatórios parecidos em um único painel com filtros, em vez de replicar dezenas de variações.
• Aposente sem dó o que não tem uso real comprovado pelos logs, mesmo que alguém alegue usar.
• Marque para redesenho os painéis que a migração é a chance de melhorar, e não apenas copiar.
• Valide a classificação com os donos de negócio, não só com a TI, para evitar resistência no cutover.
• Congele o escopo racionalizado antes de avançar, para que a lista não cresça de novo no meio do projeto.

Fase 3: a arquitetura e a modelagem definem a fundação técnica#

Com o escopo definido, o próximo passo é a fundação de dados. Reconstruir a lógica de negócio dentro de cada relatório apenas transporta a bagunça antiga para a ferramenta nova. A alternativa correta é centralizar tudo em uma camada semântica governada antes de desenhar qualquer visual.

• Consolide as fontes mapeadas em um data warehouse ou lakehouse com chaves e granularidade consistentes.
• Escolha entre ETL e ELT conforme o volume, a origem e a janela de atualização de cada fonte.
• Modele em esquema estrela, com tabelas fato e dimensão claras, evitando relacionamentos ambíguos.
• Centralize os cálculos de negócio em medidas DAX no modelo semântico, não espalhados por relatório.
• Defina, para cada fonte, o modo de conexão: Import para velocidade, DirectQuery para dado ao vivo, Direct Lake quando o dado já vive no OneLake.
• Padronize nomes, formatos e uma tabela de datas única, para dar consistência a todo o modelo.

A escolha entre Import, DirectQuery e Direct Lake não é ideológica: depende de tamanho de dado, frequência de atualização e latência aceitável. Se você quer aprofundar os fundamentos dessa fundação antes de migrar, o guia completo de Power BI para empresas no Brasil cobre o ecossistema com calma.

Fase 4: a governança e a segurança precisam nascer com o projeto#

Segurança e governança não são um ajuste final; elas se desenham junto com o modelo. Deixar isso para depois do go-live é a forma mais comum de vazar dado sensível ou de descobrir, tarde demais, que ninguém sabe quem tem acesso a quê.

• Implemente segurança por linha (RLS) no nível do modelo semântico, replicando com fidelidade as regras da plataforma antiga.
• Estruture os workspaces por área e por ciclo de vida, separando desenvolvimento, homologação e produção.
• Publique um catálogo de dados que registre a definição, o dono e a origem de cada métrica crítica.
• Trate os dados pessoais conforme a LGPD (Lei nº 13.709/2018): mapeie o que é dado pessoal, minimize a exposição e registre a base legal.
• Aplique rótulos de sensibilidade nos relatórios e conjuntos de dados que contêm informação restrita.
• Configure credenciais e gateways de dados de forma centralizada, evitando senhas presas a uma pessoa só.
• Defina quem promove conteúdo entre ambientes e quem certifica um modelo como confiável.

A governança é o que impede que a plataforma nova repita, em poucos meses, a mesma desorganização da antiga. Estruturar esse trilho é o núcleo de um trabalho de governança de dados bem conduzido.

Fase 5: o desenvolvimento e a validação provam que o número bate#

Só depois da fundação e da governança prontas vem a reconstrução visual. E reconstruir não é o fim: o entregável real desta fase é a paridade comprovada, número a número, contra o sistema legado. Um relatório bonito que mostra um total diferente do antigo destrói a confiança do usuário mais rápido do que qualquer atraso.

• Recrie os relatórios do escopo racionalizado sobre o modelo semântico único, sem lógica solta no visual.
• Compare cada indicador do relatório novo com o mesmo indicador no legado, para os mesmos filtros e períodos.
• Documente e explique qualquer diferença: às vezes o número novo é o certo e o antigo estava errado.
• Faça testes de performance com volume real de dados, não com uma amostra pequena.
• Valide a segurança por linha com usuários de perfis diferentes, conferindo que cada um vê só o que deve.
• Registre o aceite formal de cada relatório com o dono de negócio antes de considerá-lo pronto.

Essa validação merece um roteiro próprio para o dia da virada. A tabela abaixo lista os itens de checagem que não podem faltar no go-live.

Item de validação	O que conferir	Critério de aceite
Totais gerais	Soma de receita, volume e contagem por período	Igual ao legado ou diferença explicada
Recortes por dimensão	Valores por área, produto, região e cliente	Batem em todos os cruzamentos-chave
Períodos comparativos	Mês, ano e acumulados contra o histórico	Consistentes com o relatório antigo
Segurança por linha	Visão de cada perfil de usuário	Cada perfil vê apenas o permitido
Atualização de dados	Horário e sucesso das cargas agendadas	Rodam no horário e sem falha
Performance	Tempo de abertura e de resposta dos filtros	Dentro do aceitável com dado real

Fase 6: a adoção e o go-live decidem se a migração pega#

A melhor migração técnica fracassa se o usuário não adota a plataforma nova. Esta fase é sobre pessoas: comunicação clara, treinamento no contexto de cada área e uma virada planejada com rota de retorno se algo der errado.

• Comunique com antecedência o que muda, quando muda e onde encontrar cada relatório novo.
• Treine os usuários nos painéis que eles de fato usam, e não em um tutorial genérico da ferramenta.
• Planeje o cutover, decidindo entre virada única ou convivência temporária das duas plataformas.
• Mantenha o legado disponível em modo leitura por um período combinado, como rede de segurança.
• Tenha um plano de rollback escrito: como voltar ao estado anterior se um problema crítico aparecer.
• Abra um canal direto de suporte nos primeiros dias, para resolver dúvidas antes que virem desconfiança.

Fase 7: a sustentação garante que o legado morre e a evolução continua#

O go-live não é o fim do projeto, é o começo da operação. Sem sustentação, a plataforma nova envelhece mal e a antiga nunca é desligada de fato, dobrando o custo. Esta fase transforma a migração em rotina saudável.

• Monitore o uso, a performance e o sucesso das atualizações com painéis de administração.
• Organize um backlog de evolução, priorizando as melhorias que os usuários pedem depois de adotar.
• Estabeleça uma cadência de manutenção do modelo semântico, do catálogo e das regras de segurança.
• Desative o legado de forma definitiva na data combinada, arquivando o que exigir retenção.
• Registre lições aprendidas para que a próxima migração de fonte ou área seja mais rápida.

Manter isso vivo é o objetivo de um trabalho contínuo de sustentação de BI, que evita que a plataforma nova vire, com o tempo, o próximo legado a ser migrado.

Perguntas frequentes#

Quanto tempo leva uma migração de plataforma de BI?

Depende inteiramente do escopo. O que determina o prazo não é a ferramenta de origem, é o número de relatórios que sobrevivem à racionalização, a quantidade de fontes envolvidas e a complexidade das regras de negócio escondidas. Por isso a fase de descoberta vem primeiro: sem inventário, qualquer prazo é chute. Um escopo enxuto e bem racionalizado avança muito mais rápido do que uma migração que insiste em levar tudo.

Preciso migrar todos os relatórios que já existem?

Não, e essa é justamente a decisão mais importante do projeto. A fase de racionalização costuma revelar que boa parte dos relatórios está duplicada, sem uso real ou pronta para ser consolidada. Migrar tudo por padrão infla prazo, custo e transporta a desorganização antiga para a plataforma nova. Cada painel aposentado é economia de reconstrução, validação e treinamento.

Como garantir que os números novos batem com os antigos?

Com validação número a número, item por item, comparando cada indicador do relatório novo contra o mesmo indicador no legado, para os mesmos filtros e períodos. Quando aparece diferença, ela precisa ser explicada, não escondida: às vezes o número novo é o correto e o antigo carregava um erro histórico. O aceite formal do dono de negócio é o que fecha essa etapa com segurança.

O que acontece com a segurança de acesso na migração?

Ela precisa ser redesenhada no modelo novo, não apenas copiada de forma genérica. As regras de quem enxerga o quê são recriadas com segurança por linha (RLS) no nível do modelo semântico, e testadas com usuários de perfis diferentes antes do go-live. Tratar isso como detalhe final é a forma mais comum de expor dado sensível ou de violar a LGPD sem perceber.

Import, DirectQuery ou Direct Lake: qual escolher na migração?

Não existe resposta única, a escolha é por fonte. Import entrega a melhor performance e serve à maioria dos casos. DirectQuery faz sentido quando o dado precisa estar ao vivo ou é grande demais para importar. Direct Lake é a opção quando o dado já vive no OneLake do Fabric, unindo velocidade e frescor. A decisão depende de volume, latência aceitável e frequência de atualização de cada tabela.

Vale a pena manter a plataforma antiga rodando por um tempo?

Sim, por um período combinado e em modo de leitura, como rede de segurança durante o cutover. Isso reduz o risco da virada e dá aos usuários um ponto de comparação enquanto ganham confiança na plataforma nova. O cuidado é ter uma data firme para desligar o legado: convivência sem prazo definido vira custo dobrado e desmotiva a adoção do ambiente novo.

Um checklist só vale pelo que você marca de verdade#

Migrar de plataforma de BI dá certo quando o projeto respeita a ordem das fases: descobrir antes de decidir, decidir antes de construir, construir sobre uma fundação governada e validar antes de virar a chave. Pular etapas para ganhar tempo é o caminho mais curto para o retrabalho, para a diretoria desconfiando dos números e para o usuário voltando à planilha paralela. O checklist acima existe para que nada essencial fique de fora e para que o prazo, seja ele qual for, saia de uma base realista.

Se você está avaliando sair de Qlik, Tableau ou de outra plataforma legada rumo ao Power BI e ao Fabric, e quer conduzir isso com método em vez de improviso, veja como funciona nosso serviço de migração de Qlik e Tableau para Power BI e fale com a gente para uma leitura do seu caso.