Power BI strategie e modelli di migrazione dei tenant

Le organizzazioni affrontano diversi scenari di migrazione dei tenant in Power BI, basati su fusioni e acquisizioni, dismissioni aziendali, requisiti di residenza dei dati o esigenze di conformità a livello di area. Le migrazioni dei tenant sono imprese complesse che richiedono un'attenta pianificazione, strategie di backup complete ed esecuzione sistematica. Questo articolo fornisce indicazioni per le migrazioni di tenant Power BI su scala aziendale, inclusi i framework decisionali per determinare se la migrazione è necessaria e metodologie di implementazione dettagliate per modelli di migrazione diversi.

Importante

Le migrazioni dei tenant comportano un rischio significativo e richiedono un'ampia attività manuale. Microsoft non fornisce supporto diretto per la migrazione del contenuto tra tenant o all'interno dello stesso tenant durante le rilocazioni a livello di area. Prima di procedere con qualsiasi migrazione, valutare attentamente alternative, ad esempio capacità multi-geografiche che possono affrontare molti scenari senza la complessità e il rischio di migrazione completa del tenant.

Scenari di migrazione del tenant

La migrazione del tenant di Power BI prevede tre scenari. Identificare quale si applica alla situazione prima di pianificare la migrazione.

Scenario Description Trigger tipico
Migrazione affiancata (cross-tenant) Due tenant Microsoft 365 separati operano in parallelo. Gli artefatti vengono spostati singolarmente dal tenant di origine al tenant di destinazione. Fusioni e acquisizioni che consolidano due organizzazioni in un singolo tenant.
Suddivisione del tenant Un singolo tenant Power BI viene suddiviso in due tenant indipendenti. Gli artefatti, gli spazi di lavoro e gli utenti appartenenti all'entità aziendale uscente vengono scorporati selettivamente. Divestimenti e spin-off.
Rimappatura del tenant (ricollocazione del tenant) Il tenant Power BI viene eliminato e ricreato in una nuova area home all'interno dello stesso tenant Microsoft 365. Vengono mantenuti l'ID tenant Microsoft 365, il dominio e le identità utente. Per altre informazioni, vedere Move Power BI tra aree geografiche. Requisiti di residenza dei dati che impongono l'area geografica di origine del tenant a un paese o un'area geografica specifici.

Le migrazioni affiancate e le suddivisioni dei tenant sono operazioni tra tenant diversi. La rimappatura del tenant è un trasferimento di area geografica all'interno dello stesso tenant Microsoft 365.

Note

Per informazioni su considerazioni e limitazioni relative alla rimappatura del tenant (rilocazione geografica) con il supporto tecnico Microsoft, vedi Move your Power BI tenant to a different region. L'assistenza di supporto tecnico Microsoft è limitata all'eliminazione del tenant precedente e alla nuova associazione di un tenant all'area geografica specificata; non viene fornita assistenza per la migrazione. È necessario disporre di un piano di riattivazione sia per i dati che per i metadati, sia tramite backup e ripristino tramite script, azioni manuali o un processo di ricreazione e ricaricamento. Questa procedura comporta un notevole rischio, tra cui potenziali perdite di dati o artefatti se i backup sono incompleti o gli artefatti vengono omessi. Il tempo di inattività durante la rimappatura del tenant può variare da tre a 24 ore; per il ripristino degli artefatti potrebbe essere necessario un periodo di inattività più lungo.

Valutare le alternative prima della migrazione

La migrazione dei tenant comporta rischi e impegno considerevoli. Esplorare le opzioni alternative prima di procedere. Le strategie seguenti possono aiutare a evitare una migrazione o una rilocazione dei tenant.

Distribuzione multi-geografica

Una distribuzione multi-geo consente di distribuire la capacità di Power BI e Fabric nell'area geografica desiderata mantenendo invariata l'area geografica di origine del tenant. I dati all'interno di tali capacità rimangono vicini agli utenti finali ed è possibile avere più capacità in aree diverse nello stesso tenant.

La migrazione degli artefatti a una capacità in un'area geografica diversa è più semplice rispetto alla migrazione del tenant stesso. Per spostare un'area di lavoro in un'area diversa, riassegnare l'area di lavoro da una capacità a un'altra. La riassegnazione è fluida per gli elementi di Power BI.

Importante

Fabric gli elementi non sopravvivono alla riassegnazione dell'area di lavoro tra le capacità in aree diverse. Eliminare gli elementi di Fabric prima della riassegnazione dell'area di lavoro e ricrearli in seguito, oppure usare l'integrazione Git per eseguire il backup e ripristinare gli elementi di Fabric.

