Como migrar de QlikView, Qlik Sense ou Tableau para Power BI sem apagão de informação

Migrar de QlikView, Qlik Sense ou Tableau para Power BI é gestão de risco, não troca de ferramenta#

Toda empresa que decide migrar para Power BI vindo de QlikView, Qlik Sense ou Tableau parte da mesma premissa equivocada: que o projeto é recriar as telas que já existem em uma ferramenta nova. Não é. É extrair anos de regra de negócio que ficaram presas em scripts de carga, expressões set analysis e calculated fields — muitas vezes escritos por gente que já saiu da empresa — e reconstruir essa lógica de forma auditável, sem que o usuário perceba a troca, exceto pela interface.

É por isso que migrações mal planejadas viram meses de retrabalho, diretoria desconfiando dos números e gente voltando para a "planilha paralela que sempre batia certo". Já conduzimos migrações de grande porte — inclusive uma com mais de 1.200 relatórios de QlikView reconstruídos em Power BI — e o padrão se repete: o risco técnico existe, mas quem mais derruba o projeto é falha de processo e de adoção, não erro de sintaxe.

Este é o playbook que usamos: inventário e racionalização, mapeamento de regras de negócio, camada semântica governada, reconstrução, validação de paridade número a número, cutover faseado e gestão de mudança. Com duas tabelas práticas e a lista dos erros que mais derrubam esse tipo de projeto.

O primeiro passo não é migrar relatórios, é decidir quais merecem sobreviver#

O erro mais comum começa antes de qualquer linha de DAX: migrar tudo, por padrão. Ambientes de BI antigos acumulam relatório sobre relatório — versões duplicadas por departamento, painéis criados para uma apresentação única e nunca desativados, dashboards que alguém ainda abre por hábito, não por necessidade.

Migrar esse volume sem filtro infla cronograma e orçamento, e transporta para a plataforma nova a mesma desorganização da antiga. Antes de tocar em qualquer fonte de dados, o trabalho é de inventário:

• Levantar todos os relatórios existentes, com dono, área e frequência de uso real — não a percebida.
• Cruzar isso com os logs de acesso da plataforma atual; o resultado raramente bate com "todo mundo usa".
• Classificar cada item em manter, consolidar (relatórios parecidos viram um só, com filtros) ou aposentar.
• Validar a classificação com os donos de negócio, não só com TI — decisão sem esse aval gera resistência no cutover.

Essa etapa costuma reduzir de forma expressiva o volume a reconstruir, e é o que mais influencia prazo e custo do projeto inteiro: cada relatório descartado aqui é um que não vai exigir mapeamento, validação de paridade nem treinamento depois.

Toda migração de BI falha na regra de negócio escondida, não na sintaxe#

Trocar a sintaxe de uma fórmula é trabalho mecânico. O problema real é que boa parte da lógica de negócio nunca foi documentada — existe só dentro de scripts de carga, expressões set analysis, calculated fields e na cabeça de quem criou o relatório.

Antes de reconstruir, é preciso mapear, para o conjunto racionalizado:

• As fontes de dados de origem — bancos transacionais, planilhas, APIs, extrações manuais — e o grau de confiabilidade de cada uma.
• As transformações aplicadas antes do dado chegar à visualização: filtros no script de carga, joins específicos, conversão de moeda, deduplicação.
• Os cálculos de negócio nas expressões — como "receita líquida" ou "churn" foi definido, e se essa definição é consistente entre relatórios (frequentemente não é).
• As regras de segurança e de acesso, para recriar Row-Level Security no Power BI — ignorar isso é uma forma silenciosa de vazar dado sensível.

Esse mapeamento costuma revelar inconsistências antigas, como duas áreas calculando a mesma métrica de formas diferentes. Migrar sem resolver isso só transporta o problema; decidir qual definição está certa é o que entrega valor de verdade.

Sem uma camada semântica governada, a migração troca uma gambiarra por outra#

O erro estrutural mais caro é reconstruir a lógica de negócio dentro de cada relatório Power BI, exatamente como ela vivia em cada app QlikView ou workbook Tableau. Isso recria o mesmo problema de antes: toda mudança de regra exige caçar e ajustar dezenas de relatórios, e é fácil esquecer um.

