Fim do Power BI Premium P1: como migrar para o Microsoft Fabric

As capacidades Power BI Premium por capacidade, conhecidas pelas SKUs P1, P2, P3, P4 e P5, estão sendo substituídas pelas capacidades do Microsoft Fabric.

A mudança não significa o fim dos recursos Premium do Power BI. Esses recursos passam a fazer parte de uma plataforma mais ampla, que reúne Power BI, engenharia de dados, integração, ciência de dados, Data Warehouse, Lakehouse e análise em tempo real.

Para empresas que utilizam uma capacidade P1, a migração normalmente começa pela avaliação de uma capacidade Fabric F64, que possui 64 Capacity Units e corresponde à faixa de processamento da antiga P1.

Ponto principal: a migração não deve ser tratada apenas como uma troca de nome ou de SKU. Ela é uma oportunidade para revisar consumo, workspaces, licenciamento, arquitetura e forma de distribuição dos relatórios.

O Power BI Premium P1 realmente acabou?

A Microsoft encerrou a venda e a renovação das SKUs Power BI Premium por capacidade. Os clientes existentes podem continuar utilizando sua capacidade P até o término do contrato vigente, mas precisam migrar para uma capacidade Fabric na renovação.

A própria Microsoft informa que os recursos corporativos anteriormente disponíveis no Power BI Premium continuam disponíveis por meio das capacidades Fabric.

Consulte os comunicados oficiais:

• Período de transição do Power BI Premium para Microsoft Fabric
• Encerrar, cancelar ou migrar uma capacidade Fabric e Power BI
• Entender as licenças do Microsoft Fabric

Qual capacidade Fabric substitui a P1?

A equivalência de referência é:

| Power BI Premium | Microsoft Fabric | Capacity Units | Power BI v-cores | |---|---:|---:|---:| | P1 | F64 | 64 CUs | 8 | | P2 | F128 | 128 CUs | 16 | | P3 | F256 | 256 CUs | 32 | | P4 | F512 | 512 CUs | 64 | | P5 | F1024 | 1.024 CUs | 128 |

Portanto, uma organização que utiliza P1 tende a iniciar a análise pela F64.

Entretanto, escolher a mesma equivalência não elimina a necessidade de revisar o uso real. Algumas empresas utilizam apenas uma parte da capacidade P1, enquanto outras operam próximas do limite ou convivem com picos, atrasos e throttling.

A documentação oficial apresenta a relação entre SKUs, CUs e equivalências em Power BI Premium e capacidades.

Por que não migrar automaticamente de P1 para F64?

A migração direta pode ser adequada, mas nem sempre é a melhor decisão financeira ou técnica.

Antes de contratar a F64, avalie:

• consumo médio e picos de CUs;
• quantidade de workspaces associados;
• relatórios mais acessados;
• atualizações simultâneas;
• modelos semânticos com maior consumo;
• consultas lentas;
• operações interativas e em segundo plano;
• horários de maior utilização;
• necessidade de usuários gratuitos no Power BI Service;
• uso futuro de Lakehouse, Warehouse, notebooks e Data Factory.

Uma capacidade historicamente superdimensionada pode ser reduzida. Uma capacidade pressionada pode precisar de otimização ou de uma SKU superior.

F64 é obrigatória para usuários gratuitos?

Depende da forma de acesso.

No modelo tradicional do Power BI Service, uma capacidade F64 ou superior permite que usuários com licença gratuita visualizem conteúdo hospedado na capacidade, desde que tenham as permissões adequadas e atuem como visualizadores.

Em capacidades menores que F64, como F8, F16 ou F32, os usuários normalmente precisam de Power BI Pro ou PPU para consumir o conteúdo diretamente no serviço.

A Microsoft detalha essa regra em Recursos do Power BI por tipo de licença e em Recursos para usuários gratuitos do Power BI.

Um portal pode permitir o uso de uma capacidade menor?

