Padrões e estratégias de migração de locatário no Power BI

As organizações enfrentam vários cenários de migração de locatários em Power BI, impulsionados por fusões e aquisições, alienações da empresa, requisitos de residência de dados ou necessidades de conformidade regional. As migrações de locatário são empreendimentos complexos que exigem planejamento cuidadoso, estratégias de backup abrangentes e execução sistemática. Este artigo fornece diretrizes para migrações de locatário Power BI em escala empresarial, incluindo estruturas de decisão para ajudar a determinar se a migração é necessária e metodologias de implementação detalhadas para diferentes padrões de migração.

Importante

As migrações de locatário têm um risco significativo e exigem amplo esforço manual. Microsoft não fornece suporte direto para migrar conteúdo entre locatários ou dentro do mesmo locatário durante realocações regionais. Antes de prosseguir com qualquer migração, avalie cuidadosamente alternativas, como capacidades multigeográficas, que podem atender a muitos cenários sem a complexidade e o risco de uma migração completa do locatário.

Cenários de migração de locatário

Power BI migração de locatário abrange três cenários. Identifique qual deles se aplica à sua situação antes de planejar sua migração.

Scenario Descrição Gatilho típico
Migração paralela (entre locatários) Dois locatários Microsoft 365 separados operam em paralelo. Os artefatos são movidos do locatário de origem para o locatário de destino individualmente. Fusões e aquisições que consolidam duas organizações em um único locatário.
Divisão de locatário Um único locatário do Power BI é separado em dois locatários independentes. Artefatos, espaços de trabalho e usuários pertencentes à entidade empresarial que está saindo são separados seletivamente. Alienações e spin-offs.
Remapeamento do locatário (realocação do locatário) O locatário Power BI é excluído e recriado em uma nova região inicial dentro do mesmo locatário Microsoft 365. A ID do locatário Microsoft 365, o domínio e as identidades de usuário são preservadas. Para obter mais informações, consulte Move Power BI entre regiões geográficas. Requisitos de residência de dados que exigem que a região base do locatário seja um país/região específico.

Migrações paralelas e divisões de locatários são operações entre locatários. O remapeamento de locatário é uma realocação de região dentro do mesmo locatário do Microsoft 365.

Note

Para obter considerações e limitações sobre remapeamento de locatário (realocação regional) com o Suporte da Microsoft, consulte Mover seu locatário do Power BI para uma região diferente. A assistência do Suporte da Microsoft se limita à exclusão do locatário anterior e ao remapeamento de um novo locatário para a região especificada; não inclui assistência para migração. Você deve ter um plano de reidratação para dados e metadados, seja por meio de backup e restauração com script, ações manuais ou um processo de recriação e recarregamento. Esse procedimento traz um risco considerável, incluindo possíveis perda de dados ou artefatos se os backups estiverem incompletos ou os artefatos forem omitidos. O tempo de inatividade durante o remapeamento de locatário pode variar entre três e 24 horas, sendo necessário mais tempo de inatividade para a restauração de artefatos.

Avaliar alternativas antes de migrar

A migração de locatário envolve um risco e esforço consideráveis. Explore opções alternativas antes de continuar. As estratégias a seguir podem ajudá-lo a evitar uma migração ou realocação de locatário.

Implantação multigeográfica

Uma implantação multi-geo permite implantar o Power BI e a capacidade do Fabric na região de sua escolha, mantendo inalterada a região base do locatário. Os dados dentro dessas capacidades permanecem próximos aos usuários finais e você pode ter várias capacidades em regiões diferentes no mesmo locatário.

Migrar artefatos para uma capacidade em uma região diferente é mais simples do que migrar o próprio locatário. Para mover um espaço de trabalho para uma região diferente, reatribua o espaço de trabalho de uma capacidade para outra. A reatribuição ocorre sem problemas para itens do Power BI.

Importante

Os itens do Fabric não são preservados durante a reatribuição do espaço de trabalho entre capacidades de regiões diferentes. Exclua Fabric itens antes da reatribuição do workspace e recrie-os posteriormente ou use a integração do Git para fazer backup e restaurar Fabric itens.

