Power BI tenantmigratiepatronen en -strategieën

Organisaties hebben te maken met verschillende tenantmigratiescenario's in Power BI, op basis van fusies en overnames, bedrijfsactiviteiten, vereisten voor gegevenslocatie of regionale nalevingsbehoeften. Tenantmigraties zijn complexe ondernemingen die zorgvuldige planning, uitgebreide back-upstrategieën en systematische uitvoering vereisen. Dit artikel bevat richtlijnen voor migraties op ondernemingsniveau Power BI tenants, waaronder beslissingskaders om te bepalen of migratie nodig is en gedetailleerde implementatiemethoden voor verschillende migratiepatronen.

Important

Tenantmigraties dragen aanzienlijke risico's met zich mee en vereisen uitgebreide handmatige inspanning. Microsoft biedt geen directe ondersteuning voor het migreren van inhoud tussen tenants of binnen dezelfde tenant tijdens regionale verplaatsingen. Voordat u doorgaat met een migratie, moet u zorgvuldig alternatieven evalueren, zoals multi-geografische capaciteiten die veel scenario's kunnen aanpakken zonder de complexiteit en het risico van volledige tenantmigratie.

Scenario's voor tenantmigratie

Power BI tenantmigratie omvat drie scenario's. Bepaal welke van toepassing is op uw situatie voordat u uw migratie plant.

Scenario Description Typische trigger
Parallelle migratie (tenantoverschrijdend) Twee afzonderlijke Microsoft 365 tenants werken parallel. Artefacten worden afzonderlijk verplaatst van de brontenant naar de doeltenant. Fusies en overnames die twee organisaties samenvoegen tot één tenant.
Tenantsplitsing Eén Power BI tenant is onderverdeeld in twee onafhankelijke tenants. Artefacten, werkruimten en gebruikers van de vertrekkende bedrijfsentiteit worden selectief uitgesneden. Desinvesteringen en spin-offs.
Tenant opnieuw toewijzen (tenantverplaatsing) De Power BI-tenant wordt verwijderd en opnieuw gemaakt in een nieuwe thuisregio binnen dezelfde Microsoft 365 tenant. De Microsoft 365 tenant-id, domein en gebruikersidentiteiten blijven behouden. Zie Move Power BI tussen geografische regio's voor meer informatie. Vereisten voor gegevensresidentie die verplichten de thuisregio van de tenant in te stellen op een specifiek land of specifieke regio.

Parallelle migraties en tenantsplitsingen zijn cross-tenant-bewerkingen. Tenant remap is een regioverplaatsing binnen dezelfde Microsoft 365-tenant.

Note

Zie Uw Power BI-tenant naar een andere regio verplaatsen voor aandachtspunten en beperkingen bij het opnieuw toewijzen van een tenant (regionale verplaatsing) met Microsoft Ondersteuning. Microsoft Ondersteuning hulp is beperkt tot het verwijderen van de vorige tenant en het opnieuw toewijzen van een nieuwe tenant aan de opgegeven regio. Er wordt geen migratieondersteuning geboden. U moet een rehydratatieplan hebben voor zowel gegevens als metagegevens, hetzij via back-up- en herstelscripts, handmatige acties of een recreatie- en herlaadproces. Deze procedure brengt aanzienlijke risico's met zich mee, inclusief potentiële gegevens of verlies van artefacten als back-ups onvolledig zijn of artefacten worden weggelaten. De downtime tijdens het opnieuw toewijzen van tenants kan variëren van drie tot 24 uur, waarbij voor het herstellen van artefacten meer downtime nodig is.

Alternatieven evalueren voordat u migreert

Tenantmigratie omvat aanzienlijke risico's en inspanningen. Verken alternatieve opties voordat u doorgaat. De volgende strategieën kunnen u helpen bij het voorkomen van een tenantmigratie of herlocatie.

Implementatie met meerdere geografische gebieden

