Übersicht zur Migration von Power BI Premium zu Microsoft Fabric

Microsoft stellt die kapazitätsbasierten Power BI Premium-SKUs (P-SKUs) ein. Jedes P-SKU-Abonnement endet am Ende seiner aktuellen Vertragslaufzeit und Microsoft verkauft keine neuen P-SKUs mehr. Damit Ihre Power BI-Workloads weiterhin ausgeführt werden, migrieren Sie auf Microsoft Fabric-Kapazitäts-SKUs (F SKUs). In diesem Artikel erhalten Sie eine end-to-End-Ansicht der Migration: Warum Fabric F-SKUs der Weg vorwärts sind, welche Änderungen und was für Endbenutzer und Administratoren gleich bleibt, die Phasen einer typischen Migration und die Szenarien, die bestimmen, wie komplex Ihre Migration ist.

Dieser Artikel richtet sich an Fabric Administratoren, Power BI Administratoren, IT-Architekten und Kapazitätsbesitzer, die die Migration planen und ausführen.

Important

Planen Sie, ihre Migration abzuschließen, bevor Ihr P-SKU-Abonnement endet. Nach Ablauf Ihres Abonnements tritt Ihre Kapazität in eine 30-tägige Nachfrist ein. Ab Dem 31. Tag wird der Zugriff gedrosselt (interaktive Vorgänge werden verzögert). Ab Tag 91 werden alle Vorgänge zurückgewiesen – Ihre Daten bleiben gespeichert, sind jedoch nicht zugänglich, bis Sie die Arbeitsbereiche in eine Fabric F-SKU-Kapazität migrieren oder die Kapazität löschen. Um Unterbrechungen zu vermeiden, weisen Sie Ihre Arbeitsbereiche einer Fabric F-SKU-Kapazität neu zu, bevor Ihr P-SKU-Abonnement endet. Informationen zum Verfahren finden Sie unter Migrieren von Arbeitsbereichen von Power BI Premium zu Microsoft Fabric.

Note

Enterprise Agreement-Kunden. Wenn Ihr Enterprise Agreement noch aktiv ist, können Sie weiterhin vorhandene P-SKU-Kapazität ausführen und sie jährlich über Ihre Vereinbarung verlängern, bis die EA-Laufzeit endet. Kunden mit ablaufenden Enterprise Agreements oder Microsoft Cloud Vereinbarungen können keine neue P-SKU-Kapazität über ihre Vereinbarung hinzufügen oder erwerben. Klären Sie Ihre spezifischen Vertragsbedingungen mit Ihrem Microsoft-Kundenbetreuer, bevor Sie entscheiden, wann Sie migrieren.

Note

Diese Stilllegung hat zwei wichtige Einschränkungen des Geltungsbereichs:

  • Lizenzen pro Benutzer sind nicht betroffen.Power BI Pro und Power BI Premium Per User (PPU) bleiben unverändert. Weitere Informationen finden Sie unter "Wird Power BI Premium Per User (PPU) ebenfalls eingestellt?
  • Eingebettete Lizenzen (EM, A) sind nicht betroffen. Diese SKUs sind nicht von dieser Außerbetriebnahme betroffen.
  • Souveräne Clouds sind noch nicht betroffen. Microsoft Fabric ist in souveränen Clouds nicht verfügbar, sodass P-SKUs dort weiterhin unterstützt werden. Microsoft bietet separate Anleitungen, wenn Fabric in diesen Umgebungen verfügbar werden.

Gründe für die Migration zu Microsoft Fabric

