Power BI Mandantenmigrationsmuster und -strategien

Organisationen stehen verschiedenen Mandantenmigrationsszenarien in Power BI gegenüber, die durch Fusionen und Akquisitionen, Unternehmensveräußerungen, Datenaufbewahrungsanforderungen oder regionale Complianceanforderungen gesteuert werden. Mandantenmigrationen sind komplexe Vorhaben, die sorgfältige Planung, umfassende Sicherungsstrategien und eine systematische Durchführung erfordern. Dieser Artikel enthält Anleitungen für unternehmensweite Power BI Mandantenmigrationen, einschließlich Entscheidungsframeworks, um zu bestimmen, ob die Migration erforderlich ist, und detaillierte Implementierungsmethoden für verschiedene Migrationsmuster.

Important

Mandantenmigrationen sind mit erheblichen Risiken verbunden und erfordern umfangreichen manuellen Aufwand. Microsoft bietet keine direkte Unterstützung für die Migration von Inhalten zwischen Mandanten oder innerhalb desselben Mandanten während regionaler Verlagerungen. Bevor Sie mit einer Migration fortfahren, bewerten Sie sorgfältig Alternativen wie multi-geografische Kapazitäten, die viele Szenarien ohne Komplexität und Risiko der vollständigen Mandantenmigration behandeln können.

Mandantenmigrationsszenarien

Power BI Mandantenmigration umfasst drei Szenarien. Identifizieren Sie, welche für Ihre Situation gilt, bevor Sie ihre Migration planen.

Szenario Beschreibung Typischer Trigger
Parallele Migration (mandantenübergreifende Migration) Zwei separate Microsoft 365-Mandanten werden parallel betrieben. Artefakte werden vom Quellmandanten einzeln in den Zielmandanten verschoben. Fusionen und Übernahmen, die zwei Organisationen zu einem einzigen Mandanten zusammenführen.
Mandantenteilung Ein einzelner Power BI-Mandant wird in zwei unabhängige Mandanten aufgeteilt. Artefakte, Arbeitsbereiche und Benutzer, die zur ausscheidenden Unternehmenseinheit gehören, werden selektiv ausgegliedert. Veräußerungen und Spin-offs.
Mandanten-Neuzuordnung (Mandantenverlagerung) Der Power BI Mandant wird gelöscht und in einer neuen Heimregion innerhalb desselben Microsoft 365 Mandanten neu erstellt. Die Microsoft 365 Mandanten-ID, Domäne und Benutzeridentitäten bleiben erhalten. Weitere Informationen finden Sie unter Move Power BI zwischen geografischen Regionen. Anforderungen an den Datenspeicherort, die die Heimatregion des Mandanten auf ein bestimmtes Land bzw. eine bestimmte Region festlegen.

Parallele Migrationen und Mandantenteilungen sind mandantenübergreifende Vorgänge. Tenant-Remap ist eine Regionsverlagerung innerhalb desselben Microsoft 365-Mandanten.

Note

Informationen zu Aspekten und Einschränkungen bei der Neuzuordnung eines Mandanten (regionale Verlagerung) mit Microsoft-Support finden Sie unter Verschieben Ihres Power BI-Mandanten in eine andere Region. Der Support von Microsoft ist auf das Löschen des vorherigen Mandanten und die erneute Zuordnung eines neuen Mandanten zur angegebenen Region beschränkt; eine Unterstützung bei der Migration wird nicht bereitgestellt. Sie müssen über einen Rehydratisierungsplan für Daten und Metadaten verfügen, ob über skriptierte Sicherung und Wiederherstellung, manuelle Aktionen oder einen Erholungs- und Neuladevorgang. Dieses Verfahren birgt erhebliche Risiken, einschließlich potenzieller Daten- oder Artefaktverluste, wenn Sicherungen unvollständig sind oder Artefakte weggelassen werden. Ausfallzeiten während der Mandantenneuzuordnung können zwischen drei und 24 Stunden liegen, wobei mehr Ausfallzeiten für die Wiederherstellung von Artefakten erforderlich sind.

Bewerten von Alternativen vor der Migration

Die Mandantenmigration ist mit erheblichem Risiko und Aufwand verbunden. Erkunden Sie alternative Optionen, bevor Sie fortfahren. Die folgenden Strategien können Ihnen dabei helfen, eine Mandantenmigration oder -verlagerung zu vermeiden.

Multi-Geo-Bereitstellung

