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

Microsoft está descontinuando os SKUs P (Premium por capacidade) do Power BI. Cada assinatura de SKU P termina no final de seu prazo de contrato atual e Microsoft não vende mais novas SKUs P. Para manter suas cargas de trabalho do Power BI funcionando, migre para SKUs de capacidade do Microsoft Fabric (F SKUs). Este artigo fornece uma visão de ponta a ponta da migração: por que Fabric SKUs F são o caminho a seguir, quais alterações e o que permanece o mesmo para usuários finais e administradores, os estágios de uma migração típica e os cenários que determinam o quão complexa é a migração.

Este artigo destina-se a administradores Fabric, administradores de Power BI, arquitetos de TI e proprietários de capacidade que planejam e executam a migração.

Importante

Planeje concluir a migração antes do término da assinatura do SKU P. Após o término da assinatura, sua capacidade entra em um período de carência de 30 dias. A partir do dia 31, o acesso é limitado (as operações interativas estão atrasadas). No 91º dia em diante, todas as operações são rejeitadas — seus dados são mantidos, mas ficam inacessíveis até que você migre os workspaces para uma capacidade Fabric F SKU ou exclua a capacidade. Para evitar interrupção, realoque seus workspaces para uma capacidade Fabric F SKU antes que sua assinatura do P SKU termine. Para ver o procedimento, consulte Migrar workspaces do Power BI Premium para o Microsoft Fabric.

Note

Clientes do Contrato Enterprise. Se o Contrato Enterprise ainda estiver ativo, você poderá continuar executando a capacidade de SKU P existente e renová-la anualmente por meio de seu contrato até que o prazo do EA termine. Os clientes com contratos empresariais expirando ou contratos de Microsoft Cloud não podem adicionar ou comprar novas capacidades de SKU P por meio de seu contrato. Confirme seus termos de contrato específicos com seu representante do conta Microsoft antes de decidir quando migrar.

Note

Essa aposentadoria tem dois limites de escopo importantes:

As licenças por usuário não são afetadas.Power BI Pro e Power BI PPU (Premium por Usuário) continuam as-is. Para obter detalhes, consulte O Power BI Premium por Usuário (PPU) também está sendo desativado?
Licenças inseridas (EM, A) não são afetadas. Esses SKUs não fazem parte dessa descontinuação.
Nuvens soberanas ainda não foram afetadas. Microsoft Fabric não está disponível em nuvens soberanas, portanto, os SKUs P permanecem com suporte lá. Microsoft fornece diretrizes separadas quando Fabric fica disponível nesses ambientes.

Por que migrar para Microsoft Fabric

A desativação das SKUs P é o principal fator imediato, mas as SKUs F do Fabric também oferecem recursos que as SKUs P não podem oferecer:

Pague apenas pelo que usar. As SKUs F usam por padrão a cobrança do Azure conforme o uso, com reservas anuais ou multianuais opcionais para cargas de trabalho previsíveis. Você também pode pausar uma capacidade quando ela estiver ociosa para interromper a cobrança fora do horário comercial e depois retomá-la sob demanda.
Aumente ou reduza a escala a qualquer momento. Redimensione as capacidades por meio do portal do Azure à medida que suas cargas de trabalho mudam, em vez de se comprometer com um tamanho fixo durante a vigência de uma assinatura.
Use o modelo operacional nativo do Azure. Provisione e gerencie a capacidade por meio do portal do Azure, aplique tags do Azure para chargeback e conte os gastos do Fabric para seu Compromisso de Consumo do Microsoft Azure (MACC). Muitas cargas de trabalho do Fabric (como Lakehouses, Warehouses, Notebooks e pipelines do Data Factory) usam capacidades P ou F, mas o modelo operacional do Azure é apenas F.
Use o Power BI Embedded sem SKUs distintos. Os cenários inseridos são cobertos por cada SKU F, portanto, você não precisa de SKUs EM ou A separados.
Use a segurança e as operações nativas do Azure. Endpoints privados gerenciados, acesso confiável ao espaço de trabalho, Azure Monitor e Gerenciamento de Custos da Microsoft estão disponíveis nas SKUs F.

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