Die Einstellung von P-SKUs ist der unmittelbare Auslöser, aber Fabric F-SKUs bieten auch Funktionen, die P-SKUs nicht bieten können:

  • Sie zahlen nur für wirklich genutzte Ressourcen. F-SKUs verwenden standardmäßig die nutzungsbasierte Azure-Abrechnung, mit optionalen jährlichen oder mehrjährigen Reservierungen für vorhersehbare Workloads. Sie können eine Kapazität auch anhalten, wenn sie ungenutzt ist, um die Abrechnung außerhalb der Geschäftszeiten auszusetzen und sie später bei Bedarf wieder aufzunehmen.
  • Sie können jederzeit nach oben oder unten skalieren. Ändern Sie die Größe der Kapazitäten über das Azure-Portal, während sich Ihre Workloads ändern, anstatt sich für die Laufzeit eines Abonnements zu einer festen Größe zu verpflichten.
  • Verwenden Sie das Azure native Betriebssystemmodell. Stellen Sie die Kapazität im Azure-Portal bereit und verwalten Sie sie, wenden Sie Azure-Tags zur Kostenumlage an, und rechnen Sie die Fabric-Ausgaben auf Ihr Microsoft Azure Consumption Commitment (MACC) an. Viele Fabric-Workloads (z. B. Lakehouses, Warehouses, Notebooks und Data Factory-Pipelines) werden entweder auf P- oder F-Kapazitäten ausgeführt, das Azure-Betriebsmodell unterstützt jedoch nur F-Kapazitäten.
  • Verwenden Sie Power BI Embedded ohne separate SKUs. Eingebettete Szenarien werden von jeder F-SKU abgedeckt, daher benötigen Sie keine separaten EM- oder A-SKUs.
  • Verwenden Sie Azure systemeigene Sicherheit und Vorgänge. Verwaltete private Endpunkte, vertrauenswürdiger Arbeitsbereichszugriff, Azure Monitor und Microsoft Cost Management sind alle mit F-SKUs verfügbar.

Die wichtigsten Unterschiede zwischen Power BI Premium P-SKUs und Fabric F-SKUs finden Sie im Vollständigen Funktionsvergleich.

Was sich ändert und was unverändert bleibt

Die Migration umfasst in erster Linie eine Lizenzierungs- und Infrastrukturänderung. Endbenutzeroberflächen und die meisten verwaltungstechnischen Verhaltensweisen bleiben gleich. Einige betriebliche Bereiche ändern sich.

Area Veränderung? Nach der Migration zu F-SKU
Berichte, semantische Modelle, Dashboards identisch Arbeiten Sie mit F64 oder höheren Kapazitäten unverändert weiter.
Benutzerlizenzen (Pro, PPU, Kostenlos) identisch Unverändert. Auf F64 und höheren Kapazitäten können Benutzer mit einer kostenlosen Fabric-Lizenz und der Rolle „Viewer“ Inhalte anzeigen, genauso wie bei P-SKUs. Für F2 bis F32 benötigt jeder Viewer eine Pro- oder PPU-Lizenz.
Arbeitsbereiche und Apps identisch Arbeitsbereiche werden der neuen Kapazität neu zugewiesen. Arbeitsbereich-Apps, Bereitstellungspipelinen und Git-Integration funktionieren weiterhin.
Aktualisieren von Zeitplänen und Pipelines identisch Arbeiten Sie weiterhin mit der neuen Kapazität. Aktive Aktualisierungen können während der Neuzuweisung unterbrochen werden.
Power BI-Berichtsserver Identisch mit Lizenzänderung Weiterhin verfügbar mit einer reservierten Fabric-Kapazität oder einer SQL Server Enterprise Edition mit Software Assurance.
Power BI Embedded Identisch, einfacher In jeder F-SKU enthalten. Separate EM- und A-SKUs sind nicht erforderlich.
Kauf und Abrechnung Changes Wechseln Sie von Microsoft 365 Verpflichtungsabrechnung zu Azure Abrechnung. F SKUs unterstützen Pay-as-you-go sowie einjährige oder mehrjährige Reservierungen.
Kapazitätsmanagement Changes In erster Linie über das Fabric-Portal verwaltet (Arbeitsbereichszuweisungen und Einstellungen auf Kapazitätsebene). Anhalten, Fortsetzen, Hochskalieren und Herunterskalieren werden über das Azure Portal ausgeführt.
Automatische Skalierung Changes Die automatische Skalierung für P-SKUs ist für F-SKUs nicht verfügbar. Stattdessen erfolgt bei F-SKUs die Größenanpassung bei Bedarf – Sie skalieren manuell über das Azure-Portal.
Kapazitätsverwaltung Neue Funktionen Neue Funktionen für die Kostensteuerung sind für F-SKUs verfügbar, z. B. Lastspitzenschutz auf Arbeitsbereichsebene und Schutz vor Kapazitätsüberschreitungen. Verwenden Sie sie, um den Verbrauch zu steuern und ausufernde Kosten zu vermeiden.
Unterstützung für regionsübergreifende Elemente Neue Überlegungen Standard-Power BI Elemente überleben eine regionsübergreifende Neuzuweisung. Für semantische Modelle im großen Speicherformat ist vor der Neuzuweisung eine Sicherung und Wiederherstellung oder das Löschen und die Konvertierung in das kleine Speicherformat erforderlich. Alle Fabric-Elemente (Lakehouses, Warehouses, Notebooks, Data Factory-Pipelines) führen dazu, dass die Neuzuweisung fehlschlägt.