Mit einer multi-geo-Bereitstellung können Sie Power BI und Fabric Kapazität in einer Region Ihrer Wahl bereitstellen, während Ihre Mandanten-Heimregion unverändert bleibt. Die Daten innerhalb dieser Kapazitäten bleiben ihren Endbenutzern nahe, und Sie können mehrere Kapazitäten in verschiedenen Regionen unter demselben Mandanten haben.

Das Migrieren von Artefakten zu einer Kapazität in einer anderen Region ist einfacher als die Migration des Mandanten selbst. Um einen Arbeitsbereich in einen anderen Bereich zu verschieben, weisen Sie den Arbeitsbereich von einer Kapazität zu einer anderen neu zu. Die Neuzuweisung erfolgt für Power BI-Elemente nahtlos.

Important

Fabric Elemente überleben die Arbeitsbereichszuordnung nicht über Kapazitäten in verschiedenen Regionen hinweg. Löschen Sie Fabric Elemente vor der Neuzuweisung des Arbeitsbereichs, und erstellen Sie sie anschließend neu, oder verwenden Sie die Git-Integration, um Fabric Elemente zu sichern und wiederherzustellen.

Berücksichtigen Sie die Multi-Geo-Bereitstellung für die folgenden Anforderungen:

  • Datenlatenz. Stellen Sie Daten und Rechenkapazität näher bei den Endbenutzern bereit, indem Sie Kapazität in der jeweiligen Region bereitstellen.
  • Datenresidenz. Ihre Daten und Berechnungen sind an Ihre Kapazitätsregion gebunden, nicht an Ihre Mandantenregion. Eine Multi-Geo-Bereitstellung hält Daten für die meisten Workloads innerhalb der Vorgaben zur Datenresidenz.

Ziehen Sie eine Mandantenneuzuordnung nur dann in Betracht, wenn die Anforderungen an die Datenresidenz so streng sind, dass sogar Mandantenmetadaten (Arbeitsbereichsdefinitionen, Metadaten semantischer Modelle, Visualmetadaten, Einstellungen, Richtlinien) und Microsoft 365-Benutzerinformationen innerhalb der Datenresidenzgrenzen verbleiben müssen.

Verwenden Sie Ihr eigenes Speicherkonto für Dataflow Gen1

Dataflow Gen1 schreibt seine Ausgabe in ein Azure Data Lake Storage (ADLS) Gen2-Konto, das sich standardmäßig in der Heimatregion des Power BI-Mandanten befindet. Wenn der Datenspeicherort von Dataflow Gen1 Ihr einziger Wohnsitz ist, konfigurieren Sie ein eigenes ADLS Gen2-Konto in der gewünschten Region, anstatt den Mandanten neu zu verschieben.

Benutzerdefiniertes Azure Relay für nicht übereinstimmende Gatewayregionen

Wenn Ihre Kapazität in einer anderen Region als Ihre Mandanten-Heimregion bereitgestellt wird, leitet der standardmäßige lokale Datengatewayendpunkt Datenverkehr zurück an die Heimregion. Um den Gatewaydatenverkehr in Ihrer Kapazitätsregion beizubehalten, konfigurieren Sie einen custom Azure relay. Eine Nichtübereinstimmung der Gatewayregion allein sollte keine Mandantenmigration auslösen.

Überprüfen des Geschäftsszenarios

Wenn eine Mandantenmigration durch einen Geschäftlichen Bedarf (z. B. Abrechnungskonsolidierung) gesteuert wird, wiegen Sie den Aufwand und das Risiko gegen das Ergebnis ab. Ein kleiner Mandant ist möglicherweise problemlos zu migrieren; ein großer Mandant mit umfangreichen Fabric-Inhalten kann es erforderlich machen, den Geschäftsbedarf vor dem Fortfahren erneut zu prüfen.

Was für die Migration unterstützt wird

Die meisten Power BI Elemente unterstützen den Definitionsexport über die Power BI Admin-API oder Workspace Scanner-API und können skripted werden. Die meisten Fabric Elemente unterstützen den Definitionsexport nicht und müssen manuell neu erstellt werden.

In der folgenden Tabelle wird der Migrationspfad für jeden Artefakttyp zusammengefasst.

