Visão geral da migração do Power BI Premium para Microsoft Fabric

A Microsoft está a descontinuar os SKUs Premium por capacidade do Power BI (SKUs P). Cada subscrição da SKU P termina no final do prazo atual do acordo, e a Microsoft deixa de vender novas SKUs P. Para manter as suas cargas de trabalho do Power BI a funcionar, migre para SKUs de capacidade do Microsoft Fabric (SKUs F). Este artigo oferece-lhe uma visão completa da migração: porque é que as SKUs Fabric F são o caminho a seguir, o que muda e o que se mantém igual para utilizadores finais e administradores, as etapas de uma migração típica e os cenários que determinam a complexidade da sua migração.

Este artigo destina-se a administradores de Fabric, administradores de Power BI, arquitetos de TI e responsáveis pela capacidade que planeiam e executam a migração.

Importante

Planeie concluir a sua migração antes do fim da sua subscrição do P SKU. Após o fim da sua subscrição, a sua capacidade entra num período de carência de 30 dias. A partir do dia 31, o acesso é restringido (as operações interativas sofrem atrasos). No dia 91 e seguintes, todas as operações são rejeitadas – os seus dados são mantidos mas inacessíveis até migrar os espaços de trabalho para uma capacidade de SKU Fabric F ou eliminar essa capacidade. Para evitar interrupções, reatribua os seus espaços de trabalho a uma capacidade Fabric F SKU antes de a sua subscrição P SKU terminar. Para o procedimento, consulte Migrar espaços de trabalho do Power BI Premium para o Microsoft Fabric.

Note

Clientes com Enterprise Agreement. Se o seu Acordo Empresarial ainda estiver ativo, pode continuar a operar a capacidade existente do SKU P e renová-la anualmente através do seu acordo até ao fim do prazo EA. Clientes com Acordos Empresariais a expirar ou Acordos Microsoft Cloud não podem adicionar ou comprar nova capacidade de SKU P através do seu acordo. Confirme os termos específicos do seu contrato com o seu representante da conta Microsoft antes de decidir quando migrar.

Note

Esta descontinuação tem duas limitações de âmbito importantes:

As licenças por utilizador não são afetadas.Power BI Pro e Power BI Premium Per Utilizador (PPU) continuam as-is. Para mais detalhes, consulte O Power BI Premium Per User (PPU) também vai ser descontinuado?
As licenças embutidas (EM, A) não são afetadas. Estas SKUs não fazem parte desta descontinuação.
As nuvens soberanas ainda não foram afetadas. O Microsoft Fabric não está disponível em nuvens soberanas, pelo que os SKUs P continuam a ter suporte nessas nuvens. A Microsoft fornece orientações separadas quando o Fabric se torna disponível nesses ambientes.

Por que migrar para o Microsoft Fabric

A descontinuação das SKUs P é o fator imediato, mas as SKUs Fabric F também disponibilizam funcionalidades que as SKUs P não permitem:

Pague apenas por aquilo que utiliza. As SKUs F utilizam, por predefinição, a faturação pay as you go do Azure, com reservas anuais ou de vários anos opcionais para cargas de trabalho previsíveis. Também pode pausar uma capacidade quando estiver inativa para suspender a faturação durante os períodos de inatividade e retomá-la mais tarde, conforme necessário.
Aumente ou reduza a qualquer momento. Redimensione as capacidades através do portal Azure à medida que as suas cargas de trabalho mudam, em vez de se comprometer com um tamanho fixo durante o período da subscrição.
Use o modelo operativo nativo do Azure. Provisione e gere a capacidade através do portal Azure, aplique etiquetas Azure para chargeback e conte o gasto Fabric para o seu Compromisso de Consumo Microsoft Azure (MACC). Muitas cargas de trabalho do Fabric (como Lakehouses, Warehouses, Notebooks e pipelines do Data Factory) são executadas em capacidades P ou F, mas o modelo operacional do Azure suporta apenas F.
Utilize o Power BI Embedded sem SKUs distintos. Os cenários incorporados são abrangidos por todos os SKU F, pelo que não precisa de SKU EM ou A separados.
Use segurança e operações nativas do Azure. Os pontos finais privados geridos, o acesso a áreas de trabalho fidedignas, o Azure Monitor e o Microsoft Cost Management estão disponíveis com SKUs F.