A alternativa correta — o que diferencia uma migração bem feita de um projeto de "clonar telas" — é construir a camada semântica antes da reconstrução visual:

• Consolidar as fontes mapeadas em um data warehouse ou lakehouse bem modelado, com granularidade e chaves consistentes.
• Centralizar cálculos, conversões e deduplicações em um modelo semântico único, não espalhados em cada relatório.
• Definir uma vez, de forma auditável, o significado de cada métrica crítica, com o dono certo validando.
• Desenhar segurança de dados (RLS, sensitivity labels) no nível do modelo, não do relatório.

Esse é o trabalho de engenharia de dados combinado a governança de dados, e é o que garante que a migração seja oportunidade de arrumar a casa, não apenas trocar interface. Quem pula essa etapa termina com um Power BI tão difícil de manter quanto o QlikView anterior — só que pago duas vezes.

A reconstrução em Power BI é a parte mais rápida do projeto, não a mais importante#

Com fontes mapeadas e camada semântica desenhada, a reconstrução visual costuma ser a etapa mais rápida — desde que o resto tenha sido feito com rigor. É também a mais visível para quem está de fora, o que cria uma armadilha: patrocinadores que só enxergam "quando os relatórios ficam prontos" pressionam para pular direto para cá.

Aqui entram as decisões técnicas específicas: Import, DirectQuery ou modelo composto conforme volume e frequência de atualização; desenho do modelo tabular (estrela, relacionamentos, tabelas de data); tradução de set analysis do QlikView ou calculated fields do Tableau para DAX equivalente; recriação de bookmarks, drill-through e tooltips que reproduzam — ou melhorem — a experiência do usuário. Exige domínio técnico de Power BI e sensibilidade para não clonar uma interface que talvez nunca tenha sido boa, só familiar.

Etapas, objetivo e risco de cada fase da migração#

Etapa	Objetivo	Principal risco se for pulada ou malfeita
Inventário e racionalização	Migrar só o que gera valor, não todo o legado acumulado	Orçamento e prazo estourados; plataforma nova nasce tão desorganizada quanto a antiga
Mapeamento de regras e fontes	Extrair a lógica que hoje só existe em scripts e fórmulas	Regra de negócio se perde ou é recriada errada
Camada semântica governada	Centralizar dados e definições de negócio fora dos relatórios	Cada relatório repete lógica própria; manutenção segue tão cara quanto antes
Reconstrução em Power BI	Traduzir modelo e lógica em relatórios funcionais e performáticos	Modelo mal desenhado gera relatório lento ou DAX incorreto
Validação de paridade	Garantir que os números batem com os da ferramenta antiga	Usuário perde confiança e volta à ferramenta antiga ou à planilha paralela
Cutover faseado	Trocar de plataforma sem interromper a operação	Apagão de informação em relatórios críticos durante a transição
Gestão de mudança e treinamento	Garantir uso e confiança real na nova ferramenta	Entrega tecnicamente correta, mas ROI não se realiza por baixa adoção

Paridade de números é o critério que decide se a migração foi bem-sucedida#

Nenhuma etapa gera mais desconfiança do que a validação de paridade: comparar, relatório por relatório, o resultado no Power BI com o que a ferramenta de origem produzia, até a diferença ser explicável (arredondamento, correção proposital) ou inexistente.

Sem esse processo formal, a migração se apoia na confiança cega de que "a lógica foi traduzida certo" — e o primeiro sinal de erro costuma chegar do jeito mais caro: um diretor perguntando por que o número mudou. Uma boa validação inclui:

• Rodar o relatório antigo e o novo lado a lado, com o mesmo recorte de filtros e período.
• Envolver o dono de negócio na validação, não só o time técnico — ele reconhece se um número "parece certo".
• Documentar cada divergência, sua causa e a decisão tomada.
• Definir critério de aceite explícito por relatório antes de liberá-lo — sem isso, "está pronto" vira opinião.