O que muda e o que permanece o mesmo

A migração envolve principalmente uma alteração de licenciamento e infraestrutura. As experiências do usuário final e a maioria dos comportamentos administrativos permanecem iguais. Algumas áreas operacionais mudam.

Area	Mudar?	Depois de migrar para o SKU F
Relatórios, modelos semânticos, dashboards	Idêntico	Continua funcionando sem alterações no F64 ou em capacidades maiores.
Licenças de usuário (Pro, PPU, Gratuito)	Idêntico	Inalterado. No F64 e superiores, os usuários com uma licença gratuita do Fabric e a função de Visualizador podem visualizar conteúdo, assim como nas SKUs P. De F2 a F32, cada visualizador precisa de uma licença Pro ou PPU.
Espaços de trabalho e aplicativos	Idêntico	Os workspaces são reatribuídos à nova capacidade. Aplicativos de espaço de trabalho, pipelines de implantação e integração com o Git continuam funcionando.
Atualização de cronogramas e pipelines	Idêntico	Continue executando na nova capacidade. As atualizações em andamento podem ser interrompidas durante a reatribuição.
Servidor de Relatórios do Power BI	O mesmo, com alteração de licença	Continua disponível com uma reserva de capacidade do Fabric ou SQL Server Edição Enterprise com Software Assurance.
Power BI Embedded	Mesmo, mais simples	Incluído em cada SKU da categoria F. Não são necessários SKUs EM e A separados.
Compra e cobrança	Changes	Passe da cobrança por compromisso do Microsoft 365 para a cobrança do Azure. SKUs F oferecem suporte a pagamento conforme o uso e reservas anuais ou plurianuais.
Gerenciamento de capacidade	Changes	Gerenciado principalmente por meio do portal Fabric (atribuições de workspace e configurações de nível de capacidade). As operações de pausa, retomada, aumento e redução são executadas por meio do portal do Azure.
Autoscale	Changes	A escala automática das SKUs P não está disponível para as SKUs F. Em vez disso, as SKUs F usam o redimensionamento sob demanda – você aumenta ou reduz manualmente por meio do portal Azure.
Governança de capacidade	Novas capacidades	Novos recursos de governança de custos estão disponíveis nas SKUs F, como proteção contra picos no nível do espaço de trabalho e proteção contra excedente de capacidade. Use-os para controlar o consumo e evitar custos descontrolados.
Suporte a itens entre regiões	Nova consideração	Os itens de Power BI padrão sobrevivem a uma reatribuição entre regiões. Modelos semânticos de formato de armazenamento grande exigem backup e restauração ou limpeza e conversão em formato de armazenamento pequeno antes da reatribuição. Todos os itens do Fabric (Lakehouses, Warehouses, Notebooks, pipelines do Data Factory) fazem com que a reatribuição falhe.

A jornada de migração em um relance

Em sua forma mais pura, a migração P-to-F é um movimento 1:1 para o SKU F equivalente na mesma região Azure. Os clientes geralmente usam a migração como uma oportunidade para consolidar capacidades, mover-se entre regiões ou redimensionar. Cada uma dessas alterações adiciona complexidade e risco. Trate essas alterações como fluxos de trabalho separados que são executados após a conclusão da migração de licenciamento.

A migração segue os mesmos cinco estágios, independentemente do tamanho ou da complexidade.