Sim. Essa é uma alternativa relevante para empresas que utilizavam P1 principalmente para distribuir relatórios a muitos visualizadores.

No modelo App Owns Data, os relatórios são apresentados dentro de um portal ou aplicação autenticada. O sistema controla os usuários, solicita o token de incorporação e apresenta apenas os conteúdos autorizados.

Nesse cenário, a empresa pode avaliar uma capacidade Fabric menor que F64 ou uma capacidade Power BI Embedded da família A, dependendo do uso e da arquitetura.

Isso pode fazer sentido quando:

• os usuários apenas visualizam relatórios;
• o acesso ocorre por um portal próprio;
• há centenas ou milhares de visualizadores;
• existe necessidade de white-label;
• os usuários são clientes, fornecedores, franquias ou parceiros;
• a organização não precisa manter o acesso pelo Power BI Service para todos;
• o custo de licenças individuais é elevado.

Para entender essa arquitetura, consulte Como utilizar uma licença Fabric em portais Power BI.

F64, F32 com portal ou Power BI Embedded A4?

As três arquiteturas podem atender cenários diferentes.

| Cenário | Alternativa comum | |---|---| | Usuários gratuitos acessando pelo Power BI Service | F64 ou superior | | Usuários Pro acessando pelo Power BI Service | F menor pode ser suficiente | | Clientes e parceiros acessando por portal | Fabric menor ou Embedded A | | Uso completo da suíte Fabric | Capacidade F | | Somente incorporação de Power BI | Capacidade A pode ser avaliada | | Necessidade equivalente à antiga P1 | F64 como referência inicial |

A capacidade A4 também aparece como equivalente técnico da faixa P1/F64 para Power BI Embedded. Porém, capacidades A são voltadas principalmente à incorporação e não entregam toda a suíte Microsoft Fabric.

Veja a documentação de capacidade e SKUs no Power BI Embedded.

Checklist para migrar da P1 para o Fabric

1. Identifique a data de renovação

Confirme quando termina o contrato atual da P1 e quanto tempo existe para planejar a transição.

Não deixe a avaliação para os últimos dias. A contratação da capacidade, os testes e a movimentação dos workspaces precisam ser organizados com antecedência.

2. Faça um inventário do ambiente

Liste:

• capacidades atuais;
• workspaces;
• relatórios;
• modelos semânticos;
• dataflows;
• pipelines;
• gateways;
• fontes de dados;
• proprietários;
• usuários e grupos;
• agendas de atualização;
• dependências entre conteúdos.

Um inventário evita que workspaces esquecidos, relatórios sem proprietário ou atualizações críticas sejam ignorados na migração.

3. Analise o consumo da capacidade

Utilize o aplicativo Microsoft Fabric Capacity Metrics para revisar:

• utilização por período;
• consumo por workspace;
• consumo por item;
• operações interativas;
• operações em segundo plano;
• picos de CUs;
• rejeições;
• delays;
• throttling;
• duração das atualizações.

A Microsoft também disponibiliza orientações para planejar o tamanho da capacidade.

4. Classifique os workspaces

Nem todos os workspaces precisam obrigatoriamente permanecer na mesma capacidade.

Separe-os por:

• criticidade;
• área de negócio;
• volume de usuários;
• consumo;
• horário de operação;
• tipo de carga;
• ambiente de desenvolvimento, homologação ou produção.

Essa divisão ajuda a avaliar se uma única F64 é suficiente ou se a organização pode distribuir cargas entre capacidades menores.

5. Revise o licenciamento dos usuários

Confirme quem:

• desenvolve relatórios;
• publica conteúdos;
• administra workspaces;
• apenas visualiza;
• precisa entrar no Power BI Service;
• pode acessar por portal.

Essa etapa é decisiva para comparar F64, capacidades menores com Pro, portal Embedded ou uma arquitetura híbrida.

6. Contrate a capacidade Fabric

A capacidade F é adquirida no Azure e associada ao tenant do Microsoft Fabric.

