Padrões e estratégias de migração de inquilinos do Power BI

As organizações enfrentam vários cenários de migração de inquilinos no Power BI, impulsionados por fusões e aquisições, desinvestimentos empresariais, requisitos de residência de dados ou necessidades regionais de conformidade. As migrações de inquilinos são tarefas complexas que exigem planeamento cuidadoso, estratégias abrangentes de backup e execução sistemática. Este artigo fornece orientações para migrações de tenant Power BI em escala empresarial, incluindo quadros de decisão para ajudar a determinar se a migração é necessária, e metodologias detalhadas de implementação para diferentes padrões de migração.

Importante

As migrações de inquilinos acarretam riscos significativos e exigem um esforço manual extenso. A Microsoft não oferece suporte direto para migrar conteúdo entre inquilinos ou dentro do mesmo tenant durante relocalizações regionais. Antes de avançar com qualquer migração, avalie cuidadosamente alternativas, como capacidades multigeográficas, que podem lidar com muitos cenários sem a complexidade e o risco de uma migração total de inquilinos.

Cenários de migração de inquilinos

A migração de inquilino do Power BI abrange três cenários. Identifique qual se aplica à sua situação antes de planear a migração.

Scenario Description Acionador típico
Migração lado a lado (entre inquilinos) Dois inquilinos separados do Microsoft 365 funcionam em paralelo. Os artefactos são transferidos do inquilino de origem para o inquilino alvo individualmente. Fusões e aquisições que consolidam duas organizações num único inquilino.
Divisão dos inquilinos Um único inquilino Power BI está separado em dois inquilinos independentes. Artefactos, espaços de trabalho e utilizadores pertencentes à entidade empresarial cessante são separados seletivamente. Desinvestimentos e cisões.
Remapeamento do inquilino (relocalização de inquilinos) O tenant do Power BI é eliminado e recriado numa nova região principal no mesmo tenant do Microsoft 365. O ID do tenant, domínio e identidades de utilizador do Microsoft 365 são preservados. Para mais informações, veja Mover Power BI entre regiões geográficas. Requisitos de residência de dados que obrigam a região de origem do inquilino a ir para um país/região específica.

Migrações lado a lado e divisões de inquilinos são operações entre inquilinos . O remapeamento de tenant é uma relocalização de região no mesmo tenant do Microsoft 365.

Note

Para considerações e limitações sobre o remapeamento do tenant (relocalização regional) com o Suporte da Microsoft, consulte Mova o seu tenant do Power BI para outra região. A assistência do Suporte da Microsoft limita-se a eliminar o tenant anterior e a remapear um novo tenant para a região especificada; a assistência à migração não é fornecida. Tem de dispor de um plano de reidratação tanto para os dados como para os metadados, seja através de cópia de segurança e restauro automatizados por script, de ações manuais ou de um processo de recriação e recarregamento. Este procedimento acarreta riscos consideráveis, incluindo potencial perda de dados ou artefactos se as cópias de segurança estiverem incompletas ou se os artefactos forem omitidos. O tempo de inatividade durante o remapeamento dos inquilinos pode variar entre três a 24 horas, sendo necessário mais tempo de inatividade para a restauração de artefactos.

Avalie alternativas antes de migrar

A migração de inquilinos envolve riscos e esforços consideráveis. Explore opções alternativas antes de avançar. As estratégias seguintes podem ajudá-lo a evitar uma migração ou mudança de inquilino.

Implementação multi-geo

Uma implementação multigeográfica permite-lhe implementar capacidade do Power BI e do Fabric numa região à sua escolha, mantendo inalterada a região de origem do inquilino. Os dados dentro dessas capacidades mantêm-se próximos dos seus utilizadores finais, e pode ter múltiplas capacidades em diferentes regiões sob o mesmo princípio.

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

Importante