Met een multi-geo-implementatie kunt u Power BI en Fabric capaciteit implementeren in een regio van uw keuze, terwijl uw tenant-thuisregio ongewijzigd blijft. De gegevens binnen deze capaciteiten blijven dicht bij uw eindgebruikers en u kunt meerdere capaciteiten hebben in verschillende regio's onder dezelfde tenant.

Het migreren van artefacten naar een capaciteit in een andere regio is eenvoudiger dan het migreren van de tenant zelf. Als u een werkruimte naar een andere regio wilt verplaatsen, moet u de werkruimte opnieuw toewijzen van de ene naar de andere capaciteit. De hertoewijzing is naadloos voor Power BI items.

Important

Fabric-items blijven niet behouden bij het opnieuw toewijzen van werkruimten tussen capaciteiten in verschillende regio's. Verwijder Fabric items voordat de werkruimte opnieuw wordt toegewezen en maak ze later opnieuw, of gebruik Git-integratie om een back-up te maken en Fabric items te herstellen.

Overweeg implementatie met meerdere geografische gebieden voor de volgende vereisten:

  • Gegevenslatentie. Plaats gegevens en rekenkracht dichter bij eindgebruikers door capaciteit in hun regio te implementeren.
  • Gegevenslocatie. Uw gegevens en berekeningen zijn gekoppeld aan uw capaciteitsregio , niet aan uw tenantregio. Een implementatie met meerdere geografische gebieden bewaart gegevens binnen de grenzen van gegevenslocatie voor de meeste workloads.

Overweeg alleen een tenant opnieuw toe te kennen wanneer de vereisten voor gegevenslocatie strikt genoeg zijn dat zelfs tenantmetagegevens (werkruimtedefinities, semantische modelmetagegevens, visuele metagegevens, instellingen, beleid) en Microsoft 365 gebruikersgegevens binnen de grenzen van gegevenslocatie moeten blijven.

Gebruik uw eigen opslagaccount voor Dataflow Gen1

Dataflow Gen1 schrijft de uitvoer weg naar een Azure Data Lake Storage (ADLS) Gen2-account dat zich standaard in de thuisregio van de Power BI-tenant bevindt. Als de opslaglocatie van Dataflow Gen1 uw enige locatie is, configureert u een bring-your-own ADLS Gen2-account in de gewenste regio in plaats van de tenant te verplaatsen.

Aangepaste Azure Relay voor een niet-overeenkomende gatewayregio

Als uw capaciteit wordt geïmplementeerd in een andere regio dan de basisregio van uw tenant, stuurt het standaardeindpunt van de on-premises gegevensgateway verkeer terug naar de thuisregio. Als u gatewayverkeer in uw capaciteitsregio wilt behouden, configureert u een custom Azure relay. Een afwijkende gatewayregio op zichzelf mag geen aanleiding zijn voor een tenantmigratie.

De business case bekijken

Als een tenantmigratie wordt aangestuurd door een bedrijfsbehoefte (bijvoorbeeld factureringsconsolidatie), wegen de inspanningen en het risico af op basis van het resultaat. Een kleine tenant is doorgaans eenvoudig te migreren; bij een grote tenant met veel Fabric-inhoud kan het raadzaam zijn eerst de zakelijke noodzaak opnieuw te beoordelen voordat u doorgaat.

Wat wordt ondersteund voor migratie

De meeste Power BI items ondersteunen het exporteren van definities via de Power BI Admin API of Workspace Scanner-API en kunnen worden gescript. De meeste Fabric items bieden geen ondersteuning voor definitie-export en moeten handmatig opnieuw worden gemaakt.

De volgende tabel bevat een overzicht van het migratiepad voor elk artefacttype.