Para a comparação completa funcionalidade por funcionalidade, consulte Principais diferenças entre os SKUs P do Power BI Premium e os SKUs F do Fabric.

O que muda e o que permanece igual

A migração envolve principalmente uma alteração de licenciamento e infraestrutura. As experiências dos utilizadores finais e a maioria dos comportamentos administrativos mantêm-se iguais. Algumas áreas operacionais mudam.

Área	Mudar?	Depois de migrar para o SKU F
Relatórios, modelos semânticos, dashboards	Same	Continuam a funcionar sem alterações em capacidades F64 ou superiores.
Licenças de utilizador (Pro, PPU, Gratuitas)	Same	Inalterado. No F64 e superiores, os utilizadores com uma licença Fabric Free e a função Viewer podem visualizar conteúdo, à semelhança do que acontece nos SKUs P. De F2 a F32, todos os espetadores precisam de uma licença Pro ou PPU.
Espaços de trabalho e aplicações	Same	Os espaços de trabalho são realocados para a nova capacidade. As aplicações do espaço de trabalho, os pipelines de implementação e a integração com o Git continuam a funcionar.
Agendamentos de atualização e pipelines	Same	Continua a funcionar com a nova capacidade. As atualizações em curso podem ser interrompidas durante a reatribuição.
Power BI Report Server	O mesmo, com a alteração da licença	Continua disponível com uma reserva de capacidade do Fabric ou com o SQL Server Enterprise Edition com Software Assurance.
Power BI Embedded	Igual, mais simples	Incluído em todas as SKUs F. Não são necessários SKUs separados para EM e A.
Compra e faturação	Changes	Passar da faturação com compromisso do Microsoft 365 para a faturação do Azure. Os SKUs F suportam pagamento conforme a utilização e reservas anuais ou plurianuais.
Gestão da capacidade	Changes	Principalmente gerido através do portal Fabric (atribuições de espaços de trabalho e definições de capacidade). As operações de pausa, retomar, aumentar e diminuir são realizadas através do portal Azure.
Autoscale	Changes	O Autoscale do P SKU não existe nos SKUs F. Em vez disso, as SKUs F utilizam redimensionamento a pedido — pode aumentar ou reduzir a escala manualmente no portal do Azure.
Governação da capacidade	Novas capacidades	Novas funcionalidades de governação de custos estão disponíveis nas SKUs F, como proteção contra picos ao nível do espaço de trabalho e proteção contra excedência de capacidade. Use-os para controlar o consumo e evitar custos descontrolados.
Suporte de itens inter-regiões	Nova consideração	Itens padrão do Power BI sobrevivem a uma reatribuição entre regiões. Modelos semânticos de grande formato de armazenamento requerem backup e restauro ou limpeza e conversão para formato de armazenamento pequeno antes da reatribuição. Todos os itens do Fabric (Lakehouses, Armazéns, Notebooks, pipelines do Data Factory) fazem falhar a reatribuição.

A viagem migratória num olhar

Na sua forma mais pura, a migração P-para-F é uma transferência 1:1 para o SKU F equivalente na mesma região do Azure. Os clientes usam frequentemente a migração como uma oportunidade para consolidar capacidades, mudar de região ou redimensionar. Cada uma destas mudanças acrescenta complexidade e risco. Trate estas alterações como fluxos de trabalho separados que correm após a conclusão da migração de licenciamentos.

A migração segue as mesmas cinco etapas, independentemente do tamanho ou complexidade.