Os itens Fabric não sobrevivem à reatribuição de espaços de trabalho entre capacidades em diferentes regiões. Elimina os itens do Fabric antes da reatribuição do espaço de trabalho e recria-os depois, ou usa integração com o Git para fazer backup e restaurar os itens do Fabric.

Considere a implementação multi-geo para os seguintes requisitos:

  • Latência de dados. Coloque dados e computação mais perto dos utilizadores finais, implementando capacidade na sua região.
  • Residência de dados. Os teus dados e a tua capacidade de computação estão associados à tua região de capacidade, não à região do teu tenant. Uma implementação multigeográfica mantém os dados dentro das fronteiras de residência dos dados para a maioria das cargas de trabalho.

Só considere um remapeamento do tenant quando os requisitos de residência dos dados forem suficientemente rigorosos para que até os metadados do tenant (definições de espaços de trabalho, metadados do modelo semântico, metadados visuais, configurações, políticas) e as informações do utilizador do Microsoft 365 tenham de permanecer dentro dos limites de residência dos dados.

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

Dataflow Gen1 grava a saída numa conta do Azure Data Lake Storage (ADLS) Gen2 que, por defeito, se encontra na região de origem do tenant do Power BI. Se a localização de armazenamento Gen1 do Dataflow for a tua única preocupação de residência, configura uma conta ADLS Gen2 para trazer a tua própria conta na região desejada em vez de realocar o tenant.

Relay personalizado do Azure para incompatibilidade de região do gateway

Se a sua capacidade estiver implementada numa região diferente da região base do seu inquilino, o ponto final predefinido do gateway de dados no local encaminha o tráfego novamente para a região base. Para manter o tráfego do gateway na sua região de capacidade, configure um relé Azure personalizado . Uma incompatibilidade entre regiões do gateway, por si só, não deveria desencadear uma migração de tenant.

Revise o caso de negócio

Se uma migração de inquilinos for motivada por uma necessidade empresarial (por exemplo, consolidação de faturação), pondere o esforço e o risco face ao resultado. Um pequeno locatário pode ser simples de migrar; um grande locatário com conteúdo substancial do Fabric pode justificar a reavaliação da necessidade de negócio antes de avançar.

O que é suportado para migração

A maioria dos itens Power BI suporta exportação de definições através da API de Administração Power BI ou Workspace Scanner API e pode ser scriptada. A maioria dos itens Fabric não suporta exportação de definições e tem de ser recriada manualmente.

A tabela seguinte resume o percurso de migração para cada tipo de artefacto.

Order Artifact Caminho de migração
1 Gateways Sem rota migratoria. Deve ser reconfigurado no tenant de destino por um administrador do Power BI.
2 Espaços de trabalho Sem rota migratoria. Tem de ser recriado no inquilino alvo. A criação em massa é possível usando a API do Power BI Admin.
3 Artigos de tecido Os itens que suportam integração com o Git podem ser objeto de cópia de segurança ao efetuar um commit no Git, desvinculando-os do espaço de trabalho de origem e associando-os novamente a um novo espaço de trabalho no inquilino de destino. Apenas a definição é comprovada; Os dados não estão incluídos. Itens que não suportam integração com Git têm de ser recriados manualmente. Para Lakehouse, apenas os metadados são preservados; Tabelas e esquemas delta não são transferidos.
4 Dataflows Descarregue a definição JSON e reimporte para o tenant-alvo. A criação de scripts é possível usando a API de administração.
5 Modelos semânticos / conjuntos de dados Utilize cópia de segurança e restauro para uma conta de armazenamento do ADLS Gen2 ou descarregue a definição e importe-a novamente. É possível criar scripts utilizando a API de administração.
6 Relatórios Proprietários ou administradores descarregam o .pbix e republicam para o tenant alvo. Em alternativa, exporte a definição JSON. A criação de scripts é possível através da API de administração.
7 Painéis de controlo Sem rota migratoria. Tem de ser recriado manualmente.
8 Aplicações Power BI Sem rota migratoria. Tem de ser recriado manualmente.
9 Relatórios paginados Proprietários ou administradores descarregam o ficheiro RDL e publicam para o inquilino alvo.