É trabalho lento, mas é o que separa uma migração que o negócio confia de uma que apenas tolera. Em projetos com centenas de relatórios, como o que já conduzimos saindo de QlikView, essa validação é o maior consumidor de tempo depois da reconstrução — e cortar caminho aqui é a decisão mais arriscada do projeto.

Cutover sem apagão: por que big bang é o erro mais caro de uma migração de BI#

Desligar a plataforma antiga em uma data e ligar a nova no dia seguinte parece mais simples de vender internamente. Na prática, é o que mais aumenta o risco de apagão: se um relatório crítico tiver um problema não identificado, a empresa fica sem aquele dado justamente em um fechamento ou decisão importante.

O caminho recomendado é o cutover faseado, com as duas plataformas rodando em paralelo por um período definido:

• Migrar por ondas, começando por áreas de menor criticidade, não pelas mais visíveis.
• Manter QlikView ou Tableau ativos durante a homologação de cada onda, para comparação direta.
• Definir critério objetivo de homologação (paridade validada, usuários-chave aprovaram, sem chamado crítico aberto) antes de avançar.
• Só desligar a ferramenta antiga depois da última onda homologada e de um período de estabilização sem incidentes.

Esse desenho custa mais tempo de calendário e exige orçamento para duas licenças em paralelo. Mas o custo de um apagão em relatório financeiro ou operacional crítico costuma ser muito maior do que rodar em paralelo por mais algumas semanas.

Adoção não acontece sozinha: gestão de mudança decide se a migração vira ROI#

É comum um projeto tecnicamente impecável — dados corretos, performance boa, paridade validada — fracassar porque os usuários simplesmente não adotam a nova ferramenta. Isso acontece quando gestão de mudança vira detalhe de comunicação de última hora, em vez de trabalho contínuo desde o início.

O que costuma funcionar:

• Envolver usuários-chave desde o inventário, não só na entrega final — quem participa da decisão defende a mudança, não resiste a ela.
• Treinar por perfil de uso: quem só consome dashboard precisa de algo bem diferente de quem constrói relatório.
• Manter um canal ativo de suporte durante a transição — a maior fonte de desconfiança é a sensação de estar sozinho diante de um número estranho.
• Comunicar com clareza o que mudou de propósito (uma métrica corrigida) e o que é só diferença de interface, sem misturar os dois tipos de dúvida.

Sem esse trabalho, mesmo com meses de execução técnica sólida, é comum encontrar usuários exportando dados do Power BI para recriar, à mão, a mesma planilha paralela que a migração deveria eliminar.

De QlikView e Tableau para Power BI: equivalência de conceitos#

Conceito em QlikView / Qlik Sense / Tableau	Equivalente no Power BI
Script de carga (QlikView/Qlik Sense)	Power Query (M)
Set analysis (expressões condicionais)	Medidas DAX com CALCULATE e filtros de contexto
Modelo associativo (motor QIX)	Modelo tabular com relacionamentos estrela/snowflake
Calculated fields (Tableau)	Colunas calculadas e medidas DAX
Extratos .hyper (Tableau)	Modo Import (compressão VertiPaq)
Live connection (Tableau)	DirectQuery
Seções de acesso / segurança por documento	Row-Level Security (RLS) por perfil
Dashboards e sheets / apps e folhas (Qlik)	Relatórios e páginas no Power BI Desktop/Service
QlikView Server / Qlik Sense Enterprise / Tableau Server	Power BI Service (workspaces, capacidade Premium/Fabric)
Alertas e assinaturas	Alertas de dados e assinaturas de relatório no Power BI Service

Essa tabela é ponto de partida, não tradução automática — cada linha exige julgamento sobre volume de dados, frequência de atualização e comportamento esperado. Se ainda está avaliando se Power BI é a ferramenta certa para o seu contexto, vale complementar com nossa comparação entre Power BI, Tableau e Looker.

Os erros que mais derrubam uma migração de plataforma de BI#

