QlikView fim de suporte: o que muda em 2026 e as três opções que tem

Se a sua empresa ainda corre QlikView, há três factos que condicionam qualquer decisão sobre BI nos próximos meses. Verificámo-los em outubro de 2026 nas páginas oficiais da Qlik, e as fontes estão no fim deste artigo.

Os três factos

1. A Qlik deixou de vender licenças novas de QlikView isolado. Crescer em utilizadores ou em servidores passou a significar Qlik Cloud, com o seu próprio preçário e o seu próprio modelo de subscrição.

2. O QlikView 12.90 fica sem suporte a 31 de outubro de 2026. Cada versão do QlikView tem cerca de dois anos de ciclo de vida. Cada atualização é um projeto por si: testes de regressão, janelas de paragem, scripts que deixam de compilar.

3. O caminho oficial leva ao Qlik Cloud. As ferramentas de migração da Qlik convertem os ficheiros .qvw para o Qlik Cloud. Os seus scripts de carga e o seu modelo de dados não vão inalterados, e o contador de licenças recomeça do zero.

Nenhum destes factos obriga a reescrever o que tem. A lógica dentro das suas aplicações continua válida: as tabelas, as chaves, as métricas e as regras de negócio que a sua equipa afinou durante anos. O que está em causa é o motor por baixo.

Opção 1: ficar no QlikView sem suporte

É a opção mais barata no curto prazo e a mais cara no médio. Sem suporte, cada falha de segurança fica por corrigir, cada incompatibilidade com um novo Windows Server ou com um novo browser fica por resolver, e cada pessoa que sai da equipa leva consigo conhecimento de uma ferramenta que já ninguém aprende. A auditoria interna e os seguros de cibersegurança tendem a perguntar por software sem suporte.

Quem escolhe esta opção costuma fazê-lo por falta de tempo para decidir, não por convicção. O risco acumula-se em silêncio.

Opção 2: migrar para o Qlik Cloud

É o caminho que a Qlik desenha. Tem vantagens reais: suporte ativo, atualizações automáticas, sem servidores para manter. Tem também três custos que convém ver antes de assinar:

As licenças recomeçam. O investimento feito em licenças perpétuas de QlikView não transita. Paga-se por utilizador, todos os anos, para sempre.
Os scripts não passam inalterados. O modelo de dados e os scripts de carga precisam de revisão. A migração é um projeto, não um clique.
A dependência mantém-se. Troca-se um fornecedor por si próprio numa versão mais cara. Daqui a dois anos a decisão volta a ser da Qlik, não sua.

Para empresas em que o BI é uma peça pequena e o orçamento de licenças não pesa, pode ser a opção certa. Para quem tem dezenas ou centenas de utilizadores, o custo recorrente por utilizador é normalmente o argumento decisivo contra.

Opção 3: migrar para componentes abertos

É a opção que a QuickBytes implementa. A ideia é simples: cada aplicação de BI é mapeada, não reescrita. Os utilizadores veem o mesmo dashboard. O IT vê SQL normal.

O que acontece a cada peça do QlikView:

Peça do QlikView	Para onde vai
Scripts de carga e transformação	Arquitetura Medallion em PostgreSQL, construída com dbt, com metadados e linhagem no OpenMetadata
Modelo de dados, chaves e regras de negócio	Tabelas normais em PostgreSQL, consultáveis por qualquer ferramenta
Motor em memória	DuckDB sobre ficheiros Parquet, com respostas em segundos
Dashboards	Dashboard dinâmico com dimensões e métricas escolhidas num painel lateral, linha de totais, relatórios guardados, exportação Excel e CSV
Regras de acesso (section access)	Permissões por perfil e filtros por entidade, aplicados na API

O que muda de facto é o que está na tabela seguinte.

Aspeto	QlikView hoje	Com componentes abertos
Licenças	Por utilizador e por servidor, com renovações crescentes	Nenhumas. PostgreSQL, DuckDB e Parquet são open source
Motor	Servidor dedicado e motor em memória fechado	DuckDB sobre Parquet, com PostgreSQL como sistema de registo
Posse dos dados	Dentro de ficheiros .qvd e .qvw	Tabelas normais e ficheiros em colunas
Suporte	Ciclo do fornecedor, cerca de dois anos por versão	A sua equipa, ou a nossa, em competências normais: SQL, dbt, .NET e React
Evolução	Limitada ao que o fornecedor lança	Novas métricas e dashboards acrescentados pelas suas pessoas

Como se faz a migração sem big bang

O processo tem quatro passos, e o seu QlikView fica ligado até ao último.

1. Inventário. Lemos as aplicações e os scripts de carga, listamos cada tabela, campo, métrica e dashboard, e dizemos-lhe o que mapeia diretamente e o que pede decisão.
2. Arquitetura Medallion e Parquet. O modelo de dados é reconstruído em PostgreSQL com dbt, com tabelas de reconciliação e catálogo de metadados. Cada build exporta uma geração Parquet.
3. Serviço DuckDB e dashboard. Um serviço analítico DuckDB carrega a geração ativa. O dashboard dinâmico corre sobre ele, com as suas dimensões, as suas métricas e as suas regras de acesso.
4. Paridade e entrada em produção. Os valores são comparados com o QlikView, entidade a entidade e mês a mês, até baterem certo. Só depois se desliga o antigo.

Num caso real, já em produção, uma agregação por produto que demorava cerca de 6 minutos em PostgreSQL passou a ter resposta do DuckDB sobre Parquet enquanto o utilizador espera. Os valores de vendas com e sem IVA, valor de stock, valor pago pelo cliente e valor médio por transação foram reconciliados com o BI legado, por centro e por mês, de janeiro a agosto de 2026. Pode ler o caso completo.

O que fazer esta semana

Se tem QlikView em produção, a decisão não precisa de ser tomada hoje, mas o inventário sim. Saber quantas aplicações tem, quantos scripts, quantos utilizadores e que regras de acesso existem é o que permite comparar as três opções com números em vez de impressões.

A QuickBytes faz esse inventário sobre uma das suas aplicações reais, com NDA mútuo antes de qualquer partilha de dados, e mostra o dashboard dinâmico a correr sobre o novo motor. Agende uma apresentação de 30 minutos.

Fontes

Qlik, ciclo de vida de suporte do QlikView: community.qlik.com, Product Support Lifecycle
Qlik, migração de QlikView para o Qlik Cloud: community.qlik.com, Migrating QlikView