Die Migrationsreise auf einen Blick

In ihrer reinsten Form ist die P-zu-F-Migration eine 1:1-Umstellung auf die entsprechende F-SKU in derselben Azure-Region. Kunden nutzen die Migration häufig als Möglichkeit, Kapazitäten zu konsolidieren, sich über Regionen zu bewegen oder die Größe zu ändern. Jede dieser Änderungen fügt Komplexität und Risiko hinzu. Behandeln Sie diese Änderungen als separate Arbeitsstränge, die nach Abschluss der Lizenzmigration ablaufen.

Die Migration folgt unabhängig von Größe oder Komplexität auf die gleichen fünf Stufen.

  1. Entscheiden. Wählen Sie aus, wann Sie migrieren, mit welcher F-SKU Sie beginnen und ob Sie in derselben Azure-Region bleiben möchten. Siehe Entscheidungsleitfaden zur SKU-Migration für Power BI Premium P.
  2. Plan. Inventarisieren Sie Arbeitsbereiche, ermitteln Sie den Basis-CU-Verbrauch mithilfe der Microsoft Fabric Capacity Metrics-App und schätzen Sie den zukünftigen Verbrauch mit dem Fabric SKU Estimator. Registrieren Sie den Microsoft.Fabric Ressourcenanbieter in Azure, und wählen Sie einen Pilotarbeitsbereich aus. Stellen Sie für die praktische Überprüfung vor dem Kauf eine Fabric Testkapazität zum Testen von Workloads bereit.
  3. Bereitstellung. Kaufen Sie die F-SKU, bevor Sie irgendetwas erneut zuweisen. Wählen Sie zwischen nutzungsbasierter Bezahlung und einer Reservierung, und überprüfen Sie die Lizenzierung für Power BI-Berichtsserver, wenn Sie ihn verwenden.
  4. Migrieren und Überprüfen. Weisen Sie Arbeitsbereiche im Fabric Admin-Portal oder mithilfe des Kapazitätsmigrationsnotizbuchs neu zu. Erstellen Sie bei regionenübergreifenden Verschiebungen Semantikmodelle im Large-Storage-Format und Fabric-Elemente in der neuen Region neu. Überprüfen Sie Aktualisierungen, Berichte und Gateways. Siehe Migrieren von Arbeitsbereichen von Power BI Premium zu Microsoft Fabric.
  5. Außerbetriebnahme und Betrieb. Die Außerbetriebnahme Ihrer P-SKU erfolgt manuell – Fabric setzt Ihre P-SKU nicht automatisch außer Betrieb, wenn Sie eine F-SKU bereitstellen. Nachdem Sie die Migration überprüft haben, kündigen Sie das P-SKU-Abonnement im Microsoft 365 Admin Center explizit. Richten Sie dann die Kostenüberwachung mithilfe von Microsoft Cost Management ein, und nutzen Sie pausen-, fortsetzungs- und skalierungsflexibilität in Fabric.

Migrationsszenarios

Die meisten Kunden fallen in eines der folgenden vier Szenarien. Die ersten drei Szenarien folgen den Standardschritten für die Migration in Arbeitsbereiche von Power BI Premium zu Microsoft Fabric migrieren.

Scenario Complexity Hinweise
Derselbe Mandant, dieselbe Region Niedrig Die empfohlene Standardeinstellung. Weisen Sie jedem Arbeitsbereich die neue F-SKU neu zu. Null erwartete Ausfallzeiten abgesehen von aktiven Aktualisierungen.
Derselbe Mandant, regionübergreifend Mittel bis hoch Folgt den Standardschritten für die Migration, aber Semantikmodelle im Large-Storage-Format und Fabric-Elemente müssen gesichert oder in Git erfasst, gelöscht und in der neuen Region neu erstellt werden. Siehe regionsübergreifende Migrationen: Spezielle Behandlung.
Multigeo (mehrere F-SKUs in verschiedenen Regionen, im selben Mandanten) Mäßig Folgt den standardmäßigen Schritten für die Migration, aber Sie erwerben F-SKUs in jeder Zielregion und legen Governance-Richtlinien für regionenspezifische Inhalte fest. Siehe Multigeo-Migrationen.
mandantenübergreifend Hoch; wird nicht als Migration mit nur einem Klick unterstützt Führt nicht die standardmäßigen Migrationsschritte aus. Erfordert eine manuelle Wiederherstellung von Gateways, semantischen Modellen, Arbeitsbereichen, Berichten, Apps und Dashboards. Betrachten Sie zuerst multigeo. Siehe mandantenübergreifende Migrationen.