Bestelling Artifact Migratiepad
1 Gateways Geen migratiepad. Moet opnieuw worden geconfigureerd in de doeltenant door een Power BI-beheerder.
2 Werkruimtes Geen migratiepad. Moet opnieuw worden gemaakt in de doeltenant. Bulksgewijs maken is mogelijk met behulp van de Power BI Admin API.
3 Stofitems Items die Git-integratie ondersteunen, kunnen een back-up krijgen door ze naar Git te committen, ze van de bronwerkruimte te ontkoppelen en ze opnieuw te koppelen aan een nieuwe werkruimte in de doeltenant. Alleen een back-up van de definitie wordt gemaakt; gegevens zijn niet opgenomen. Items die geen ondersteuning bieden voor Git-integratie, moeten handmatig opnieuw worden gemaakt. Voor Lakehouse blijven alleen metagegevens behouden; Delta-tabellen en -schema's worden niet overgedragen.
4 Dataflows Download de definitie-JSON en voer deze opnieuw in de doeltenant in. Scripting is mogelijk met behulp van de Beheer-API.
5 Semantische modellen/gegevenssets Gebruik back-up en herstel naar een ADLS Gen2-opslagaccount, of download de definitie en import opnieuw. Scripting is mogelijk met behulp van de Beheer-API.
6 Rapporten Eigenaren of beheerders downloaden het PBIX-bestand en publiceren opnieuw naar de doeltenant. U kunt ook de JSON-definitie exporteren. Scripting is mogelijk met behulp van de Beheer-API.
7 Dashboards Geen migratiepad. Moet handmatig opnieuw worden gemaakt.
8 Power BI-apps Geen migratiepad. Moet handmatig opnieuw worden gemaakt.
9 Gepagineerde rapporten Eigenaren of beheerders downloaden het RDL-bestand en publiceren naar de doeltenant.

Important

Maak altijd artefacten in deze volgorde opnieuw. Downstream-artefacten zijn afhankelijk van upstream-artefacten, en het niet aanhouden van die volgorde kan tijdens de uitvoering leiden tot kapotte verwijzingen. Als u een Git-synchronisatie uitvoert, worden alle items in de werkruimte gewist die niet in de opslagplaats aanwezig zijn.

Migratiemethodologie

Houd rekening met de volgende referentieactiviteiten. De meeste stappen zijn van toepassing op alle drie de scenario's. Stappen die specifiek zijn voor een scenario, worden in hun koppen beschreven.

Stap 1: Detectie- en inventarisevaluatie

Bouw een volledige inventaris van artefacten en afhankelijkheden en identificeer wat u wel en niet kunt migreren.

activiteiten

  • Voer tenantbrede detectie uit met behulp van een combinatie van:
    • Power BI-beheer-API's
    • Fabric-beheer-API's
    • Activiteitenlogboeken (werkruimten, rapporten, gegevenssets, vernieuwingen)
    • Handmatige documentatie voor items die niet worden weergegeven door API's
  • Opnemen:
    • Werkruimten (type, capaciteit, regio)
    • Rapporten, semantische modellen (met name grote opslagindeling), gegevensstromen
    • Fabric-onderdelen (Lakehouse, Warehouse, Eventhouse, notitieblokken)
    • Gateways, gegevensbronnen, referenties
    • RLS-rollen (Beveiliging op rijniveau), werkruimtemachtigingen, koppelingen voor delen
  • Classificeer elke werkruimte op migratiecomplexiteit (laag, gemiddeld, hoog) op basis van de artefacten die deze bevat en afhankelijkheden.

Outputs

  • Een primaire voorraad spreadsheet.
  • Een classificatie van migratiecomplexiteit voor elke werkruimte.

Stap 2: Detectie van gebruikers en beveiliging

Leg gebruikersidentiteit, licentieverlening en machtigingen vast en wijs deze indien nodig toe tussen tenants.