Considere a implantação multigeográfica para os seguintes requisitos:

  • Latência de dados. Coloque os dados e a computação mais próximos dos usuários finais implantando a capacidade em sua região.
  • Residência de dados. Seus dados e computação estão vinculados à sua região de capacidade , não à sua região de locatário. Uma implantação em várias regiões geográficas mantém os dados dentro dos requisitos de residência de dados para a maioria das cargas de trabalho.

Considere um remapeamento de locatário apenas quando os requisitos de residência de dados forem rigorosos a ponto de exigir que até mesmo os metadados do locatário (definições de workspace, metadados do modelo semântico, metadados visuais, configurações, políticas) e as informações do usuário do Microsoft 365 permaneçam dentro dos limites de residência de dados.

Traga sua própria conta de armazenamento para o Dataflow Gen1

Dataflow Gen1 grava a saída em uma conta do Azure Data Lake Storage (ADLS) Gen2 que, por padrão, fica na região de origem do locatário do Power BI. Se o local de armazenamento do Dataflow Gen1 for sua única preocupação de residência, configure uma conta traga sua própria conta do ADLS Gen2 na região desejada em vez de realocar o locatário.

Retransmissão de Azure personalizada para incompatibilidade de região do gateway

Se a sua capacidade estiver implantada em uma região diferente da região principal do locatário, o ponto de extremidade padrão do gateway de dados local encaminhará o tráfego de volta para a região principal. Para manter o tráfego de gateway na sua região de capacidade, configure um Azure Relay personalizado. Uma divergência na região do gateway, por si só, não deve desencadear uma migração de locatário.

Revisar o caso de negócios

Se uma migração de locatário for impulsionada por uma necessidade de negócios (por exemplo, consolidação de cobrança), avalie o esforço e o risco em relação ao resultado. Um tenant pequeno pode ser fácil de migrar; um tenant grande com um volume significativo de conteúdo do Fabric pode justificar uma reavaliação da necessidade de negócio antes de prosseguir.

O que tem suporte para migração

A maioria dos itens do Power BI oferece suporte à exportação de definição por meio da Power BI Admin API ou da Workspace Scanner API e podem ser automatizados por script. A maioria dos itens Fabric não dá suporte à exportação de definição e deve ser recriada manualmente.

A tabela a seguir resume o caminho de migração para cada tipo de artefato.

Pedido Artefato Caminho de migração
1 Gateways Nenhum caminho de migração. Deve ser reconfigurado no locatário de destino por um administrador Power BI.
2 Espaços de trabalho Nenhum caminho de migração. Deve ser recriado no locatário de destino. A criação em massa é possível usando a API de administração do Power BI.
3 Itens de estrutura de rede Os itens que oferecem suporte à integração com o Git podem ser salvos como backup por meio de um commit no Git, desvinculando-os do workspace de origem e vinculando-os novamente a um novo workspace no tenant de destino. Somente a definição tem backup; os dados não estão incluídos. Os itens que não dão suporte à integração do Git devem ser recriados manualmente. Para Lakehouse, apenas metadados são preservados; tabelas delta e esquemas não são transferidos.
4 Fluxos de dados Baixe a definição JSON e reimporte no locatário de destino. É possível criar scripts usando a API Admin.
5 Modelos semânticos/conjuntos de dados Use backup e restauração em uma conta de armazenamento do ADLS Gen2 ou baixe a definição e reimporte. É possível criar scripts usando a API de administração.
6 Relatórios Proprietários ou administradores fazem o download do arquivo .pbix e republicam no tenant de destino. Como alternativa, exporte a definição de JSON. É possível usar scripts com a API Admin.
7 Painéis Nenhum caminho de migração. Deve ser recriado manualmente.
8 Power BI aplicativos Nenhum caminho de migração. Deve ser recriado manualmente.
9 Relatórios paginados Proprietários ou administradores baixam o arquivo RDL e publicam no locatário de destino.

Importante

Sempre recrie artefatos nesta ordem. Os artefatos posteriores dependem dos artefatos anteriores, e não respeitar essa ordem pode levar a referências corrompidas durante a execução. A execução de uma sincronização do Git apaga todos os itens no workspace que não existem no repositório.