Caution

Regionsübergreifende Migrationen erfordern deutlich mehr Aufwand als Migrationen in derselben Region. Berücksichtigen Sie zusätzlich zu den Elementtypen, die eine regionsübergreifende Neuzuweisung nicht überstehen:

  • Fabric Elemente überstehen keine regionsübergreifenden Verschiebungen. Lakehouses, Warehouses, Notebooks und Data Factory-Pipelines führen dazu, dass die Neuzuweisung fehlschlägt. Erfassen Sie ihre Definitionen vor der Neuzuweisung an Git (oder exportieren Sie sie), und erstellen Sie sie dann in der Zielregion neu.
  • Bericht neu binden. Wenn Sie ein großes Semantikmodell im Speicherformat sichern und wiederherstellen (oder löschen und erneut bereitstellen), erhält das neu erstellte Modell eine neue GUID. Berichte, auf die auf das ursprüngliche Modell verwiesen wurde, müssen an das neu erstellte Modell zurückgebunden werden.
  • Gateway-Mehraufwand. Regionsübergreifende Ziele erfordern häufig zusätzliche lokale Datengatewaykonfiguration und -validierung, insbesondere, wenn Ihre Gateways Azure Relays unter Bring Your Own Relay (BYOR) verwenden, da Relayendpunkte regionsgebunden sind.

Wählen Sie die regionenübergreifende Migration nur dann, wenn Datenresidenz oder eine andere zwingende Vorgabe dies erfordert. Die Migration innerhalb derselben Region ist die empfohlene Standardeinstellung.

Nach der Migration

Nachdem Sie Arbeitsbereiche neu zugewiesen und überprüft haben, ob Berichte und Aktualisierungsvorgänge mit der neuen F-SKU funktionieren, planen Sie ein Zeitfenster zur Stabilisierung ein, bevor Sie die P-SKU kündigen und bevor Sie optionale Modernisierungsarbeiten durchführen. Die folgenden Maßnahmen helfen Ihnen, zu überprüfen, ob die Migration reibungslos abgeschlossen wurde, und zu entscheiden, was als Nächstes zu tun ist.

Stabilisierung der Kosten

F-SKU-Ausgaben sind vorhersagbar, wenn Sie kapazitäten rund um die Uhr laufen lassen. Ihre monatlichen Kosten bleiben stabil, obwohl nutzungsbasierte Tarife in der Regel höher sind als der entsprechende P-SKU. Verwenden Sie Reservierungen, um sich Kosteneinsparungen für konstante Workloads zu sichern, und verwenden Sie Anhalten und Fortsetzen für Kapazitäten, die während Teilen des Tages tatsächlich ungenutzt sind. So stabilisieren Sie die Kosten:

  • Verfolgen Sie tägliche Ausgaben für die ersten 30 Tage mithilfe von Microsoft Cost Management.
  • Richten Sie Budgets und Warnungen in Azure für die Ressourcengruppe der Kapazität ein, damit Sie benachrichtigt werden, bevor die Ausgaben das geplante Budget überschreiten.
  • Ziehen Sie eine jährliche Kapazitätsreservierung für Fabric in Betracht, sobald der tägliche Verbrauch stabil ist. Reservierungen reduzieren in der Regel vorhersagbare Workloads.
  • Pausieren Sie Kapazitäten, die außerhalb der Geschäftszeiten inaktiv sind, damit in diesen Zeitfenstern keine Gebühren anfallen.

Stabilisierung der Leistung