A contratação permite escolher região, grupo de recursos, assinatura e tamanho da SKU. Capacidades Fabric também podem ser pausadas, retomadas ou redimensionadas conforme as regras da oferta.

Consulte Comprar uma assinatura do Microsoft Fabric.

7. Associe os workspaces à nova capacidade

Após provisionar a capacidade, mova os workspaces de forma controlada.

A Microsoft alerta que, ao reatribuir um workspace, trabalhos ativos podem ser cancelados. Por isso, programe a mudança fora dos períodos críticos e execute novamente os processos interrompidos.

8. Teste relatórios e atualizações

Valide:

• abertura dos relatórios;
• desempenho das consultas;
• RLS e OLS;
• atualização agendada;
• conexão com gateway;
• dataflows;
• relatórios paginados;
• XMLA;
• APIs;
• aplicativos do Power BI;
• permissões dos usuários.

9. Monitore após a migração

A migração não termina quando o workspace é movido.

Acompanhe o comportamento da nova capacidade por algumas semanas para identificar:

• aumento de consumo;
• horários de saturação;
• atualizações concorrentes;
• modelos que precisam ser otimizados;
• workspaces que deveriam ser separados;
• necessidade de redimensionamento.

Existe período de transição após o vencimento?

A Microsoft informa que, após o término da assinatura ou da capacidade Premium, pode existir um período de 90 dias de acesso completo para apoiar a transição.

Esse período não deve ser tratado como substituto de um planejamento adequado. O ideal é contratar e testar a nova capacidade antes do encerramento da P1.

Consulte a orientação oficial em Migrar uma capacidade P SKU em expiração.

Erros comuns durante a migração

Escolher a SKU apenas pela equivalência

P1 e F64 são equivalentes em faixa de capacidade, mas o consumo real precisa ser analisado.

Ignorar operações em segundo plano

Atualizações, dataflows, notebooks e cargas de engenharia podem competir com as consultas dos usuários.

Migrar todos os workspaces ao mesmo tempo

Uma transição em ondas reduz riscos e facilita a comparação de desempenho.

Não revisar as licenças

Uma F menor que F64 pode alterar a experiência dos usuários que acessam diretamente o Power BI Service.

Não testar RLS e permissões

A migração deve preservar as regras de acesso, grupos e identidades.

Não monitorar a capacidade

Sem métricas, a empresa pode aumentar a SKU quando o problema real está em um modelo, atualização ou consulta específica.

Quando considerar um portal durante a migração?

Um portal pode ser avaliado quando a organização percebe que mantém uma P1 ou F64 principalmente para entregar relatórios a visualizadores.

Com um portal Power BI Embedded, é possível estruturar:

• autenticação própria;
• controle individual de usuários;
• menus e permissões por relatório;
• RLS;
• domínio próprio;
• white-label;
• auditoria de acessos;
• distribuição para clientes e parceiros;
• uso de capacidade Fabric menor ou Embedded A, conforme o dimensionamento.

Essa arquitetura não substitui automaticamente a F64 em todos os casos. Ela cria uma alternativa para cenários nos quais o acesso pelo Power BI Service não é obrigatório para todos os usuários.

Conclusão

O fim das SKUs Power BI Premium P não representa o fim do Power BI Premium. Os recursos passam a ser entregues por meio das capacidades Microsoft Fabric.

Para uma P1, a F64 é a equivalência inicial mais direta. Entretanto, a melhor migração depende de consumo, usuários, licenciamento, cargas de trabalho e forma de distribuição.

A decisão pode resultar em:

• migração direta para F64;
• adoção de uma capacidade Fabric superior;
• redução para uma F menor com usuários Pro;
• uso de uma F menor com portal Embedded;
• adoção de Power BI Embedded A;
• arquitetura híbrida com diferentes capacidades.

O principal é tratar a mudança como um projeto de arquitetura e FinOps, não apenas como uma renovação de licença.