Metodologia de migração

Considere as seguintes atividades de referência. A maioria das etapas se aplica aos três cenários. As etapas específicas de um cenário são indicadas em seus títulos.

Etapa 1: Descoberta e avaliação de inventário

Crie um inventário completo de artefatos e dependências e identifique o que você pode, não pode ou não deve migrar.

Atividades

  • Execute a descoberta em todo o locatário usando uma combinação de:
    • APIs de administrador do Power BI
    • APIs de administrador do Fabric
    • Logs de atividade (espaços de trabalho, relatórios, conjuntos de dados, atualizações)
    • Documentação manual para itens não expostos por APIs
  • Captura:
    • Espaços de trabalho (tipo, capacidade, região)
    • Relatórios, modelos semânticos (especialmente formato de armazenamento grande), fluxos de dados
    • Itens do Fabric (Lakehouse, Warehouse, Eventhouse, blocos de anotações)
    • Gateways, fontes de dados, credenciais
    • Funções de RLS (segurança em nível de linha), permissões do espaço de trabalho, links de compartilhamento
  • Classifique cada workspace por complexidade de migração (baixa, média, alta) com base nos artefatos que ele contém e nas dependências.

Saídas

  • Uma planilha de inventário primário.
  • Uma classificação de complexidade de migração para cada workspace.

Etapa 2: Descoberta de usuário e segurança

Capture a identidade do usuário, o licenciamento e as permissões e mapeie-os entre locatários quando necessário.

Em um remapeamento de locatário, as IDs dos objetos do usuário são preservadas. Para uma migração paralela ou divisão de tenant, os usuários têm IDs de objeto diferentes no tenant de destino. Mapeie cada identidade de locatário de origem para sua identidade de locatário de destino. Reatribuir atribuições de licenças do Power BI (Free, Pro, PPU). Espelhar grupos de segurança no novo tenant do Microsoft 365.

Atividades

Identificar e registrar:

  • Atribuições de licença do Power BI (obtidas de Microsoft Graph)
  • IDs de objeto de usuário no locatário de origem
  • IDs de objeto de usuário no locatário de destino (lado a lado ou somente dividido)
  • Permissões de usuário e níveis de acesso do workspace
  • Configurações atuais no nível do locatário (capturar manualmente por meio do portal de administração)
  • Configurações de governança atuais (rótulos de confidencialidade, políticas de endosso)

Você pode extrair permissões de espaço de trabalho e artefatos usando as APIs de Administração do Power BI e a API Workspace Scanner.

Etapa 3: Comunicação de stakeholders e gerenciamento de alterações

Comunique o plano de migração antecipadamente para reduzir a resistência e a carga de suporte.

Principais grupos de stakeholders

  • Patrocinadores executivos
  • Proprietários do espaço de trabalho e autores de relatórios
  • Usuários finais
  • Equipes de TI, segurança e identidade

Atividades

  • Desenvolva um plano de comunicação que abrange:
    • Visão geral e lógica da migração.
    • O que é migrado e o que não é (por exemplo, espaços de trabalho pessoais, espaços de trabalho ociosos).
    • O que muda (URLs, acesso, tempo de atualização). Links de Power Apps e SharePoint que fazem referência a URLs de Power BI também são afetados.
    • O que não muda (semântica de dados, visuais, lógica de negócios).
  • Comunicar datas-chave:
    • Congelar janelas (normalmente cerca de uma semana sem alterações no locatário de origem durante o backup final).
    • Tempo de inatividade esperado (para cenários de remapeamento de locatário).
    • Períodos de validação para os stakeholders verificarem seus próprios relatórios no locatário de destino.
    • Marcos da transição e datas de desativação do tenant de origem (cenários paralelos).

Saídas

  • Uma apresentação de briefing para as partes interessadas.
  • Perguntas frequentes sobre o usuário final.

Etapa 4: Enviar uma solicitação de remapeamento de tenant (somente para remapeamento de tenant)

Quando a data de migração estiver definida, envie um chamado de suporte e selecione especificamente a opção de remapeamento de tenant. Um Microsoft engenheiro de suporte aceita a solicitação.

