Power BI zu Microsoft Fabric migrieren: Was bleibt, was sich ändert

Du möchtest Power BI zu Microsoft Fabric migrieren, ohne funktionierende Berichte und Datenmodelle neu aufzubauen? Dann hilft zuerst eine Klarstellung: Power BI ist Bestandteil von Microsoft Fabric. Es geht deshalb meist nicht um einen vollständigen Systemwechsel, sondern darum, Deinen bestehenden BI-Einsatz um Datenintegration, zentrale Datenhaltung und weitere Analysefunktionen zu erweitern. Entscheidend ist, welche Engpässe Du lösen möchtest – und welche Änderungen dafür tatsächlich notwendig sind.

Kurz gesagt: Bestehende Power-BI-Berichte und semantische Modelle lassen sich in der Regel weiterverwenden; Fabric erzwingt weder einen Wechsel zu OneLake noch zu Direct Lake. Anpassungen werden nötig, wenn Du Datenquellen, Verarbeitungswege, Speichermodus oder Zugriffswege veränderst. Eine gezielte Erweiterung beginnt deshalb mit einer Bestandsaufnahme und einem fachlich abgegrenzten Pilotprojekt.

Muss ich Power BI zu Microsoft Fabric migrieren?

Ein bestehender Power-BI-Einsatz muss nicht vollständig zu Fabric migriert werden, weil Power BI bereits Teil der Plattform ist. Zusätzliche Fabric-Funktionen kannst Du schrittweise einführen, während vorhandene Berichte weiterlaufen.

Unterscheide drei Vorhaben:

• Bestehendes BI weiterbetreiben: Berichte, semantische Modelle und Datenquellen bleiben unverändert.
• Fabric ergänzen: Neue Datenpipelines, Lakehouses oder Warehouses liefern zusätzliche Daten für Power BI.
• Architektur umbauen: Bestehende Aufbereitung und Datenhaltung werden gezielt nach Fabric verlagert.

Die Zuordnung eines Arbeitsbereichs zu einer Fabric-Kapazität kopiert noch keine Quelldaten nach OneLake und stellt keine Modelle automatisch auf Direct Lake um. Sie schafft zunächst die kapazitätsseitige Grundlage für entsprechende Workloads. Zusätzlich müssen Mandanteneinstellungen, Berechtigungen und verfügbare Funktionen passen.

Welche Power-BI-Komponenten kann ich weiterverwenden?

Berichte, DAX-Kennzahlen und semantische Modelle sind bei einer Fabric-Erweiterung meist weiter nutzbar. Wie viel Anpassung nötig ist, hängt vor allem davon ab, ob die fachliche und technische Schnittstelle zum Bericht stabil bleibt.

Berichte und semantische Modelle

Bleiben Tabellen, Spalten, Beziehungen und Kennzahlen erhalten, müssen Visualisierungen normalerweise nicht neu entwickelt werden. Import- und DirectQuery-Modelle bleiben gültige Architekturentscheidungen. Direct Lake ist eine zusätzliche Option, keine Pflicht.

Wechselst Du hingegen das semantische Modell oder entfernst Felder, musst Du abhängige Berichte prüfen und gegebenenfalls neu anbinden. Auch scheinbar kleine Änderungen an Datentypen oder Beziehungen können Ergebnisse beeinflussen.

Arbeitsbereiche, Apps und Gateways

Bestehende Arbeitsbereiche und veröffentlichte Power-BI-Apps können grundsätzlich bestehen bleiben. Eine neue Arbeitsbereichsstruktur kann trotzdem sinnvoll sein, wenn Datenplattform und Fachbereichsberichte unterschiedliche Verantwortliche haben.

Ein vorhandenes lokales Datengateway wird nicht allein durch Fabric überflüssig. Es bleibt relevant, wenn lokale oder abgeschottete Quellen weiterhin darüber erreicht werden müssen. Für neue Fabric-Verbindungen prüfst Du separat, ob Connector, Authentifizierung und Netzwerkzugang unterstützt werden.

Wann muss ich die Datenhaltung für Fabric ändern?

Die Datenhaltung muss sich erst ändern, wenn Dein Zielbild eine andere Speicherung oder Bereitstellung verlangt. Ein bestehendes SQL-System oder Data Warehouse kann weiterhin Datenquelle für Power BI bleiben.

Eine Verlagerung wird interessant, wenn mehrere Teams dieselben Daten aufbereiten, historische Daten zentral verfügbar sein sollen oder neue Analyseverfahren auf gemeinsame Datenbestände zugreifen müssen.

Lakehouse, Warehouse oder bestehende Quelle?

Ein Fabric Warehouse passt häufig zu SQL-orientierter Modellierung und relationalen Analyseprozessen. Ein Lakehouse eignet sich besonders, wenn dateibasierte Daten, Spark-Verarbeitung und offene Delta-Tabellen wichtig sind. Die Auswahl folgt Deinen Verarbeitungsschritten und den Fähigkeiten Deines Teams, nicht dem Produktnamen.

OneLake-Shortcuts können unterstützte Datenbestände zugänglich machen, ohne dafür eine vollständige zusätzliche Kopie anzulegen. Sie ersetzen aber weder eine Prüfung der Quellverfügbarkeit noch ein Zugriffskonzept.

Wann ist Direct Lake sinnvoll?

Direct Lake kann semantische Modelle auf unterstützten Delta-Tabellen aufbauen, ohne Daten wie bei einem klassischen Import vollständig in das Modell zu kopieren. Ob das Vorteile bringt, hängt unter anderem von Datenstruktur, Modellfunktionen, Sicherheitsanforderungen und Kapazität ab.