Importante

Recria sempre os artefactos nesta ordem. Os artefactos subsequentes dependem dos artefactos anteriores, e não respeitar essa ordem pode levar a referências inválidas durante a execução. Realizar um Git sync apaga todos os itens no espaço de trabalho que não existem no repositório.

Metodologia de migração

Considere as seguintes atividades de referência. A maioria dos passos aplica-se aos três cenários. Os passos específicos de um determinado cenário são assinalados nos respetivos títulos.

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

Constrói um inventário completo de artefactos e dependências, e identifica o que podes, não podes ou não deves migrar.

Atividades

  • Execute a descoberta a nível do inquilino utilizando uma combinação de:
    • APIs de administração do Power BI
    • APIs de administração do Fabric
    • Registos de atividade (espaços de trabalho, relatórios, conjuntos de dados, atualizações)
    • Documentação manual para itens não expostos pelas APIs
  • Captura:
    • Espaços de trabalho (tipo, capacidade, região)
    • Relatórios, modelos semânticos (especialmente em grande formato de armazenamento), fluxos de dados
    • Artigos de Fabric (Lakehouse, Armazém, Casa de Eventos, cadernos)
    • Gateways, fontes de dados, credenciais
    • Funções de segurança ao nível de linha (RLS), permissões de espaço de trabalho, partilha de ligações
  • Classifica cada espaço de trabalho por complexidade de migração (baixa, média, alta) com base nos artefactos que contém e nas dependências.

Outputs

  • Uma folha de cálculo de inventário principal.
  • Uma classificação de complexidade de migração para cada espaço de trabalho.

Passo 2: Descoberta de utilizadores e segurança

Capturar a identidade do utilizador, licenciamento e permissões, e mapeá-los entre os inquilinos quando necessário.

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

Atividades

Identificar e registar:

  • Atribuições de licença do Power BI (provenientes de Microsoft Graph)
  • IDs de objetos do utilizador no tenant de origem
  • IDs de objetos de utilizador no inquilino de destino (apenas em paralelo ou dividido)
  • Permissões de utilizador e níveis de acesso ao espaço de trabalho
  • Definições atuais ao nível do inquilino (capturar manualmente através do portal de administração)
  • Configurações atuais de governação (rótulos de sensibilidade, políticas de endosso)

Pode extrair as permissões do espaço de trabalho e dos artefactos utilizando as APIs de Administração do Power BI e a Workspace Scanner API.

Passo 3: Comunicação com as partes interessadas e gestão da mudança

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

Principais grupos de partes interessadas

  • Patrocinadores executivos
  • Proprietários de espaços de trabalho e autores de relatórios
  • Utilizadores finais
  • Equipas de TI, segurança e identidade

Atividades

  • Desenvolva um plano de comunicação que abranja:
    • Visão geral e justificação da migração.
    • O que é e o que não é migrado (por exemplo, espaços de trabalho pessoais, espaços de trabalho ociosos).
    • O que muda (URLs, acesso, tempo de atualização). Os links downstream do Power Apps e SharePoint que referenciam URLs do Power BI também são afetados.
    • O que não muda (semântica de dados, visuais, lógica de negócio).
  • Comunique datas-chave:
    • Congelar janelas (normalmente cerca de uma semana sem alterações no tenant de origem durante a cópia de segurança final).
    • Tempo de inatividade esperado (para cenários de remapeamento de tenant).
    • Períodos de validação para as partes interessadas verificarem os seus próprios relatórios no inquilino-alvo.
    • Marcos de transição e datas de desativação para o inquilino de origem (cenários lado a lado).

Outputs

  • Um baralho de briefing para partes interessadas.
  • Uma FAQ para utilizadores finais.