Bestellung Artefakt Migrationspfad
1 Gateways Kein Migrationspfad. Muss im Zielmandanten von einem Power BI-Administrator neu konfiguriert werden.
2 Arbeitsbereiche Kein Migrationspfad. Muss im Zielmandanten neu erstellt werden. Die Massenerstellung ist mithilfe der Power BI-Administrator-API möglich.
3 Gewebe-Elemente Elemente, die die Git-Integration unterstützen, können gesichert werden, indem ein Commit für Git ausgeführt wird, die Verknüpfung vom Quellarbeitsbereich aufgehoben und eine Verknüpfung mit einem neuen Arbeitsbereich im Zielmandanten hergestellt wird. Nur die Definition wird gesichert; Daten sind nicht enthalten. Elemente, die die Git-Integration nicht unterstützen, müssen manuell neu erstellt werden. Für Lakehouse werden nur Metadaten beibehalten; Delta-Tabellen und -Schemas werden nicht übertragen.
4 Dataflows Laden Sie den JSON-Code der Definition herunter, und importieren Sie es erneut in den Zielmandanten. Skripting ist mithilfe der Administrator-API möglich.
5 Semantische Modelle /Datasets Verwenden Sie Sichern und Wiederherstellen in einem ADLS Gen2-Speicherkonto, oder laden Sie die Definition herunter und importieren Sie sie erneut. Skripting ist mithilfe der Administrator-API möglich.
6 Berichte Besitzer oder Administratoren können die .pbix-Datei herunterladen und sie erneut im Zielmandanten veröffentlichen. Exportieren Sie alternativ die JSON-Definition. Skripting ist mithilfe der Administrator-API möglich.
7 Dashboards Kein Migrationspfad. Muss manuell neu erstellt werden.
8 Power BI-Apps Kein Migrationspfad. Muss manuell neu erstellt werden.
9 Paginierte Berichte Besitzer oder Administratoren laden die RDL-Datei herunter und veröffentlichen sie im Zielmandanten.

Important

Erstellen Sie Artefakte immer in dieser Reihenfolge neu. Nachgelagerte Artefakte hängen von vorgelagerten Artefakten ab, und das Nichteinhalten dieser Reihenfolge kann während der Ausführung zu fehlerhaften Verweisen führen. Bei einer Git-Synchronisierung werden alle Elemente im Arbeitsbereich gelöscht, die im Repository nicht vorhanden sind.

Migrationsmethodik

Berücksichtigen Sie die folgenden Referenzaktivitäten. Die meisten Schritte gelten für alle drei Szenarien. Schritte, die für ein Szenario spezifisch sind, werden in ihren Überschriften aufgerufen.

Schritt 1: Ermittlung und Bestandsbewertung

Erstellen Sie ein vollständiges Inventar von Artefakten und Abhängigkeiten und identifizieren Sie, was Sie migrieren können, nicht migrieren können oder nicht migrieren sollten.

Aktivitäten

  • Führen Sie die mandantenweite Erkennung aus, indem Sie eine Kombination aus Folgendem verwenden:
    • Power BI-Administrator-APIs
    • Fabric-Administrator-APIs
    • Aktivitätsprotokolle (Arbeitsbereiche, Berichte, Datensätze, Aktualisierungen)
    • Manuelle Dokumentation für Elemente, die von APIs nicht verfügbar gemacht werden
  • Erfassen:
    • Arbeitsbereiche (Typ, Kapazität, Region)
    • Berichte, semantische Modelle (insbesondere großes Speicherformat), Datenflüsse
    • Fabric-Elemente (Lakehouse, Warehouse, Eventhouse, Notebooks)
    • Gateways, Datenquellen, Anmeldeinformationen
    • Rollen für Sicherheit auf Zeilenebene (RLS), Arbeitsbereichsberechtigungen, Freigabelinks
  • Klassifizieren Sie jeden Arbeitsbereich nach Migrationskomplexität (niedrig, mittel, hoch), basierend auf den darin enthaltenen Artefakten und Abhängigkeiten.

Ausgaben

  • Eine primäre Bestandstabelle.
  • Eine Klassifizierung der Migrationskomplexität für jeden Arbeitsbereich.

Schritt 2: Benutzer- und Sicherheitsermittlung

Erfassen Sie Benutzeridentitäten, Lizenzen und Berechtigungen und bilden Sie diese bei Bedarf zwischen Mandanten ab.