Teste deshalb reale Berichtsabfragen. Ein gut optimiertes Importmodell kann für Deinen Anwendungsfall weiterhin die bessere Wahl sein.

Welche Pipelines und Aktualisierungen muss ich anpassen?

Bestehende Aktualisierungen müssen angepasst werden, wenn sich Datenquellen, Transformationen oder Abhängigkeiten ändern. Neue Fabric-Pipelines ersetzen vorhandene Power-BI-Aktualisierungen nicht automatisch.

Erfasse zunächst, wo Geschäftslogik heute liegt: in SQL, Power Query, Dataflows oder externen ETL-Werkzeugen. Sonst verschiebst Du doppelte Transformationen lediglich auf eine neue Plattform.

Power-BI-Dataflows Gen1 und Dataflows Gen2 sind unterschiedliche Artefakte. Eine Arbeitsbereichszuordnung wandelt Gen1 nicht automatisch in Gen2 um. Bei einer Überführung prüfst Du Abfragen, unterstützte Connectoren, Zieltabellen, Zugangsdaten und Aktualisierungsverhalten.

Für verlässliche Abläufe brauchst Du:

• eine Reihenfolge von Datenübernahme, Transformation und Modellaktualisierung,
• Fehlerbehandlung und Benachrichtigungen,
• nachvollziehbare Laufzeiten und Datenstände,
• Tests für inkrementelle Verarbeitung und Wiederholungen.

Wichtig ist außerdem die Begriffstrennung: Datenpipelines orchestrieren Datenverarbeitung. Deployment-Pipelines unterstützen die Bereitstellung von Inhalten zwischen Entwicklungs-, Test- und Produktivumgebungen. Du brauchst dafür unterschiedliche Prüfungen und Verantwortlichkeiten.

Was ändert sich bei Berechtigungen und Lizenzen?

Power-BI-Berechtigungen allein reichen nicht aus, um neue Fabric-Datenzugriffe abzusichern. Zusätzlich zu Berichts- und Modellrechten musst Du Arbeitsbereichsrollen, Elementfreigaben und die jeweils verwendeten Datenzugriffswege betrachten.

Sicherheit entlang des Zugriffswegs prüfen

Row-Level Security im semantischen Modell schützt nicht automatisch jeden direkten Zugriff auf zugrunde liegende Daten. Wer zusätzlich auf ein Warehouse oder Lakehouse zugreifen darf, benötigt ein dafür passendes Sicherheitskonzept.

Prüfe mit konkreten Testidentitäten:

• Welche Berichte darf die Person öffnen?
• Darf sie eigene Auswertungen auf dem Modell erstellen?
• Kann sie Daten über SQL oder andere Schnittstellen direkt lesen?
• Besitzt sie eine Arbeitsbereichsrolle mit weitergehenden Rechten?

Dokumentiere außerdem, unter welcher Identität Verbindungen und automatisierte Prozesse ausgeführt werden.

Kapazität ist nicht gleich Benutzerlizenz

Für Fabric-Workloads wie Lakehouse oder Warehouse benötigst Du eine dafür geeignete Kapazität; Power BI Pro oder Premium pro Benutzer allein ersetzt diese nicht. Für Power-BI-Inhalte gelten zusätzlich Benutzerlizenz- und Verteilungsregeln.

Bei F-Kapazitäten unter F64 benötigen auch reine Berichtskonsumenten grundsätzlich Pro oder PPU. Ab F64 können Nutzer mit kostenloser Lizenz unter den vorgesehenen Bedingungen Inhalte konsumieren; Ersteller benötigen in der Regel weiterhin Pro oder PPU. Prüfe vor der Beschaffung die aktuellen Microsoft-Bedingungen und Dein konkretes Verteilungsszenario.

So gehen wir vor

Ailio begleitet Unternehmen aus Bielefeld/Ostwestfalen-Lippe, Hamburg und darüber hinaus bei der gezielten Erweiterung ihrer BI-Landschaft. Unser Ausgangspunkt ist nicht der Austausch funktionierender Berichte, sondern ein überprüfbares fachliches Ziel.

1. Bestand und Engpass erfassen

Wir inventarisieren Modelle, Berichte, Datenquellen, Gateways, Dataflows und Berechtigungen. Gemeinsam priorisieren wir ein Problem, etwa unzuverlässige Aktualisierungen oder mehrfach gepflegte Aufbereitungslogik.

2. Zielarchitektur und Pilot festlegen

Wir entscheiden, welche Komponenten bleiben und welche Fabric ergänzt. Der Pilot umfasst einen vollständigen Weg von der Quelle bis zum Bericht – einschließlich Lizenzen, Zugriffsschutz und Betriebsverantwortung.

3. Parallel testen und vergleichen

Wir vergleichen Kennzahlen, Datenvollständigkeit, Laufzeiten und Berechtigungen mit dem bisherigen System. Fachliche Abnahmekriterien und ein Rückfallplan stehen vor der Umschaltung fest.

4. Kontrolliert ausrollen

Erst nach der Abnahme folgen weitere Anwendungsfälle. Monitoring, Dokumentation und klare Zuständigkeiten gehören zur Einführung; alte Abläufe werden erst abgeschaltet, wenn ihre Abhängigkeiten geklärt sind.

Dein nächster Schritt

Erweitere Power BI dort um Fabric, wo Du einen konkreten Nutzen nachweisen kannst. Bewährte Berichte dürfen bleiben; Datenhaltung, Pipelines und Sicherheit veränderst Du gezielt statt pauschal.

Du möchtest wissen, welche Komponenten in Deiner Umgebung betroffen sind? Mit unserer Microsoft Fabric Beratung klärst Du Zielarchitektur, Migrationsumfang und einen sinnvollen ersten Anwendungsfall.