Passo 4: Submeter um pedido de remapeamento dos inquilinos (apenas remapeamento dos inquilinos)

Quando a data de migração estiver definida, submeta um pedido de suporte e selecione especificamente a opção de remapeamento do tenant. Um engenheiro de suporte da Microsoft aceita o pedido.

Atividades

  • Submete o pedido de suporte.
  • Preencha a lista de verificação de prontidão fornecida pela Microsoft.
  • Concordem numa data e horário de migração, incluindo um intervalo de tempo de backup.
  • Elimine a capacidade existente antes de o remapeamento dos locatários ocorrer.

Resultados esperados

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

Passo 5: Prontidão do tenant de destino

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

Atividades

  • Configurar as definições do tenant Power BI:
    • Controlos de criação de espaços de trabalho
    • Partilha e políticas de acesso externo
    • Governação de elementos visuais personalizados
    • Etiquetas de sensibilidade e proteção da informação
    • Registo de auditoria e capacitação de monitorização
  • Compre capacidades do Fabric com um SKU igual ou superior ao da origem.
  • Configure e valide gateways, clusters de gateways e conectividade de dados.
  • Para cenários em paralelo ou de separação de locatários:
    • Crie um utilizador no tenant alvo para cada utilizador no tenant de origem e registre o mapeamento do utilizador.
    • Recriar grupos de utilizadores a partir do inquilino de origem.
    • Atribui licenças Power BI no tenant-alvo.
  • Alinhar a governação: etiquetas de sensibilidade, integração com o Microsoft Purview e políticas de endosso.

Passo 6: Piloto de migração

Efetue uma migração de teste num espaço de trabalho de amostra representativo antes da migração de produção.

Para migrações paralelas, o tenant de origem permanece disponível como alternativa de recurso para novas tentativas. Para o remapeamento de tenente, o conteúdo que não foi corretamente guardado antes do remapeamento é irrecuperável. Um piloto bem-sucedido é a principal forma de mitigar os riscos no percurso de remapeamento.

Critérios de seleção do espaço de trabalho piloto

  • Contém uma mistura de artefactos: relatórios, modelos semânticos, fluxos de dados e itens Fabric.
  • Utiliza fontes de dados realistas e cronogramas de atualização.
  • Tem permissões ao nível do espaço de trabalho e, idealmente, RLS.
  • É usado ativamente mas não é crítico para a missão.

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

Executar a migração. Os itens suportados são scriptados primeiro; Itens não suportados são recriados manualmente.

Para grandes locatários, escreva scripts que utilizem a API de Administração do Power BI para exportar em massa e recriar artefactos em massa.

Recrie os artefactos pela ordem definida em O que é suportado para a migração. Saltar a ordem quebra dependências.

Passo 8: Validação e testes

Valide que o conteúdo foi migrado com sucesso e se comporta corretamente.

As definições de modelos semânticos exportados não incluem os dados subjacentes. Cada modelo semântico importado necessita de pelo menos uma atualização manual no tenant-alvo.

Tip

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 alvo.

Atividades

  • Validar dados: contagens de linhas, agregações por chave, sucesso da atualização.
  • Validar a segurança: regras RLS, acesso ao espaço de trabalho, âmbitos de partilha.
  • Validar o desempenho: tempos de carregamento do relatório, resposta à consulta, margem de capacidade.

Passo 9: Transição e adoção por utilizadores

Mova os utilizadores para o inquilino de destino e atualize as aplicações subsequentes.

Atividades

  • Conceda aos utilizadores acesso a espaços de trabalho e artefactos no tenant-alvo.
  • Atualize URLs de relatórios incorporados, links do SharePoint, ligações do Power Apps e fluxos do Power Automate que referenciam conteúdos do Power BI.
  • Desative a edição no tenant de origem (fase só de leitura) antes da desativação final.
  • Organiza sessões curtas de capacitação sobre o que mudou e onde encontrar conteúdo.

Conteúdo relacionado

  • Last updated on