Panoramica della migrazione da Power BI Premium a Microsoft Fabric

Microsoft sta ritirando gli SKU Power BI Premium per capacità (SKU P). Ogni sottoscrizione SKU P termina alla fine del periodo di contratto corrente e Microsoft non vende più nuovi SKU P. Per continuare a eseguire i carichi di lavoro Power BI, esegui la migrazione agli SKU di capacità di Microsoft Fabric (SKU F). Questo articolo offre una visualizzazione end-to-end della migrazione: perché Fabric SKU F sono il percorso in avanti, quali modifiche e cosa rimangono invariati per gli utenti finali e gli amministratori, le fasi di una migrazione tipica e gli scenari che determinano la complessità della migrazione.

Questo articolo è destinato agli amministratori Fabric, agli amministratori Power BI, agli architetti IT e ai proprietari della capacità che pianificano ed eseguono la migrazione.

Importante

Pianificare il completamento della migrazione prima del termine della sottoscrizione dello SKU P. Al termine dell'abbonamento, la capacità entra in un periodo di tolleranza di 30 giorni. A partire dal giorno 31, l'accesso viene limitato (le operazioni interattive vengono ritardate). Dal giorno 91 in poi, tutte le operazioni vengono rifiutate: i dati vengono conservati ma restano inaccessibili finché non si migrano le aree di lavoro a una capacità Fabric F SKU o non si elimina la capacità. Per evitare disservizi, riassegna le aree di lavoro a una capacità Fabric F SKU prima della scadenza della sottoscrizione P SKU. Per la procedura, vedere Eseguire la migrazione di aree di lavoro da Power BI Premium a Microsoft Fabric.

Note

Clienti con Contratto Enterprise. Se il tuo Enterprise Agreement è ancora attivo, puoi continuare a usare la capacità P SKU esistente e rinnovarla annualmente nell'ambito del contratto fino alla scadenza dell'EA. I clienti con contratti Enterprise scaduti o contratti di Microsoft Cloud non possono aggiungere o acquistare una nuova capacità sku P tramite il contratto. Confermare le condizioni di contratto specifiche con il rappresentante account Microsoft prima di decidere quando eseguire la migrazione.

Note

Questo ritiro ha due limiti di ambito importanti:

  • Le licenze per utente non sono interessate.Power BI Pro e Power BI Premium per utente (PPU) continuano as-is. Per informazioni dettagliate, vedere Anche Power BI Premium per utente (PPU) è in fase di ritiro?
  • Le licenze incorporate (EM, A) non sono interessate. Questi SKU non fanno parte di questo ritiro.
  • I cloud sovrani non sono ancora coinvolti. Microsoft Fabric non è disponibile nei cloud sovrani, quindi gli SKU P rimangono supportati. Microsoft fornisce indicazioni separate quando Fabric diventa disponibile in tali ambienti.

Perché eseguire la migrazione a Microsoft Fabric

Il ritiro degli SKU P è il fattore scatenante immediato, ma gli SKU F di Fabric offrono anche funzionalità che gli SKU P non possono offrire:

  • Si paga solo per le risorse usate. Per impostazione predefinita, gli SKU F usano la fatturazione Azure con pagamento in base al consumo, con prenotazioni facoltative annuali o pluriennali per carichi di lavoro prevedibili. È anche possibile sospendere una capacità quando è inattiva per interrompere la fatturazione durante gli orari di minore attività e successivamente riprenderla su richiesta.
  • Aumentare o ridurre le prestazioni in qualsiasi momento. Ridimensiona le capacità tramite il portale di Azure man mano che cambiano i carichi di lavoro, anziché vincolarti a una dimensione fissa per l’intera durata della sottoscrizione.
  • Usare il modello operativo nativo di Azure. Effettuare il provisioning e gestire la capacità tramite il portale di Azure, applicare i tag di Azure per il chargeback e conteggiare la spesa di Fabric ai fini del Microsoft Azure Consumption Commitment (MACC). Molti carichi di lavoro di Fabric (ad esempio lakehouse, warehouse, notebook e pipeline di Data Factory) vengono eseguiti su capacità P o F, ma il modello operativo di Azure è esclusivamente F.
  • Usare Power BI Embedded senza SKU separati. Gli scenari incorporati sono coperti da ogni SKU F, quindi non sono necessari SKU EM o A separati.
  • Usare la sicurezza e le operazioni native di Azure. Gli endpoint privati gestiti, l'accesso all'area di lavoro attendibile, Monitoraggio di Azure e Gestione dei costi Microsoft sono tutti disponibili con GLI SKU F.