In einer Mandanten-Neuzuordnung werden Benutzerobjekt-IDs beibehalten. Bei einer parallelen Migration oder Mandantenteilung haben Benutzer im Zielmandanten unterschiedliche Objekt-IDs. Ordnen Sie jede Quellmandantenidentität ihrer Zielmandantenidentität zu. Power BI-Lizenzzuweisungen neu zuweisen (Free, Pro, PPU). Spiegelung von Sicherheitsgruppen im neuen Microsoft 365 Mandanten.

Aktivitäten

Identifizieren und Aufzeichnen:

  • Power BI Lizenzzuweisungen (stammen aus Microsoft Graph)
  • Benutzerobjekt-IDs im Quellmandanten
  • Benutzerobjekt-IDs im Zielmandanten (nur Seite an Seite oder geteilt)
  • Benutzerberechtigungen und Zugriffsebenen für Arbeitsbereiche
  • Aktuelle Einstellungen auf Mandantenebene (manuell über das Verwaltungsportal erfassen)
  • Aktuelle Governancekonfigurationen (Vertraulichkeitsbezeichnungen, Bestätigungsrichtlinien)

Sie können Arbeitsbereichs- und Artefaktberechtigungen mithilfe der Power BI Admin-APIs und der Workspace Scanner-API extrahieren.

Schritt 3: Kommunikation und Change Management von Stakeholdern

Kommunizieren Sie den Migrationsplan frühzeitig, um Widerstände und den Supportaufwand zu verringern.

Wichtige Stakeholdergruppen

  • Leitende Sponsoren
  • Arbeitsbereichsbesitzer und Berichtsautoren
  • Endbenutzer
  • IT-, Sicherheits- und Identitätsteams

Aktivitäten

  • Entwickeln eines Kommunikationsplans, der Folgendes abdeckt:
    • Migrationsübersicht und -rationale.
    • Was nicht migriert wird (z. B. persönliche Arbeitsbereiche, Leerlaufarbeitsbereiche).
    • Welche Änderungen (URLs, Zugriff, Aktualisierungszeitpunkt). Nachgeschaltete Power Apps- und SharePoint-Links, die auf Power BI URLs verweisen, sind ebenfalls betroffen.
    • Was sich nicht ändert (Datensemantik, visuelle Elemente, Geschäftslogik).
  • Kommunizieren Sie wichtige Datumsangaben:
    • Sperrfrist (in der Regel etwa eine Woche ohne Änderungen im Quellmandanten während der abschließenden Sicherung).
    • Erwartete Ausfallzeit (für Szenarien zur Neuzuordnung von Mandanten).
    • Validierungszeiträume für Beteiligte zur Überprüfung ihrer eigenen Berichte im Zielmandanten.
    • Meilensteine der Umstellung und Stilllegungstermine für den Quellmandanten (Side-by-Side-Szenarien).

Ausgaben

  • Ein Stakeholder-Briefing-Deck.
  • Häufig gestellte Fragen zu Endbenutzern.

Schritt 4: Übermitteln einer Mandanten-Remap-Anforderung (nur Mandanten-Neuzuordnung)

Wenn das Migrationsdatum gesperrt ist, reichen Sie ein Support-Ticket ein und wählen Sie dabei gezielt die Option „Mandanten-Neuzuordnung“ aus. Ein Microsoft Supporttechniker übernimmt die Anfrage.

Aktivitäten

  • Reichen Sie das Support-Ticket ein.
  • Füllen Sie die Prüfliste für die Bereitschaft aus, die von Microsoft bereitgestellt wird.
  • Vereinbaren Sie ein Migrationsdatum und ein Zeitfenster, einschließlich eines Sicherungszeitfensters.
  • Vorhandene Kapazität löschen, bevor die Mandanten-Neuzuordnung stattfindet.

Erwartete Ergebnisse

  • Eine typische Remap dauert etwa drei Stunden, aber Verzögerungen von bis zu 24 Stunden sind möglich, wenn Komplikationen auftreten.
  • Nach Abschluss der Neuzuordnung verfügt der neue Mandant über dieselbe Mandanten-ID und befindet sich in der angeforderten Region.

Schritt 5: Zielmandantenbereitschaft

Ein neu erstellter oder neu zugeordneter Mandant ist nicht sofort für den Empfang von Inhalten bereit. Konfigurieren Sie sie zuerst.