Decidir. Escolha quando migrar, com qual SKU F começar e se deseja permanecer na mesma região Azure. Consulte o guia de decisões sobre migração de SKU P do Power BI Premium.
Plano. Faça um inventário dos workspaces, estabeleça uma linha de base do consumo de CU usando o aplicativo Métricas de Capacidade do Microsoft Fabric e estime o consumo futuro com o Estimador de SKU do Fabric. Registre o Microsoft.Fabric provedor de recursos no Azure e escolha um workspace piloto. Para validação prática antes da compra, provisione uma capacidade de avaliação do Fabric para testar cargas de trabalho.
Provisionamento Compre a SKU F antes de reatribuir qualquer coisa. Escolha a opção de pagamento conforme o uso ou uma reserva e verifique o licenciamento do Servidor de Relatórios do Power BI, se usá-lo.
Migre e valide. Reatribua workspaces no portal de administração do Fabric ou usando o notebook de migração de capacidade. Para migrações entre regiões, recrie os modelos semânticos no formato de armazenamento grande e os itens do Fabric na nova região. Valide atualizações, relatórios e gateways. Consulte Migrar workspaces do Power BI Premium para o Microsoft Fabric.
Descomissionar e operar. O cancelamento da SKU P é manual - o Fabric não descomissiona automaticamente sua SKU P quando você provisiona uma SKU F. Depois de validar a migração, cancele explicitamente a assinatura P SKU no Centro de administração do Microsoft 365. Em seguida, configure o monitoramento de custos usando Gerenciamento de Custos da Microsoft e aproveite a flexibilidade de pausar, retomar e dimensionar no Fabric.

Cenários de migração

A maioria dos clientes se enquadra em um dos quatro cenários a seguir. Os três primeiros cenários seguem as etapas de migração padrão em Migrar workspaces do Power BI Premium para o Microsoft Fabric.

Scenario	Complexidade	Notes
Mesmo locatário, mesma região	Baixo	O padrão recomendado. Reatribua cada espaço de trabalho para a nova SKU F. Não há expectativa de tempo de inatividade, exceto durante quaisquer atualizações em andamento.
Mesmo locatário, entre regiões	Moderado a alto	Segue as etapas de migração padrão, mas modelos semânticos de formato de armazenamento grande e itens Fabric devem ser copiados ou capturados no Git, excluídos e recriados na nova região. Consulte migrações entre regiões: Tratamento especial.
Multigeo (várias SKUs F em regiões diferentes, mesmo locatário)	Moderado	Segue as etapas padrão de migração, mas você adquire SKUs F em cada região de destino e planeja a governança de conteúdo específico de cada região. Consulte Migrações Multigeo.
Entre locatários	Alta; não é compatível com migração com um clique	Não segue as etapas de migração padrão. Requer recriação manual de gateways, modelos semânticos, espaços de trabalho, relatórios, aplicativos e painéis. Considere primeiro a multigeo. Consulte migrações entre locatários.

Caution

As migrações entre regiões envolvem significativamente mais esforço do que as migrações da mesma região. Além dos tipos de item que não sobrevivem à reatribuição entre regiões, planeje:

Os itens do Fabric não são preservados em movimentações entre regiões. Lakehouses, warehouses, notebooks e pipelines do Data Factory impedem a reatribuição. Capture suas definições no Git (ou exporte-as) antes da reatribuição e recrie-as na região de destino.
Revinculação de relatório. Quando você faz backup e restaura (ou exclui e reimplanta) um modelo semântico de formato de armazenamento grande, o modelo recriado obtém um novo GUID. Os relatórios que faziam referência ao modelo original precisam ser vinculados novamente ao modelo recriado.
Sobrecarga do gateway. Os destinos em regiões diferentes geralmente exigem configuração e validação adicionais dos gateways de dados locais, especialmente se seus gateways usam o Azure Relay no modelo Bring Your Own Relay (BYOR), porque os pontos de extremidade do relay são vinculados a uma região.

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

Depois de migrar

Depois de reatribuir os espaços de trabalho e validar que os relatórios e as atualizações de dados funcionam no novo SKU F, reserve um período de estabilização antes de cancelar o SKU P e antes de iniciar qualquer trabalho opcional de modernização. As atividades a seguir ajudam a confirmar que a migração foi concluída sem problemas e a decidir o que fazer em seguida.

Estabilizar o custo