Bij het opnieuw toewijzen van een tenant blijven gebruikersobject-id’s behouden. Voor een side-by-side migratie of tenantsplitsing hebben gebruikers verschillende object-id's in de doeltenant. Wijs elke brontenant-identiteit toe aan de bijbehorende doeltenant-identiteit. Wijs Power BI licentietoewijzingen (Gratis, Pro, PPU) opnieuw toe. Beveiligingsgroepen repliceren in de nieuwe Microsoft 365-tenant.

activiteiten

Identificeren en vastleggen:

  • Power BI licentietoewijzingen (afkomstig uit Microsoft Graph)
  • Id's van gebruikersobjecten in de brontenant
  • Object-id’s van gebruikers in de doeltenant (alleen naast elkaar of gesplitst)
  • Gebruikersmachtigingen en toegangsniveaus voor werkruimten
  • Huidige instellingen op tenantniveau (handmatig vastleggen via de beheerportal)
  • Huidige governanceconfiguraties (vertrouwelijkheidslabels, goedkeuringsbeleid)

U kunt werkruimte- en artefactmachtigingen extraheren met behulp van de Power BI Admin-API's en de Werkruimtescanner-API.

Stap 3: Communicatie met belanghebbenden en wijzigingsbeheer

Communiceer het migratieplan vroeg om weerstand en ondersteuningsbelasting te verminderen.

Belangrijke groepen belanghebbenden

  • Directiesponsors
  • Werkruimte-eigenaren en rapportauteurs
  • Eindgebruikers
  • IT-, beveiligings- en identiteitsteams