Bei einer 1:1-In-Region-Migration zur entsprechenden F-SKU sollte der CU-Verbrauch nach der Stabilisierung genau mit Ihrem P-SKU-Basisplan übereinstimmen. Rechnen Sie mit Leistungsschwankungen, wenn die Migration eine Konfigurationsänderung umfasst – eine andere Region, eine andere SKU-Größe oder eine Workloadkonsolidierung – und validieren Sie dies, bevor Sie die P-SKU außer Betrieb setzen. Gemeldete Überladungen nach der Migration werden häufig durch Workloadänderungen verursacht (ein Schub von Aktualisierungen, hinzugefügte Inhalte, geänderte Aktualisierungszeitpläne) und nicht durch die Migration selbst. Überprüfen Sie Verwendungsmuster, bevor Sie davon ausgehen, dass die F-SKU die Ursache ist. So stabilisieren Sie die Leistung:

  • Überwachen Sie die neue Kapazität nach der Umstellung ein bis zwei Wochen lang mit der Microsoft Fabric App für Kapazitätsmetriken.
  • Vergleichen Sie dies mit der Baseline, die Sie auf der P-SKU erfasst haben. Untersuchen Sie große Deltas in Aktualisierungshäufigkeit, Datasetgröße oder interaktiver Auslastung, bevor Sie die Größe ändern.
  • Skalieren Sie bei Bedarf über das Azure-Portal hoch, wenn Sie eine anhaltende Drosselung feststellen. Weitere Informationen finden Sie unter Skalieren der Kapazität.
  • Überprüfen Sie einen vollständigen Geschäftszyklus , einschließlich Monatsende und Quartalsschluss, bevor Sie den Basisplan als abgeschlossen behandeln.
  • Überprüfen Sie den Basisplan, wenn Sie wichtige neue Inhalte hinzufügen oder Aktualisierungszeitpläne ändern.
  • Überprüfen Sie nach jeder Konfigurationsänderung auf Ihrer Seite erneut (SKU-Größe, Region, Workloadzuweisung).
  • Eine umfassendere Anleitung zur Planung von Kapazitätswachstum und -governance finden Sie im Leitfaden zur Kapazitätsplanung Microsoft Fabric.

Überprüfung von Abläufen und Governance

Einige Betriebseinstellungen werden nicht automatisch übernommen, wenn Arbeitsbereiche zu einer F-SKU wechseln. Lesen Sie Folgendes:

  • Bestätigen Sie Azure RBAC-Zuordnungen für die Kapazitätsressource, damit die richtigen Administratoren sie verwalten können.
  • Erneutes Anwenden von Workloadeinstellungen auf Kapazitätsebene (z. B. Speichergrenzwerte für semantische Modelle) im Fabric Admin-Portal, wenn sie auf der P-SKU angepasst wurden.
  • Überprüfen Sie erneut die Mandanteneinstellung Benutzer können Fabric-Elemente erstellen und alle kapazitätsbezogenen Delegierungen.
  • Wenden Sie Azure-Tags auf die Kapazitätsressource an, damit Chargeback- und Showbackberichte die Ausgaben der richtigen Kostenstelle zuordnen.
  • Bewerten Sie neue Features zur Steuerung der Kapazitätsauslastung, die für F-SKUs verfügbar sind (z. B. Schutz vor Lastspitzen auf Arbeitsbereichsebene und Schutz vor Kapazitätsüberschreitungen), um Leitplanken festzulegen, bevor Sie die Kapazität für eine breitere Nutzung freigeben.

Erkunden von Modernisierungsmöglichkeiten

Viele Fabric-Modernisierungsszenarien sind technisch auch mit P-SKUs möglich. Was sich bei F-SKUs ändert, ist das Betriebsmodell: Azure-native Kostenverwaltung, Funktionen für die Kapazitätsgovernance (z. B. Schutz vor Lastspitzen und Mehrverbrauch) und einheitliches Azure RBAC erleichtern die Umsetzung dieser Szenarien mit klareren Leitplanken für Kosten und mehr betrieblicher Sicherheit. Bei diesen Optionen handelt es sich um optionale Nachverfolgungsanforderungen und nicht um Migrationsanforderungen:

  • Vorhandene Daten mithilfe von Spiegelung und Tastenkombinationen in OneLake übertragen.
  • Konvertieren Sie DirectQuery-Semantikmodelle zu Direct Lake, wenn die Workloads davon profitieren.
  • Übernehmen Sie OneLake-Sicherheit für einheitliche Datenzugriffssteuerungen über Fabric Workloads hinweg.

Behandeln Sie diese Optionen als separate Arbeitsstränge, die nach Abschluss der Lizenzmigration ablaufen. Sie blockieren die Migration nicht und sollten ihre Zeitachse nicht erweitern.

Verwandte Inhalte

  • Last updated on