Aktivitäten

  • Konfigurieren sie Power BI Mandanteneinstellungen:
    • Steuerelemente zum Erstellen von Arbeitsbereichen
    • Richtlinien für Teilen und externen Zugriff
    • Governance für benutzerdefinierte visuelle Elemente
    • Vertraulichkeitsbezeichnungen und Informationsschutz
    • Aktivierung von Auditprotokoll und Überwachung
  • Kaufen Sie Fabric-Kapazitäten mit derselben oder einer höheren SKU als die Quellkapazität.
  • Konfigurieren und Überprüfen von Gateways, Gatewayclustern und Datenkonnektivität.
  • Für Parallelbetriebs- oder Mandantenaufteilungsszenarien:
    • Erstellen Sie einen Benutzer im Zielmandanten für jeden Benutzer im Quellmandanten, und notieren Sie die Benutzerzuordnung.
    • Erstellen Sie die Benutzergruppen aus dem Quellmandanten neu.
    • Weisen Sie Power BI Lizenzen im Zielmandanten zu.
  • Governance ausrichten: Vertraulichkeitsbezeichnungen, Microsoft Purview Integration und Bestätigungsrichtlinien.

Schritt 6: Migrationspilot

Führen Sie vor der Produktionsmigration eine Testmigration für einen repräsentativen Beispielarbeitsbereich aus.

Bei Side-by-Side-Migrationen bleibt der Quellmandant als Fallback für erneute Versuche verfügbar. Bei der Mandantenneuzuordnung können Inhalte, die vor der Neuzuordnung nicht ordnungsgemäß gesichert wurden, nicht wiederhergestellt werden. Ein erfolgreiches Pilotprojekt ist die wichtigste Methode, den Remap-Pfad abzusichern.

Kriterien für die Auswahl des Pilotarbeitsbereichs

  • Enthält eine Mischung aus Artefakten: Berichte, semantische Modelle, Datenflüsse und Fabric Elemente.
  • Verwendet realistische Datenquellen und Aktualisierungszeitpläne.
  • Verfügt über Berechtigungen auf Arbeitsbereichsebene und im Idealfall über RLS.
  • Wird aktiv verwendet, aber nicht unternehmenskritisch.

Schritt 7: Migrationsausführung

Führen Sie die Migration aus. Unterstützte Elemente werden zuerst skripted; Nicht unterstützte Elemente werden manuell neu erstellt.

Schreiben Sie für große Mandanten Skripts, die die Power BI Admin-API kapseln, um Artefakte gesammelt zu exportieren und in großer Zahl neu zu erstellen.

Erstellen Sie Artefakte in der in What's supported for migration definierten Reihenfolge erneut. Beim Überspringen der Reihenfolge werden Abhängigkeiten unterbrochen.

Schritt 8: Validierung und Tests

Überprüfen Sie, ob der Inhalt erfolgreich migriert wird und sich ordnungsgemäß verhält.

Exportierte Semantikmodelldefinitionen enthalten nicht die zugrunde liegenden Daten. Jedes importierte Semantikmodell benötigt mindestens eine manuelle Aktualisierung im Zielmandanten.

Tip

Erwägen Sie die vorübergehende Skalierung auf eine SKU mit höherer Kapazität während der Überprüfung. Eine große Anzahl gleichzeitiger Aktualisierungen kann andernfalls die Zielkapazität sättigen.

Aktivitäten

  • Überprüfen von Daten: Zeilenanzahl, Schlüsselaggregate, Aktualisierungserfolg.
  • Überprüfen der Sicherheit: RLS-Regeln, Arbeitsbereichszugriff, Freigabebereiche.
  • Leistung validieren: Ladezeiten, Abfragereaktionsfähigkeit, Kapazitätsreserven.

Schritt 9: Umstellung und Benutzerakzeptanz

Verschieben Sie Benutzer zum Zielmandanten und aktualisieren Sie nachgelagerte Anwendungen.

Aktivitäten

  • Gewähren Sie Benutzern Zugriff auf Arbeitsbereiche und Artefakte im Zielmandanten.
  • Aktualisieren Sie eingebettete Berichts-URLs, SharePoint-Links, Power Apps-Verbindungen und Power-Automate-Flows, die auf Power BI-Inhalte verweisen.
  • Deaktivieren Sie die Bearbeitung im Quellmandanten (schreibgeschützte Phase) vor der endgültigen Außerbetriebnahme.
  • Führen Sie kurze Aktivierungssitzungen aus, die die Änderungen und den Ort der Suche nach Inhalten abdecken.

Verwandte Inhalte

  • Last updated on