Decida. Escolhe quando migrar, com que SKU F começar e se queres ficar na mesma região do Azure. Consulte o guia de decisão de migração do SKU P do Power BI Premium.
Plano. Faça o inventário dos espaços de trabalho, estabeleça o consumo de CU de referência utilizando a aplicação Microsoft Fabric Capacity Metrics e estime o consumo futuro com o Fabric SKU Estimator. Regista o Microsoft.Fabric fornecedor de recursos no Azure e escolhe um espaço de trabalho piloto. Para validação prática antes da compra, disponibilize uma capacidade de teste do Fabric para testar cargas de trabalho.
Aprovisionamento Compra o SKU F antes de reatribuires qualquer coisa. Escolha o pagamento conforme a utilização ou uma reserva e verifique o licenciamento do Power BI Report Server, caso o utilize.
Migrar e validar. Reatribuir espaços de trabalho no portal de administração do Fabric ou usando o caderno de migração de capacidade. Para migrações entre regiões, recrie modelos semânticos com formato de armazenamento grande e itens do Fabric na nova região. Validar atualizações, relatórios e portas de ligação. Veja Migrar espaços de trabalho do Power BI Premium para o Microsoft Fabric.
Descomissionar e operar. O cancelamento do SKU P é manual - o Fabric não descomissiona automaticamente o seu SKU P quando aprovisiona um SKU F. Depois de validares a migração, cancela explicitamente a subscrição do SKU P no centro de administração do Microsoft 365. Depois, configure a monitorização de custos utilizando o Microsoft Cost Management e aproveite a flexibilidade de pausa, retoma e escalabilidade no Fabric.

Cenários de migração

A maioria dos clientes enquadra-se num dos seguintes quatro cenários. Os três primeiros cenários seguem os passos padrão de migração dos espaços de trabalho do Power BI Premium para o Microsoft Fabric.

Scenario	Complexidade	Notes
Mesmo inquilino, mesma região	Baixo	O padrão recomendado. Reatribui cada espaço de trabalho ao novo SKU F. Zero tempo de indisponibilidade esperado, exceto por atualizações ativas.
Mesmo locatário, entre regiões	Moderado a elevado	Segue os passos padrão de migração, mas modelos semânticos de grande formato de armazenamento e itens Fabric devem ser copiados ou capturados no Git, eliminados e recriados na nova região. Ver Migrações entre regiões: Tratamento especial.
Multigeo (várias SKUs F em diferentes regiões, mesmo locatário)	Moderado	Segue os passos padrão de migração, mas adquire SKUs F em cada região-alvo e planeia a governação dos conteúdos específicos de cada região. Consulte Migrações Multigeo.
Inquilino cruzado	Alto; não suportado como migração com um clique	Não segue os passos padrão de migração. Requer a recriação manual de gateways, modelos semânticos, espaços de trabalho, relatórios, aplicações e dashboards. Considere primeiro o multigeo. Ver Migrações entre inquilinos.

Atenção

As migrações entre regiões envolvem significativamente mais esforço do que as migrações na mesma região. Para além dos tipos de itens que não sobrevivem à reatribuição entre regiões, planeie para:

Os itens Fabric não sobrevivem a movimentos entre regiões. Casas de lago, armazéns, cadernos e pipelines de fábricas de dados fazem com que a reatribuição falhe. Captura as definições deles para o Git (ou exporta-as) antes de as reatribuir, e depois recria-as na região de destino.
Reporte a religação. Quando fazes backup e restauras (ou apagas e reimplementas) um modelo semântico em grande formato de armazenamento, o modelo recriado recebe um novo GUID. Os relatórios que faziam referência ao modelo original têm de ser novamente associados ao modelo recriado.
Gateway por cima. Os destinos entre regiões requerem frequentemente configuração e validação adicionais dos gateways de dados no local, especialmente se os seus gateways utilizarem o Azure Relay no âmbito do Bring Your Own Relay (BYOR), porque os pontos finais dos relés estão vinculados à região.

Escolha migração entre regiões apenas quando a residência de dados ou outra restrição rígida o exigir. A migração para a mesma região é o padrão recomendado.

Depois de migrares

Depois de reatribuíres espaços de trabalho e validares que os relatórios e as atualizações funcionam no novo SKU F, concede-te um período de estabilização antes de cancelares o SKU P e antes de realizares qualquer trabalho opcional de modernização. As seguintes atividades ajudam-no a confirmar que a migração decorreu sem problemas e a decidir o que fazer a seguir.

Estabilizar o custo

O gasto com o SKU F é previsível se mantiver as capacidades em execução 24 horas por dia. O seu custo mensal mantém-se estável, embora as tarifas pay-as-you-go sejam normalmente mais elevadas do que as equivalentes do SKU P. Utilize reservas para assegurar poupanças em cargas de trabalho estáveis e utilize a pausa e a retoma para capacidades que estejam genuinamente inativas durante partes do dia. Para estabilizar custos:

Acompanhe os gastos diários durante os primeiros 30 dias utilizando o Microsoft Cost Management.
Defina orçamentos e alertas do Azure no grupo de recursos da capacidade para ser notificado antes de a despesa exceder o previsto.
Avalie uma reserva anual de capacidade Fabric quando o consumo diário estiver estável. As reservas normalmente descontam cargas de trabalho previsíveis.
Pause as capacidades que estejam inativas fora do horário comercial para interromper a faturação durante esses períodos.

Estabilizar o desempenho

Para uma migração 1:1 na mesma região para o SKU F equivalente, o consumo de CU deverá corresponder de perto ao valor de referência do SKU P após a estabilização. Espere variação de desempenho quando a migração incluir uma alteração de configuração – uma região diferente, um tamanho de SKU diferente ou consolidação de carga de trabalho – e valide antes de desmantelar o SKU P. Sobrecargas reportadas após a migração são frequentemente causadas por alterações na carga de trabalho (uma explosão de atualizações, conteúdo adicionado, alterações nos cronogramas de atualização) em vez da migração em si. Verifique os padrões de utilização antes de assumir que o SKU F é a causa. Para estabilizar o desempenho:

Monitorize a nova capacidade com a aplicação Microsoft Fabric Capacity Metrics durante uma a duas semanas após o corte.
Compara com a base que captaste no SKU P. Investigue grandes variações na frequência de atualização, no tamanho do conjunto de dados ou na carga de trabalho interativa antes de redimensionar.
Aumente a capacidade conforme necessário no portal do Azure, se verificar uma limitação persistente. Veja Aumente a sua capacidade.
Valide ao longo de um ciclo de atividade completo — inclua o fecho de fim do mês e o fecho trimestral — antes de considerar a referência como definitiva.
Verifique novamente a linha de base sempre que adicionar conteúdo novo significativo ou alterar os horários de atualização.
Revalide após qualquer alteração de configuração do seu lado (tamanho do SKU, região, atribuição de carga de trabalho).
Para orientações mais amplas sobre planeamento, crescimento de capacidade e governação, consulte o guia de planeamento de capacidade da Microsoft Fabric.

Revisão das operações e governação

Algumas definições operacionais não são transferidas automaticamente quando os espaços de trabalho passam para um SKU F. Reveja o seguinte:

Confirme as atribuições do Azure RBAC no recurso de capacidade para que os administradores certos possam gerir.
Volte a aplicar as definições da carga de trabalho ao nível da capacidade (por exemplo, limites de memória do modelo semântico) no portal de administração do Fabric, caso tenham sido personalizadas no SKU P.
Verifique novamente a definição de inquilino Os utilizadores podem criar itens do Fabric e quaisquer delegações ao nível da capacidade.
Aplique etiquetas do Azure ao recurso de capacidade para que os relatórios de chargeback e showback atribuam a despesa ao centro de custos correto.
Avalie as novas funcionalidades de governação de utilização de capacidade disponíveis nos SKUs F (como proteção contra picos ao nível do espaço de trabalho e proteção contra excedência de capacidade) para estabelecer limites antes de abrir a capacidade a um consumo mais amplo.

Explorar oportunidades de modernização

Muitos cenários de modernização do Fabric também são tecnicamente possíveis nos SKUs P. O que muda nos SKUs F é o modelo operacional: gestão de custos nativa do Azure, funcionalidades de governação de capacidade (como proteção contra picos e excessos) e RBAC unificado do Azure tornam mais fácil enfrentar estes cenários com guardas de custos mais claras e maior confiança operacional. Estas opções são seguimentos opcionais, não requisitos de migração:

Traga os dados existentes para o OneLake com Mirroring e Shortcuts.
Converta modelos semânticos DirectQuery para Direct Lake nos casos em que as cargas de trabalho beneficiem disso.
Adote a segurança OneLake para controlos unificados de acesso a dados em cargas de trabalho Fabric.

Trate estas opções como fluxos de trabalho separados que se executam após a conclusão da migração de licenciamentos. Não bloqueiam a migração e não deviam prolongar o seu prazo.

Comentários

Esta página foi útil?

Last updated on 2026-07-22