activiteiten

  • Een communicatieplan ontwikkelen met betrekking tot:
    • Overzicht en logica van migratie.
    • Wat is en is niet gemigreerd (bijvoorbeeld persoonlijke werkruimten, niet-actieve werkruimten).
    • Wat verandert (URL's, toegang, verversingsmoment). Downstream-Power Apps- en SharePoint-koppelingen die verwijzen naar Power BI URL's, worden ook beïnvloed.
    • Wat verandert er niet (gegevenssemantiek, visuals, bedrijfslogica).
  • Belangrijke datums communiceren:
    • Bevriezingsperiode (doorgaans ongeveer één week waarin geen wijzigingen worden aangebracht in de brontenant tijdens de definitieve back-up).
    • Verwachte downtime (voor scenario's voor opnieuw toewijzen van tenants).
    • Validatieperioden voor belanghebbenden om hun eigen rapporten in de doeltenant te verifiëren.
    • Overgangsmijlpalen en datums voor buitengebruikstelling van de brontenant (naast-elkaar-scenario's).

Outputs

  • Een presentatiedeck voor belanghebbenden.
  • Veelgestelde vragen over eindgebruikers.

Stap 4: Een aanvraag voor tenant-hertoewijzing verzenden (alleen tenant-hertoewijzing)

Wanneer de migratiedatum is vergrendeld, dient u een ondersteuningsticket in en selecteert u specifiek de optie voor opnieuw toewijzen van de tenant. Een Microsoft-supportmedewerker neemt het verzoek in behandeling.

activiteiten

  • Dien het ondersteuningsticket in.
  • Voltooi de controlelijst voor gereedheid van Microsoft.
  • Ga akkoord met een migratiedatum en -tijdslot, inclusief een back-uptijdslot.
  • Verwijder bestaande capaciteit voordat de tenant opnieuw wordt toegewezen.

Verwachte resultaten

  • Een typische remap duurt ongeveer drie uur, maar vertragingen van maximaal 24 uur zijn mogelijk als er complicaties optreden.
  • Nadat het opnieuw toewijzen is voltooid, heeft de nieuwe tenant dezelfde tenant-id en bevindt deze zich in de aangevraagde regio.

Stap 5: Gereedheid van doeltenant

Een nieuw aangemaakte of opnieuw toegewezen tenant is niet onmiddellijk klaar om inhoud te ontvangen. Configureer deze eerst.

activiteiten

  • Tenantinstellingen voor Power BI configureren:
    • Besturingselementen voor het maken van werkruimten
    • Beleid voor delen en externe toegang
    • Beheer van aangepaste visuele elementen
    • Vertrouwelijkheidslabels en gegevensbescherming
    • Inschakelen van auditlog en monitoring
  • Koop Fabric-capaciteiten met een gelijke of hogere SKU dan de broncapaciteit.
  • Gateways, gatewayclusters en gegevensconnectiviteit configureren en valideren.
  • Voor scenario's voor side-by-side of tenantsplitsing:
    • Maak in de doeltenant een gebruiker aan voor elke gebruiker in de brontenant en registreer de gebruikerkoppeling.
    • Maak gebruikersgroepen opnieuw vanuit de brontenant.
    • Wijs Power BI licenties toe in de doeltenant.
  • Governance afstemmen: vertrouwelijkheidslabels, Microsoft Purview-integratie en goedkeuringsbeleid.

Stap 6: Migratiepilot

Voer een testmigratie uit op een representatieve voorbeeldwerkruimte vóór de productiemigratie.

Voor gelijktijdige migraties blijft de brontenant beschikbaar als terugval voor nieuwe pogingen. Bij het opnieuw toewijzen van tenants kan inhoud waarvan vóór de remap niet correct een back-up is gemaakt, niet worden hersteld. Een succesvol pilotproject is de belangrijkste manier om de risico’s van het remaptraject te beperken.

Selectiecriteria voor testwerkruimten

  • Bevat een combinatie van artefacten: rapporten, semantische modellen, gegevensstromen en Fabric items.
  • Maakt gebruik van realistische gegevensbronnen en vernieuwingsschema's.
  • Heeft machtigingen op het niveau van de werkruimte en bij voorkeur RLS.
  • Wordt actief gebruikt, maar niet bedrijfskritiek.

Stap 7: Migratie-uitvoering

Voer de migratie uit. Ondersteunde items worden eerst gescript; niet-ondersteunde items worden handmatig opnieuw gemaakt.

Schrijf voor grote tenants scripts die de Power BI Admin API verpakken om artefacten bulksgewijs te exporteren en bulksgewijs opnieuw te maken.

Maak artefacten opnieuw in de volgorde die is gedefinieerd in Wat wordt ondersteund voor migratie. Als u de volgorde overslaat, worden afhankelijkheden verbroken.

Stap 8: Validatie en testen

Controleer of de inhoud is gemigreerd en goed werkt.

Geëxporteerde semantische modeldefinities bevatten niet de onderliggende gegevens. Elk geïmporteerd semantisch model moet ten minste één handmatige vernieuwing in de doeltenant hebben.

Tip

Overweeg tijdens de validatie tijdelijk te schalen naar een SKU met een hogere capaciteit. Een groot aantal gelijktijdige vernieuwingen kan anders de doelcapaciteit overbelasten.

activiteiten

  • Gegevens valideren: aantal rijen, sleutelaggregaties, geslaagde vernieuwing.
  • Valideer beveiliging: RLS-regels, toegang tot werkruimten, bereik voor delen.
  • Prestaties valideren: laadtijden van rapporten, reactiesnelheid van query's, capaciteitshoofdruimte.

Stap 9: Gebruikersmigratie en adoptie

Verplaats gebruikers naar de doeltenant en werk downstreamtoepassingen bij.

activiteiten

  • Gebruikers toegang verlenen tot werkruimten en artefacten in de doeltenant.
  • Werk de URL’s van ingesloten rapporten, SharePoint-links, Power Apps-verbindingen en Power Automate-werkstromen bij die verwijzen naar Power BI-inhoud.
  • Schakel bewerken uit in de brontenant (alleen-lezenfase) voordat deze definitief buiten gebruik wordt gesteld.
  • Voer korte activeringssessies uit waarin wordt beschreven wat er is gewijzigd en waar inhoud kan worden gevonden.

Verwante inhoud

  • Last updated on