Per il confronto completo delle funzionalità per funzionalità, vedere Differenze principali tra SKU P Premium Power BI e SKU F Fabric.

Cosa cambia e cosa rimane lo stesso

La migrazione comporta principalmente una modifica delle licenze e dell'infrastruttura. Le esperienze degli utenti finali e la maggior parte dei comportamenti amministrativi rimangono invariati. Alcune aree operative cambiano.

Area Cambiare? Dopo la migrazione allo SKU F
Report, modelli semantici, dashboard Uguali Continuano a funzionare senza modifiche con capacità F64 o superiori.
Licenze utente (Pro, PPU, Gratuito) Uguali Inalterato. In F64 e superiori, gli utenti con una licenza Fabric Free e il ruolo di Visualizzatore possono visualizzare il contenuto, come per gli SKU P. Da F2 a F32, ogni utente deve avere una licenza Pro o PPU.
Aree di lavoro e app Uguali Le aree di lavoro vengono riassegnate alla nuova capacità. Le app dell'area di lavoro, le pipeline di distribuzione e l'integrazione git continuano a funzionare.
Pianificazioni e pipeline di aggiornamento Uguali Continuare a essere eseguiti sulla nuova capacità. Gli aggiornamenti attivi potrebbero essere interrotti durante la riassegnazione.
Server di report di Power BI Lo stesso, con la modifica della licenza Disponibile anche con una prenotazione di capacità di Fabric o con SQL Server edizione Enterprise con Software Assurance.
Power BI Embedded Stesso, più semplice Incluso in ogni SKU F. Non sono necessari SKU EM e A separati.
Acquisto e fatturazione Changes Passare dalla fatturazione con impegno di Microsoft 365 alla fatturazione di Azure. Gli SKU F supportano il pagamento in base al consumo e prenotazioni annuali o pluriennali.
Gestione della capacità Changes Gestito principalmente tramite il portale di Fabric (assegnazioni dell'area di lavoro e impostazioni a livello di capacità). Le operazioni di sospensione, ripresa, aumento e riduzione delle prestazioni vengono eseguite tramite il portale di Azure.
Autoscale Changes La scalabilità automatica per gli SKU P non è disponibile per gli SKU F. Gli SKU F usano invece il ridimensionamento su richiesta: è possibile aumentare o ridurre manualmente le prestazioni tramite il portale di Azure.
Governance della capacità Nuove funzionalità Le nuove funzionalità di governance dei costi sono disponibili per gli SKU F, come la protezione dagli aumenti improvvisi a livello di area di lavoro e la protezione dal superamento della capacità. Usarli per controllare il consumo e prevenire i costi di fuga.
Supporto per elementi tra aree geografiche Nuova considerazione Gli elementi Power BI standard sopravvivono a una riassegnazione tra aree. I modelli semantici di formato di archiviazione di grandi dimensioni richiedono il backup e il ripristino o la cancellazione e la conversione in un formato di archiviazione di piccole dimensioni prima della riassegnazione. Tutti gli elementi Fabric (Lakehouses, Warehouses, Notebooks, Pipeline di Data Factory) causano un errore di riassegnazione.

Il percorso di migrazione a colpo d'occhio

Nel formato più puro, la migrazione da P a F è uno spostamento 1:1 allo SKU F equivalente nella stessa area Azure. I clienti spesso usano la migrazione come opportunità per consolidare le capacità, spostarsi tra aree o ridimensionare. Ognuna di queste modifiche aggiunge complessità e rischio. Considerare queste modifiche come flussi di lavoro separati che vengono eseguiti al termine della migrazione delle licenze.

La migrazione segue le stesse cinque fasi indipendentemente dalle dimensioni o dalla complessità.

  1. Decidi. Scegliere quando eseguire la migrazione, con quale SKU F iniziare e se rimanere nella stessa area Azure. Vedi guida decisionale per la migrazione dello SKU P di Power BI Premium.
  2. Piano. Esegui l'inventario delle aree di lavoro, definisci il consumo CU di riferimento usando l'app Microsoft Fabric Capacity Metrics e stima il consumo futuro con Fabric SKU Estimator. Registrare il Microsoft.Fabric provider di risorse in Azure e selezionare un'area di lavoro pilota. Per una verifica pratica prima dell'acquisto, eseguire il provisioning di una capacità di valutazione di Fabric per testare i carichi di lavoro.
  3. Provvigione. Acquistare lo SKU F prima di riassegnare qualsiasi elemento. Scegli il pagamento in base al consumo o una prenotazione e verifica le licenze di Server di report di Power BI se lo utilizzi.
  4. Esegui la migrazione e convalida. Riassegna i workspace nel portale di amministrazione Fabric o usando il notebook di migrazione della capacità. Per gli spostamenti tra regioni, ricreare i modelli semantici in formato di archiviazione di grandi dimensioni e gli elementi Fabric nella nuova regione. Convalidare gli aggiornamenti, i report e i gateway. Vedere Eseguire la migrazione di aree di lavoro da Power BI Premium a Microsoft Fabric.
  5. Dismettere e utilizzare. L'annullamento dello SKU P è manuale: Fabric non ritira automaticamente lo SKU P quando si effettua il provisioning di uno SKU F. Dopo aver convalidato la migrazione, cancella esplicitamente la sottoscrizione SKU P nell'interfaccia di amministrazione di Microsoft 365. Configurare quindi il monitoraggio dei costi usando Gestione dei costi Microsoft e sfruttare la flessibilità di sospensione, ripresa e scalabilità in Fabric.

Scenari di migrazione

La maggior parte dei clienti rientra in uno dei quattro scenari seguenti. I primi tre scenari seguono i passaggi di migrazione standard in Eseguire la migrazione delle aree di lavoro da Power BI Premium a Microsoft Fabric.

Scenario Complexity Notes
Stesso tenant, stessa area geografica Bassa Impostazione predefinita consigliata. Riassegnare ogni area di lavoro al nuovo SKU F. Nessun tempo di inattività previsto, salvo eventuali aggiornamenti in corso.
Stesso tenant, tra aree Da moderato a elevato Segue i passaggi di migrazione standard, ma i modelli semantici di formato di archiviazione di grandi dimensioni e gli elementi Fabric devono essere sottoposti a backup o acquisiti in Git, eliminati e ricreati nella nuova area. Vedere Migrazioni tra aree: gestione speciale.
Multigeo (SKU F multipli in regioni diverse, stesso tenant) Moderate Segue i passaggi di migrazione standard, ma si acquistano SKU F in ogni area di destinazione e si pianifica la governance per il contenuto specifico dell'area. Vedi Migrazioni Multigeo.
Cross-tenant Alto; non supportato come migrazione con un solo clic Non segue i passaggi di migrazione standard. Richiede la ricreazione manuale di gateway, modelli semantici, aree di lavoro, report, app e dashboard. Prendere in considerazione prima il multigeo. Vedi Migrazioni tra tenant.

Caution

Le migrazioni tra aree comportano un impegno notevolmente maggiore rispetto alle migrazioni della stessa area. Oltre ai tipi di elemento che non sopravvivono alla riassegnazione tra aree, pianificare:

  • Fabric gli elementi non sopravvivono agli spostamenti tra aree. I lakehouse, i warehouse, i notebook e le pipeline di Data Factory causano un errore di riassegnazione. Acquisire le definizioni in Git (o esportarle) prima della riassegnazione e quindi ricrearle nell'area di destinazione.
  • Riassociazione del report. Quando si esegue il backup e il ripristino, oppure si elimina e si ridistribuisce, un modello semantico in formato di archiviazione grande, il modello ricreato riceve un nuovo GUID. I report che facevano riferimento al modello originale devono essere ricollegati al modello ricreato.
  • Sovraccarico del gateway. Le destinazioni tra aree geografiche richiedono spesso una configurazione e una convalida aggiuntive del gateway dati locale, soprattutto se i gateway usano i relay di Azure con Bring Your Own Relay (BYOR), perché gli endpoint di relay sono vincolati all'area geografica.

Scegliere la migrazione tra aree solo quando è richiesta la residenza dei dati o un altro vincolo rigido. La migrazione nella stessa area è l'impostazione predefinita consigliata.

Dopo la migrazione

Dopo aver riassegnato le aree di lavoro e aver verificato che i report e gli aggiornamenti funzionino sul nuovo SKU F, è possibile assegnare a se stessi una finestra di stabilizzazione prima di annullare lo SKU P e prima di eseguire operazioni di modernizzazione facoltative. Le attività seguenti consentono di confermare che la migrazione sia andata a buon fine e di decidere cosa fare successivamente.

Stabilizzare i costi

La spesa dello SKU F è prevedibile se si mantengono le capacità in esecuzione 24 ore su 24. Il costo mensile rimane stabile, anche se le tariffe con pagamento in base al consumo sono in genere superiori rispetto allo SKU P equivalente. Usa le prenotazioni per garantirti un risparmio sui carichi di lavoro costanti e usa le funzioni di sospensione e ripresa per la capacità realmente inutilizzata durante alcune ore della giornata. Per stabilizzare i costi:

  • Tenere traccia della spesa giornaliera per i primi 30 giorni usando Gestione dei costi Microsoft.
  • Impostare Azure budget e avvisi sul gruppo di risorse della capacità in modo da ricevere una notifica prima che la spesa superi il piano.
  • Valutare una prenotazione annuale della capacità di Fabric una volta che il consumo giornaliero è costante. Le prenotazioni in genere scontino i carichi di lavoro prevedibili.
  • Sospendere le capacità inattive all'esterno dell'orario di ufficio per interrompere la fatturazione durante tali finestre.

Stabilizzare le prestazioni

Per una migrazione 1:1 nella stessa area verso lo SKU F equivalente, il consumo di CU dovrebbe avvicinarsi molto al valore di riferimento dello SKU P dopo la stabilizzazione. Prevedere una variazione delle prestazioni quando la migrazione include una modifica della configurazione, ovvero un'area diversa, una dimensione dello SKU diversa o un consolidamento del carico di lavoro, e convalidare prima di rimuovere lo SKU P. Gli overload segnalati dopo la migrazione sono spesso causati da modifiche del carico di lavoro (un burst di aggiornamenti, contenuto aggiunto, pianificazioni di aggiornamento modificate) anziché dalla migrazione stessa. Controllare i modelli di utilizzo prima di presupporre che lo SKU F sia la causa. Per stabilizzare le prestazioni:

  • Monitora la nuova capacità con l'app Microsoft Fabric Capacity Metrics per una o due settimane dopo il passaggio.
  • Confronta con la baseline registrata nello SKU P. Esaminare i delta di grandi dimensioni nella frequenza di aggiornamento, nelle dimensioni del set di dati o nel caricamento interattivo prima del ridimensionamento.
  • Aumentare le risorse in base alle esigenze tramite il portale di Azure se si riscontra una limitazione persistente. Vedi Aumentare la capacità.
  • Convalida nell’intero ciclo aziendale - includi la chiusura di fine mese e quella trimestrale - prima di considerare la baseline definitiva.
  • Controllare di nuovo la linea di base ogni volta che si aggiungono nuovi contenuti significativi o si modificano le pianificazioni di aggiornamento.
  • Convalida nuovamente dopo qualsiasi modifica della configurazione da parte tua (dimensioni SKU, regione, assegnazione del carico di lavoro).
  • Per indicazioni più dettagliate sulla pianificazione dell'espansione della capacità e sulla governance, vedi guida alla pianificazione della capacità di Microsoft Fabric.

Esaminare le operazioni e la governance

Alcune impostazioni operative non vengono trasferite automaticamente quando le aree di lavoro passano a una SKU F. Vedere gli articoli seguenti:

  • Verificare le assegnazioni di Azure RBAC sulla risorsa di capacità, in modo che gli amministratori appropriati possano gestirla.
  • Riapplicare le impostazioni del carico di lavoro a livello di capacità (ad esempio, limiti di memoria del modello semantico) nel portale di amministrazione Fabric se sono stati personalizzati nello SKU P.
  • Ricontrollare l'impostazione del tenant Gli utenti possono creare elementi Fabric ed eventuali deleghe con ambito limitato alla capacità.
  • Applica i tag di Azure alla risorsa di capacità in modo che i report di chargeback e showback attribuiscano la spesa al centro di costo corretto.
  • Valutare le nuove funzionalità di governance per l'utilizzo della capacità disponibili negli SKU F (ad esempio la protezione di picchi a livello di area di lavoro e la protezione dell'overage della capacità) per impostare protezioni prima di aprire la capacità a un consumo più ampio.

Esplorare le opportunità di modernizzazione

Molti scenari di modernizzazione Fabric sono tecnicamente possibili anche per gli SKU P. Ciò che cambia negli SKU F è il modello operativo: la gestione dei costi nativa di Azure, le funzionalità di governance della capacità (come la protezione dai picchi e dagli sforamenti) e il RBAC di Azure unificato rendono più semplice affrontare questi scenari con limiti di costo più chiari e maggiore sicurezza operativa. Queste opzioni sono azioni successive facoltative, non requisiti di migrazione:

Considerare queste opzioni come flussi di lavoro separati che vengono eseguiti al termine della migrazione delle licenze. Non bloccano la migrazione e non devono estenderne la sequenza temporale.

Contenuti correlati

  • Last updated on