Valutare un'implementazione multi-geo per i seguenti requisiti:

  • Latenza dei dati. Posizionare i dati e il calcolo più vicini agli utenti finali distribuendo la capacità nella propria area.
  • Residenza dei dati. I dati e le risorse di calcolo sono associati all'area di capacità , non all'area del tenant. Una distribuzione multi-geografica mantiene i dati entro i limiti di residenza dei dati per la maggior parte dei carichi di lavoro.

Prendere in considerazione una rimappatura del tenant solo quando i requisiti di residenza dei dati siano così rigorosi da richiedere che anche i metadati del tenant (definizioni dell'area di lavoro, metadati del modello semantico, metadati degli oggetti visivi, impostazioni, criteri) e le informazioni sugli utenti di Microsoft 365 rimangano all'interno dei confini di residenza dei dati.

Usa il tuo account di archiviazione per Dataflow Gen1

Dataflow Gen1 scrive l'output in un account Azure Data Lake Storage (ADLS) Gen2 che, per impostazione predefinita, si trova nell'area principale del tenant Power BI. Se la posizione di archiviazione di Dataflow Gen1 è la tua unica esigenza relativa alla residenza dei dati, configura un account ADLS Gen2 personalizzato nell'area geografica desiderata invece di trasferire il tenant.

Azure Relay personalizzato per mancata corrispondenza dell'area geografica del gateway

Se la capacità è distribuita in un'area geografica diversa dall'area geografica primaria del tenant, l'endpoint predefinito del gateway dati locale instrada il traffico di nuovo verso l'area geografica primaria. Per mantenere il traffico del gateway nell'area di capacità, configurare un relè personalizzato Azure. Una discrepanza della regione del gateway da sola non dovrebbe attivare una migrazione del tenant.

Esaminare il business case

Se la migrazione di un tenant è determinata da una necessità aziendale (ad esempio, il consolidamento della fatturazione), valutare il lavoro e il rischio rispetto al risultato. Un tenant di piccole dimensioni potrebbe essere facile da migrare; un tenant di grandi dimensioni con una quantità significativa di contenuto Fabric potrebbe richiedere di riesaminare l'esigenza aziendale prima di procedere.

Cosa è supportato per la migrazione

La maggior parte degli elementi di Power BI supporta l'esportazione delle definizioni tramite l'API Power BI Admin o Workspace Scanner API e può essere gestita tramite script. La maggior parte degli elementi Fabric non supporta l'esportazione delle definizioni e deve essere ricreata manualmente.

La tabella seguente riepiloga il percorso di migrazione per ogni tipo di artefatto.

Ordine Artefatto Percorso di migrazione
1 Gateways Nessun percorso di migrazione. Deve essere riconfigurato nel tenant di destinazione da un amministratore Power BI.
2 Aree di lavoro Nessun percorso di migrazione. Deve essere ricreato nel tenant di destinazione. La creazione in blocco è possibile usando l'API di amministrazione Power BI.
3 Elementi dell'infrastruttura È possibile eseguire il backup degli elementi che supportano l'integrazione Git eseguendo il commit in Git, scollegando dall'area di lavoro di origine e ricollegando a una nuova area di lavoro nel tenant di destinazione. Viene eseguito il backup solo della definizione; i dati non sono inclusi. Gli elementi che non supportano l'integrazione Git devono essere ricreati manualmente. Per Lakehouse, vengono conservati solo i metadati; le tabelle delta e gli schemi non vengono trasferiti.
4 Dataflows Scaricare il codice JSON di definizione e reimportare nel tenant di destinazione. Lo scripting è possibile usando l'API di amministrazione.
5 Modelli semantici/set di dati Usare il backup e il ripristino in un account di archiviazione di ADLS Gen2 oppure scaricare la definizione e reimportarla. Lo scripting è possibile usando l'API di amministrazione.
6 Rapporti I proprietari o gli amministratori scaricano il file con estensione pbix e ripubblicano nel tenant di destinazione. In alternativa, esportare la definizione JSON. Lo scripting è possibile usando l'API di amministrazione.
7 Dashboard Nessun percorso di migrazione. Deve essere ricreato manualmente.
8 App di Power BI Nessun percorso di migrazione. Deve essere ricreato manualmente.
9 Report impaginati I proprietari o gli amministratori scaricano il file RDL e pubblicano nel tenant di destinazione.

Importante

Ricreare sempre gli artefatti in questo ordine. Gli artefatti a valle dipendono dagli artefatti a monte e il mancato rispetto dell'ordine può causare riferimenti non validi durante l'esecuzione. L'esecuzione di una sincronizzazione Git cancella tutti gli elementi nell'area di lavoro che non esistono nel repository.

Metodologia di migrazione

Si considerino le attività di riferimento seguenti. La maggior parte dei passaggi si applica a tutti e tre gli scenari. I passaggi specifici di uno scenario sono indicati nei rispettivi titoli.

Passaggio 1: Individuazione e valutazione dell'inventario

Crea un inventario completo di artefatti e dipendenze e individua ciò che puoi migrare, ciò che non puoi migrare o ciò che non dovresti migrare.

attività

  • Eseguire il rilevamento nell'intero tenant usando una combinazione di:
    • API di amministrazione di Power BI
    • API di amministrazione di Fabric
    • Registri attività (aree di lavoro, report, set di dati, aggiornamenti dei dati)
    • Documentazione manuale per gli elementi non esposti dalle API
  • Cattura:
    • Aree di lavoro (tipo, capacità, area)
    • Report, modelli semantici (in particolare formato di archiviazione di grandi dimensioni), flussi di dati
    • elementi di Fabric (Lakehouse, Warehouse, Eventhouse, notebook)
    • Gateway, origini dati, credenziali
    • Ruoli di sicurezza a livello di riga, autorizzazioni dell'area di lavoro, collegamenti di condivisione
  • Classificare ogni area di lavoro in base alla complessità della migrazione (bassa, media, alta) in base agli artefatti contenuti e alle dipendenze.

Risultati

  • Foglio di calcolo dell'inventario principale.
  • Classificazione della complessità della migrazione per ogni area di lavoro.

Passaggio 2: Individuazione utenti e sicurezza

Acquisire l'identità utente, le licenze e le autorizzazioni ed eseguirne il mapping tra i tenant quando necessario.

In un nuovo mapping del tenant, gli ID oggetto utente vengono mantenuti. Per una migrazione affiancata o una scissione del tenant, gli utenti hanno ID di oggetto diversi nel tenant di destinazione. Mappare ogni identità del tenant di origine alla relativa identità del tenant di destinazione. Riassegnare le assegnazioni delle licenze di Power BI (Free, Pro, PPU). Eseguire il mirroring dei gruppi di sicurezza nel nuovo tenant Microsoft 365.

attività

Identificare e registrare:

  • Power BI assegnazioni di licenze (Microsoft Graph)
  • ID degli oggetti utente nel tenant di origine
  • ID degli oggetti utente nel tenant di destinazione (solo side-by-side o split)
  • Autorizzazioni utente e livelli di accesso all'area di lavoro
  • Impostazioni correnti a livello di tenant (acquisizione manuale tramite il portale di amministrazione)
  • Configurazioni di governance attuali (etichette di riservatezza, criteri di certificazione)

È possibile estrarre le autorizzazioni dell'area di lavoro e degli artefatti usando le API amministratore Power BI e l'API Workspace Scanner.

Passaggio 3: Comunicazione degli stakeholder e gestione dei cambiamenti

Comunicare in anticipo il piano di migrazione per ridurre la resistenza e il carico di supporto.

Gruppi di stakeholder chiave

  • Sponsor esecutivi
  • Titolari dell'area di lavoro e autori di report
  • Utenti finali
  • Team IT, sicurezza e identità

attività

  • Sviluppare un piano di comunicazione che copre:
    • Panoramica e logica della migrazione.
    • Cosa viene e non viene migrato (ad esempio, aree di lavoro personali, aree di lavoro inattive).
    • Modifiche (URL, accesso, intervallo di aggiornamento). Sono anch’essi interessati i collegamenti a valle di Power Apps e SharePoint che fanno riferimento agli URL di Power BI.
    • Cosa non cambia (semantica dei dati, oggetti visivi, logica di business).
  • Comunicare le date chiave:
    • Bloccare le finestre (in genere circa una settimana di nessuna modifica nel tenant di origine durante il backup finale).
    • Tempo di inattività previsto (per gli scenari di mapping del tenant).
    • Periodi di validazione per consentire agli stakeholder di verificare i propri report nel tenant di destinazione.
    • Milestone di cutover e date di dismissione per il tenant di origine (scenari side-by-side).

Risultati

  • Una presentazione informativa per gli stakeholder.
  • Domande frequenti sugli utenti finali.

Passaggio 4: Inviare una richiesta di rimappatura del tenant (solo rimappatura del tenant)

Quando la data di migrazione è bloccata, invia un ticket di supporto e seleziona specificamente l'opzione di riassegnazione del tenant. Un tecnico del supporto Microsoft accetta la richiesta.

attività

  • Inviare il ticket di supporto.
  • Completare l'elenco di controllo di conformità fornito da Microsoft.
  • Accettare una data e una fascia oraria di migrazione, inclusa una fascia oraria di backup.
  • Eliminare la capacità esistente prima che venga eseguito il mapping del tenant.

Risultati previsti

  • Una tipica mappa richiede circa tre ore, ma i ritardi fino a 24 ore sono possibili se si verificano complicazioni.
  • Al termine del mapping, il nuovo tenant ha lo stesso ID tenant e si trova nell'area richiesta.

Passaggio 5: Idoneità del tenant di destinazione

Un tenant appena creato o appena mappato non è immediatamente pronto per ricevere contenuto. Configuralo prima.

attività

  • Configurare le impostazioni del tenant Power BI:
    • Controlli di creazione dell'area di lavoro
    • Condivisione e criteri di accesso esterno
    • Governance delle visualizzazioni personalizzate
    • Etichette di riservatezza e protezione delle informazioni
    • Abilitazione del log di controllo e del monitoraggio
  • Acquistare capacità Fabric con SKU pari o superiore rispetto a quella di origine.
  • Configurare e validare i gateway, i cluster di gateway e la connettività dei dati.
  • Per scenari di suddivisione side-by-side o tenant:
    • Creare un utente nel tenant di destinazione per ogni utente nel tenant di origine e registrare il mapping dell'utente.
    • Ricreare gruppi di utenti dal tenant di origine.
    • Assegnare licenze Power BI nel tenant di destinazione.
  • Allinea la governance: etichette di riservatezza, integrazione con Microsoft Purview e criteri di approvazione.

Passaggio 6: Migrazione pilota

Eseguire una migrazione di test in un'area di lavoro di esempio rappresentativa prima della migrazione di produzione.

Per le migrazioni affiancate, il tenant di origine rimane disponibile come alternativa di ripiego per i nuovi tentativi. Per la rimappatura del tenant, il contenuto di cui non è stato eseguito correttamente il backup prima della rimappatura è irrecuperabile. Un progetto pilota riuscito è il modo principale per ridurre i rischi nel percorso di rimappatura.

Criteri di selezione dell'area di lavoro pilota

  • Contiene un insieme di elementi diversi: report, modelli semantici, flussi di dati ed elementi di Fabric.
  • Usa origini dati realistiche e pianificazioni di aggiornamento.
  • Dispone di autorizzazioni a livello di area di lavoro e, preferibilmente, di RLS.
  • È utilizzato attivamente, ma non è critico per l'attività.

Passaggio 7: Esecuzione della migrazione

Eseguire la migrazione. Gli elementi supportati vengono prima inseriti in script; gli elementi non supportati vengono ricreati manualmente.

Per i tenant di grandi dimensioni, scrivere script che incapsulano l'API di amministrazione di Power BI per esportare in blocco e ricreare in blocco gli artefatti.

Ricreare gli artefatti nell'ordine definito in Elementi supportati per la migrazione. Saltare l'ordine interrompe le dipendenze.

Passaggio 8: Convalida e test

Verificare che la migrazione del contenuto sia stata eseguita correttamente e che si comporti correttamente.

Le definizioni del modello semantico esportato non includono i dati sottostanti. Ogni modello semantico importato richiede almeno un aggiornamento manuale nel tenant di destinazione.

Tip

Prendere in considerazione il ridimensionamento temporaneamente a uno SKU di capacità superiore durante la convalida. Un numero elevato di aggiornamenti simultanei può altrimenti saturare la capacità di destinazione.

attività

  • Convalidare i dati: conteggi delle righe, aggregazioni chiave, aggiornamento riuscito.
  • Verificare la sicurezza: regole RLS, accesso all'area di lavoro, livelli di condivisione.
  • Verificare le prestazioni: tempi di caricamento dei report, reattività delle query, margine di capacità residua.

Passaggio 9: Passaggio degli utenti e adozione

Spostare gli utenti nel tenant di destinazione e aggiornare le applicazioni downstream.

attività

  • Concedere agli utenti l'accesso alle aree di lavoro e agli artefatti nel tenant di destinazione.
  • Aggiornare gli URL dei report incorporati, i collegamenti SharePoint, le connessioni Power Apps e i flussi di Power Automate che fanno riferimento al contenuto Power BI.
  • Disabilitare la modifica nel tenant di origine (fase di sola lettura) prima della rimozione finale.
  • Eseguire sessioni di abilitazione brevi che illustrano le modifiche apportate e la posizione in cui trovare il contenuto.

Contenuti correlati

  • Last updated on