Atividades

  • Envie o chamado de suporte.
  • Conclua a lista de verificação de preparação fornecida pelo Microsoft.
  • Concorde com um intervalo de data e hora de migração, incluindo um intervalo de tempo de backup.
  • Exclua a capacidade existente antes que ocorra o remapeamento do locatário.

Resultados esperados

  • Um remapeamento típico leva cerca de três horas, mas atrasos de até 24 horas são possíveis se ocorrerem complicações.
  • Após a conclusão do remapeamento, o novo locatário tem a mesma ID de locatário e está localizado na região solicitada.

Etapa 5: Prontidão do locatário de destino

Um tenant recém-criado ou recém-remapeado não fica imediatamente pronto para receber conteúdo. Configure-o primeiro.

Atividades

  • Defina Power BI configurações de locatário:
    • Controles para criação de espaço de trabalho
    • Compartilhamento e políticas de acesso externo
    • Governança de visuais personalizados
    • Rótulos de confidencialidade e proteção de informações
    • Ativação do log de auditoria e do monitoramento
  • Comprar capacidades do Fabric com SKU igual ou superior ao da origem.
  • Configure e valide gateways, clusters de gateways e conectividade de dados.
  • Para cenários lado a lado ou de divisão por locatário:
    • Crie um usuário no locatário de destino para cada usuário no locatário de origem e registre o mapeamento do usuário.
    • Recrie os grupos de usuários do tenant de origem.
    • Atribua licenças Power BI no locatário de destino.
  • Alinhe a governança: rótulos de confidencialidade, integração com o Microsoft Purview e políticas de endosso.

Etapa 6: Piloto de migração

Faça uma migração de teste em um espaço de trabalho representativo como amostra antes da migração de produção.

Para migrações paralelas, o tenant de origem permanece disponível como alternativa de contingência para novas tentativas. No remapeamento de locatário, o conteúdo que não teve backup feito corretamente antes do remapeamento é irrecuperável. Um piloto bem-sucedido é a principal forma de reduzir os riscos da trajetória de remapeamento.

Critérios de seleção do workspace piloto

  • Contém uma combinação de artefatos: relatórios, modelos semânticos, fluxos de dados e itens de Fabric.
  • Usa fontes de dados realistas e agendamentos de atualização.
  • Tem permissões em nível de workspace e, idealmente, RLS.
  • É usado ativamente, mas não é essencial para a operação.

Etapa 7: Execução da migração

Execute a migração. Os itens com suporte são primeiro processados por script; os itens sem suporte são recriados manualmente.

Para locatários de grande porte, escreva scripts que encapsulem a API de administração do Power BI para exportar artefatos em massa e recriá-los em massa.

Recrie artefatos na ordem definida em O que tem suporte para migração. Ignorar a ordem quebra as dependências.

Etapa 8: Validação e teste

Valide se o conteúdo foi migrado com êxito e se comporta corretamente.

As definições de modelo semântico exportadas não incluem os dados subjacentes. Cada modelo semântico importado precisa de pelo menos uma atualização manual no locatário de destino.

Dica

Considere escalar temporariamente para um SKU de maior capacidade durante a validação. Um grande número de atualizações simultâneas pode, de outra forma, saturar a capacidade de destino.

Atividades

  • Validar dados: contagens de linhas, agregações-chave, sucesso da atualização.
  • Validar a segurança: regras de RLS, acesso ao espaço de trabalho, escopos de compartilhamento.
  • Valide o desempenho: tempos de carregamento dos relatórios, tempo de resposta das consultas, margem de capacidade.

Etapa 9: Transição e adoção pelos usuários

Mova os usuários para o locatário de destino e atualize os aplicativos downstream.

Atividades

  • Conceda aos usuários acesso a espaços de trabalho e artefatos no locatário de destino.
  • Atualize urls de relatório inseridas, links de SharePoint, conexões Power Apps e fluxos de Power Automate que fazem referência ao conteúdo Power BI.
  • Desative a edição no locatário de origem (fase de somente leitura) antes do descomissionamento final.
  • Execute sessões de habilitação curtas que abrangem o que mudou e onde encontrar conteúdo.

Conteúdo relacionado

  • Last updated on