• Migrar tudo às cegas. Reconstruir cada relatório existente sem racionalizar infla prazo, custo e a desorganização do ambiente novo.
• Big bang sem paralelo. Desligar a plataforma antiga antes de homologar a nova gera apagão em momentos críticos do negócio.
• Ignorar a gestão de mudança. Tratar treinamento como formalidade final, não trabalho contínuo, garante baixa adoção mesmo com entrega correta.
• Pular a validação de paridade. Confiar que a tradução "deve estar certa" sem comparar número a número é a forma mais rápida de perder a confiança do negócio.
• Reconstruir regra de negócio dentro de cada relatório. Sem camada semântica governada, a plataforma nova herda o mesmo problema de manutenção da antiga.
• Não envolver os donos de negócio no mapeamento. Só o time técnico decidir o que uma métrica "deveria" significar gera retrabalho quando o usuário final discorda.
• Subestimar fontes de dados legadas. Extrações manuais e integrações improvisadas que alimentavam o QlikView ou o Tableau raramente têm documentação, e sempre consomem mais tempo do que o estimado.

Nenhum desses erros é puramente técnico — todos são de planejamento e processo, o que reforça por que migração bem-sucedida é projeto de gestão de risco com componente técnico, não o contrário. Veja como isso se traduziu na prática em um dos nossos cases de migração de Qlik para Power BI.

Perguntas frequentes#

Quanto tempo leva para migrar de QlikView ou Tableau para Power BI? Depende do volume de relatórios que sobrevive à racionalização, da complexidade das regras mapeadas e do número de fontes envolvidas. Projetos pequenos, já racionalizados, podem levar semanas; migrações de grande porte, com centenas de relatórios e fontes heterogêneas, costumam levar meses, considerando o cutover em paralelo.

É possível migrar sem reescrever a lógica de negócio do zero? Parcialmente. Boa parte da transformação e do cálculo precisa ser reescrita, porque a sintaxe de QlikView e Tableau não se traduz automaticamente para DAX ou Power Query. Mas o mapeamento cuidadoso evita reinventar a lógica — o objetivo é traduzir com fidelidade, corrigindo só o que já estava errado.

Dá para migrar aos poucos, por área ou departamento? Sim, e é a abordagem que recomendamos. Migrar por ondas — começando pelas áreas de menor criticidade — reduz risco, permite ajustar o processo com o aprendizado das primeiras ondas e evita o apagão característico de uma troca "tudo de uma vez".

Como garantir que os números do Power BI batem com os da ferramenta antiga? Com processo formal de validação de paridade: comparar relatório a relatório, com os mesmos filtros e período, envolvendo o dono de negócio e documentando toda divergência até ela ser explicável ou corrigida. Pular essa etapa é o erro que mais compromete a confiança na nova plataforma.

Vale a pena aproveitar a migração para reorganizar o data warehouse? Quase sempre, sim. Migrar a lógica de negócio para dentro de cada relatório novo, sem centralizá-la em camada semântica governada, recria o mesmo problema de manutenção. É o momento certo para investir em engenharia de dados e consolidar definições de métrica que antes viviam espalhadas.

O que fazer com usuários que preferem a ferramenta antiga? É normal — mudança de ferramenta gera resistência, especialmente entre quem já domina atalhos da plataforma anterior. O que reduz isso é envolver usuários-chave desde o início, treinar por perfil de uso e manter suporte ativo durante a transição, em vez de ignorar a resistência.

Migrar bem é reduzir risco, não só trocar de ferramenta#

Migrar de QlikView, Qlik Sense ou Tableau para Power BI é oportunidade real de reduzir custo de licenciamento, consolidar ecossistema e arrumar anos de lógica de negócio espalhada e não documentada — mas só quando o projeto tem rigor de inventário, mapeamento, camada semântica, validação de paridade e cutover faseado. Empresas que tratam isso como "reconstruir telas" tendem a repetir, na plataforma nova, os mesmos problemas que motivaram a migração.

Se sua empresa está avaliando ou já decidiu migrar e quer reduzir o risco de apagão de informação, perda de confiança nos números ou baixa adoção, fale com a gente — já conduzimos migrações de grande porte, incluindo mais de 1.200 relatórios de QlikView reconstruídos em Power BI, e podemos olhar seu cenário atual antes de recomendar qualquer caminho.