Os gastos com F SKU são previsíveis se você mantiver as capacidades em execução 24 horas por dia. Seu custo mensal permanece estável, embora as tarifas de pagamento conforme o uso sejam geralmente mais altas do que as da SKU P equivalente. Use reservas para garantir economia em cargas de trabalho estáveis e use os recursos de pausar e retomar para capacidades que realmente ficam ociosas durante parte do dia. Para estabilizar o custo:

Acompanhe os gastos diários dos primeiros 30 dias usando Gerenciamento de Custos da Microsoft.
Defina orçamentos e alertas no Azure no grupo de recursos da capacidade para que você seja notificado antes que os gastos ultrapassem o planejado.
Avalie uma reserva de capacidade Fabric anual quando o consumo diário estiver estável. As reservas geralmente descontam cargas de trabalho previsíveis.
Pause as capacidades ociosas fora do horário comercial para suspender a cobrança nesses períodos.

Estabilizar o desempenho

Para uma migração de 1:1 na mesma região para o SKU F equivalente, o consumo de CU deve corresponder de perto à 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 desativar o SKU P. As sobrecargas relatadas após a migração geralmente são causadas por alterações de carga de trabalho (uma intermitência de atualizações, conteúdo adicionado, agendas de atualização alteradas) em vez da migração em si. Verifique os padrões de uso antes de assumir que a SKU F é a causa. Para estabilizar o desempenho:

Monitore a nova capacidade com o aplicativo Métricas de Capacidade do Microsoft Fabric por uma a duas semanas após a transição.
Compare com a linha de base que você capturou no SKU P. Investigue deltas grandes em frequência de atualização, tamanho do conjunto de dados ou carga interativa antes de redimensionar.
Aumente a escala conforme necessário por meio do portal do Azure se você observar limitação persistente. Confira Dimensionar sua capacidade.
Valide ao longo de um ciclo de negócios completo - incluindo o fechamento de fim de mês e o fechamento trimestral - antes de considerar a linha de base definitiva.
Verifique novamente a linha de base sempre que você adicionar um novo conteúdo significativo ou alterar os agendamentos de atualização.
Revalide após qualquer alteração de configuração do seu lado (tamanho da SKU, região, atribuição de carga de trabalho).
Para obter diretrizes mais amplas sobre como planejar o crescimento da capacidade e a governança, consulte Microsoft Fabric guia de planejamento de capacidade.

Examinar operações e governança

Algumas configurações operacionais não são transferidas automaticamente quando os workspaces são movidos para um SKU F. Examine o seguinte:

Confirme as atribuições do Azure RBAC no recurso de capacidade para que os administradores corretos possam gerenciá-lo.
Reaplique as configurações de carga de trabalho no 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 configuração de locatário Os usuários podem criar itens do Fabric e quaisquer delegações com escopo para a capacidade.
Aplique tags do Azure ao recurso de capacidade para que os relatórios de chargeback e showback atribuam os gastos ao centro de custo correto.
Avalie novos recursos de governança do uso da capacidade disponíveis em SKUs F (como proteção contra picos no nível do workspace e proteção contra sobrecarga da capacidade) para definir proteções antes de disponibilizar a capacidade para um uso mais amplo.

Explorar oportunidades de modernização

Muitos cenários de modernização do Fabric também são tecnicamente possíveis em SKUs P. O que muda nas SKUs F é o modelo operacional: gerenciamento de custos nativo do Azure, recursos de governança de capacidade (como proteção contra picos e excedentes) e RBAC unificado do Azure facilitam a adoção desses cenários com limites de custo mais claros e maior confiança operacional. Essas opções são acompanhamentos opcionais, não requisitos de migração:

Traga dados existentes para o OneLake usando Espelhamento e Atalhos.
Converta modelos semânticos do DirectQuery no Direct Lake , onde as cargas de trabalho se beneficiam.
Adote a segurança do OneLake para controles unificados de acesso a dados em cargas de trabalho Fabric.

Trate essas opções como fluxos de trabalho separados que são executados após a conclusão da migração de licenciamento. Eles não bloqueiam a migração e não devem estender o prazo da migração.

Comentários

Esta página foi útil?

Last updated on 2026-07-22