Power BI mönster och strategier för klientmigrering

Organisationer står inför olika scenarier för klientmigrering i Power BI, som drivs av fusioner och förvärv, företagsförsäljningar, krav på datahemvist eller regionala efterlevnadsbehov. Tenantmigreringar är komplexa projekt som kräver noggrann planering, omfattande strategier för säkerhetskopiering och systematiskt genomförande. Den här artikeln innehåller vägledning för migreringar i företagsskala Power BI klientorganisation, inklusive beslutsramverk som hjälper dig att avgöra om migrering är nödvändig och detaljerade implementeringsmetoder för olika migreringsmönster.

Viktigt!

Klientmigreringar medför betydande risker och kräver omfattande manuella åtgärder. Microsoft ger inte direkt stöd för att migrera innehåll mellan klienter eller inom samma klientorganisation under regionala omlokaliseringar. Innan du fortsätter med någon migrering bör du noggrant utvärdera alternativ som flera geografiska kapaciteter som kan hantera många scenarier utan komplexiteten och risken för fullständig klientmigrering.

Scenarier för klientmigrering

Power BI klientmigrering omfattar tre scenarier. Identifiera vilken som gäller för din situation innan du planerar migreringen.

Scenario Description Typisk utlösare
Migrering sida vid sida (mellan klientorganisationer) Två separata Microsoft 365 klienter fungerar parallellt. Artefakter flyttas från källklientorganisationen till målklientorganisationen individuellt. Sammanslagningar och förvärv som konsoliderar två organisationer till en enda klientorganisation.
Uppdelning av klientorganisation En Power BI-klientorganisation delas upp i två oberoende klientorganisationer. Artefakter, arbetsytor och användare som tillhör den avgående affärsentiteten är selektivt utskurna. Avyttringar och avknoppningar.
Ommappning av tenant (omlokalisering av tenant) Power BI-klientorganisationen tas bort och återskapas i en ny hemregion inom samma Microsoft 365-klientorganisation. Microsoft 365 klientorganisations-ID, domän och användaridentiteter bevaras. Mer information finns i Move Power BI mellan geografiska regioner. Krav på datahemvist som innebär att klientorganisationens hemregion måste vara ett visst land eller en viss region.

Parallella migreringar och tenantuppdelningar är cross-tenant-operationer. Klientommappning är en regionflytt inom samma Microsoft 365 klientorganisation.

Note

Mer information om överväganden och begränsningar för ommappning av klientorganisationer (regional flytt) med Microsoft Support finns i Move your Power BI tenant to a different region. Microsoft Support hjälp är begränsad till att ta bort den tidigare klientorganisationen och mappa om en ny klientorganisation till den angivna regionen. Migreringshjälp tillhandahålls inte. Du måste ha en rehydreringsplan för både data och metadata, oavsett om det gäller skriptbaserad säkerhetskopiering och återställning, manuella åtgärder eller en återskapnings- och inläsningsprocess. Den här proceduren medför betydande risker, inklusive potentiell data- eller artefaktförlust om säkerhetskopior är ofullständiga eller artefakter utelämnas. Stilleståndstid under klientmappning kan variera från tre till 24 timmar, med mer stilleståndstid som krävs för återställning av artefakter.

Utvärdera alternativ innan du migrerar

Klientmigrering innebär betydande risker och arbete. Utforska alternativa alternativ innan du fortsätter. Följande strategier kan hjälpa dig att undvika en klientmigrering eller flytt.

Multi-geo-driftsättning

Med en multi-geo-distribution kan du distribuera Power BI och Fabric kapacitet i valfri region samtidigt som klientorganisationens hemregion hålls oförändrad. Data i dessa kapaciteter ligger nära dina slutanvändare och du kan ha flera kapaciteter i olika regioner under samma klientorganisation.

Det är enklare att migrera artefakter till en kapacitet i en annan region än att migrera själva tenanten. Om du vill flytta en arbetsyta till en annan region, omtilldela arbetsytan från en kapacitet till en annan. Omtilldelningen är sömlös för Power BI objekt.

Viktigt!

Fabric objekten överlever inte omtilldelning av arbetsytor mellan kapaciteter i olika regioner. Ta bort Fabric-objekt innan arbetsytan omtilldelas och återskapa dem efteråt, eller använd Git-integrationen för att säkerhetskopiera och återställa Fabric-objekt.

Överväg multi-geo-distribution för följande krav:

  • Datafördröjning. Placera data och beräkning närmare slutanvändarna genom att distribuera kapacitet i deras region.
  • Datahemvist. Dina data och beräkning är knutna till din kapacitetsregion , inte din klientregion. En distribution i flera geografiska områden ser till att data lagras inom gränserna för datahemvist för de flesta arbetsbelastningar.

Överväg endast en klientommappning när kraven på datahemvist är tillräckligt strikta för att även klientmetadata (definitioner för arbetsytor, semantiska modellmetadata, visuella metadata, inställningar, principer) och Microsoft 365 användarinformation måste ligga inom datahemvistsgränser.

Ta med ditt eget lagringskonto för Dataflow Gen1

Dataflow Gen1 skriver utdata till ett Azure Data Lake Storage (ADLS) Gen2-konto som som standard finns i Power BI klientorganisationens hemregion. Om Dataflow Gen1-lagringsplatsen är ditt enda residency-problem konfigurerar du ett eget ADLS Gen2-konto i önskad region i stället för att flytta klientorganisationen.

Anpassat Azure relä för gatewayregionens matchningsfel

Om din kapacitet har distribuerats i en annan region än klientorganisationens hemregion, dirigerar den förvalda slutpunkten för on-premises-datagatewayen trafiken tillbaka till hemregionen. Om du vill behålla gatewaytrafiken i kapacitetsregionen konfigurerar du en anpassad Azure relay. Enbart en bristande överensstämmelse mellan gatewayregioner bör inte i sig utlösa en tenantmigrering.

Granska affärsfallet

Om en klientmigrering drivs av ett affärsbehov (till exempel faktureringskonsolidering) väger du ansträngningen och risken mot resultatet. Det kan vara enkelt att migrera en liten tenantorganisation; en stor tenantorganisation med omfattande Fabric-innehåll kan motivera att man omprövar verksamhetsbehovet innan man går vidare.

Vad stöds för migrering

De flesta Power BI objekt stöder definitionsexport via Power BI Admin API eller Workspace Scanner API och kan skriptas. De flesta Fabric objekt stöder inte definitionsexport och måste återskapas manuellt.

Följande tabell sammanfattar migreringsvägen för varje artefakttyp.

Beställning Artifact Migreringsväg
1 Gateways Det finns ingen migreringsväg. Måste konfigureras om i målklientorganisationen av en Power BI administratör.
2 Arbetsytor Ingen migreringsväg. Måste återskapas i måltenanten. Massskapande är möjligt med hjälp av api:et Power BI admin.
3 Textilprodukter Objekt som stöder Git-integrering kan säkerhetskopieras genom att checka in på Git, ta bort länkning från källarbetsytan och länka om till en ny arbetsyta i målklientorganisationen. Endast definitionen säkerhetskopieras. data ingår inte. Objekt som inte stöder Git-integrering måste återskapas manuellt. För Lakehouse bevaras endast metadata. deltatabeller och scheman överförs inte.
4 Dataflows Ladda ned definitions-JSON-filen och återimportera den till målklientorganisationen. Skript är möjligt med hjälp av administratörs-API:et.
5 Semantiska modeller/datauppsättningar Använd säkerhetskopiering och återställning till ett ADLS Gen2-lagringskonto eller ladda ned definitionen och importera igen. Skript är möjligt med hjälp av administratörs-API:et.
6 Rapporter Ägare eller administratörer laddar ned .pbix-filen och publicerar den på nytt i måltenant. Du kan också exportera JSON-definitionen. Skript är möjligt med hjälp av administratörs-API:et.
7 Dashboards Ingen migreringsväg. Måste återskapas manuellt.
8 Power BI-appar Ingen migreringsväg. Måste återskapas manuellt.
9 Rapporter med pagination Ägare eller administratörer laddar ned RDL-filen och publicerar den till målklientorganisationen.

Viktigt!

Återskapa alltid artefakter i den här ordningen. Artefakter i senare led är beroende av artefakter i tidigare led, och om ordningen inte följs kan det leda till felaktiga referenser under körning. Att utföra en Git-synkronisering tar bort alla objekt i arbetsytan som inte finns i repot.

Migreringsmetodik

Överväg följande referensaktiviteter. De flesta steg gäller för alla tre scenarierna. Steg som är specifika för ett scenario beskrivs i deras rubriker.

Steg 1: Identifiering och inventeringsutvärdering

Skapa en fullständig inventering av artefakter och beroenden och identifiera vad du kan, inte kan eller inte bör migrera.

Aktiviteter

  • Kör identifiering i hela klientorganisationen med hjälp av en kombination av:
    • Power BI admin-API:er
    • Fabric administratörs-API:er
    • Aktivitetsloggar (arbetsytor, rapporter, datauppsättningar, uppdateringar)
    • Manuell dokumentation för objekt som inte exponeras av API:er
  • Fånga:
    • Arbetsytor (typ, kapacitet, region)
    • Rapporter, semantiska modeller (särskilt stort lagringsformat), dataflöden
    • Fabric-objekt (Lakehouse, Warehouse, Eventhouse, anteckningsböcker)
    • Gatewayer, datakällor, autentiseringsuppgifter
    • Säkerhetsroller på radnivå (RLS), arbetsytebehörigheter, delningslänkar
  • Klassificera varje arbetsyta efter migreringskomplexitet (låg, medel, hög) baserat på artefakterna den innehåller och beroenden.

Outputs

  • Ett primärt inventeringskalkylblad.
  • En klassificering av migreringskomplexitet för varje arbetsyta.

Steg 2: Användar- och säkerhetsidentifiering

Samla in användaridentitet, licensiering och behörigheter och mappa dem mellan klienter när det behövs.

I en klientommappning bevaras användarobjekt-ID:t. Vid en parallellmigrering eller delning av en klientorganisation har användarna olika objekt-ID:n i målklientorganisationen. Mappa varje källklientidentitet till dess målklientidentitet. Tilldela om Power BI licenstilldelningar (kostnadsfri, Pro, PPU). Återskapa säkerhetsgrupper i den nya Microsoft 365-klientorganisationen.

Aktiviteter

Identifiera och registrera:

  • Power BI licenstilldelningar (hämtas från Microsoft Graph)
  • Användarobjekt-ID:n i källklientorganisationen
  • Användarobjekt-ID:er i målklientorganisationen (endast sida vid sida eller endast delning)
  • Användarbehörigheter och åtkomstnivåer för arbetsytor
  • Aktuella inställningar på klientnivå (avbilda manuellt via administratörsportalen)
  • Aktuella styrningskonfigurationer (känslighetsetiketter, godkännandeprinciper)

Du kan extrahera arbetsyte- och artefaktbehörigheter med hjälp av API:erna Power BI Admin och api:et Workspace Scanner.

Steg 3: Kommunikation med intressenter och förändringshantering

Kommunicera migreringsplanen tidigt för att minska motståndet och stödbelastningen.

Viktiga intressentgrupper

  • Chefssponsorer
  • Ägare av arbetsytor och rapportförfattare
  • Slutanvändare
  • IT-, säkerhets- och identitetsteam

Aktiviteter

  • Utveckla en kommunikationsplan som omfattar:
    • Migreringsöversikt och logik.
    • Vad som migreras och inte migreras (till exempel personliga arbetsytor, inaktiva arbetsytor).
    • Vilka ändringar (URL:er, åtkomst, uppdateringstidpunkt). Underordnade Power Apps och SharePoint länkar som refererar till Power BI URL:er påverkas också.
    • Vad ändras inte (datasemantik, visuella objekt, affärslogik).
  • Kommunicera nyckeldatum:
    • Lås fönster (vanligtvis ungefär en vecka utan ändringar i källklientorganisationen under den slutliga säkerhetskopieringen).
    • Förväntat driftstopp (vid scenarier för ommappning av tenant).
    • Valideringsperioder för intressenter för att verifiera sina egna rapporter i målklientorganisationen.
    • Milstolpar för övergång och datum för avveckling för källklientorganisationen (parallellscenarier).

Outputs

  • Ett informationsdäck för intressenter.
  • Vanliga frågor och svar om slutanvändare.

Steg 4: Skicka in en begäran om ommappning av klientorganisation (endast ommappning av klientorganisation)

När migreringsdatumet är låst, skicka in ett supportärende och välj sedan alternativet tenant-ommappning. En Microsoft supporttekniker tar begäran.

Aktiviteter

  • Skicka supportärendet.
  • Slutför beredskapschecklistan som tillhandahålls av Microsoft.
  • Kom överens om ett datum- och tidsintervall för migrering, inklusive en tidslucka för säkerhetskopiering.
  • Ta bort befintlig kapacitet innan klientorganisationens ommappning sker.

Förväntade utfall

  • En typisk omkarta tar ungefär tre timmar, men fördröjningar på upp till 24 timmar är möjliga om komplikationer uppstår.
  • När ommappningen är klar har den nya klientorganisationen samma klientorganisations-ID och finns i den begärda regionen.

Steg 5: Målklientens beredskap

En nyligen skapad eller nyligen ommappad klientorganisation är inte omedelbart redo att ta emot innehåll. Konfigurera det först.

Aktiviteter

  • Konfigurera Power BI-klientorganisationens inställningar:
    • Kontroller för att skapa arbetsyta
    • Principer för delning och extern åtkomst
    • Styrning av anpassade visuella objekt
    • Känslighetsetiketter och informationsskydd
    • Aktivering av granskningsloggning och övervakning
  • Köp Fabric-kapaciteter med samma eller högre SKU än källan.
  • Konfigurera och verifiera gatewayer, gatewaykluster och dataanslutning.
  • För scenarier med uppdelning sida vid sida eller klientorganisation:
    • Skapa en användare i målklientorganisationen för varje användare i källklientorganisationen och registrera användarmappningen.
    • Återskapa användargrupper från källklientorganisationen.
    • Tilldela Power BI-licenser i målklientorganisationen.
  • Justera styrning: känslighetsetiketter, Microsoft Purview integrering och godkännandeprinciper.

Steg 6: Migreringspilot

Kör en testmigrering på en representativ exempelarbetsyta före produktionsmigreringen.

Vid migreringar parallellt förblir källklientorganisationen tillgänglig som reservalternativ vid nya försök. Vid tenant-ommappning kan innehåll som inte säkerhetskopierades korrekt före ommappningen inte återställas. Ett framgångsrikt pilotprojekt är det främsta sättet att minska riskerna med vägen för ommappning.

Urvalskriterier för pilotarbetsyta

  • Innehåller en blandning av artefakter: rapporter, semantiska modeller, dataflöden och Fabric objekt.
  • Använder realistiska datakällor och uppdateringsscheman.
  • Har behörigheter på arbetsytenivå och helst även RLS.
  • Används aktivt men inte verksamhetskritiskt.

Steg 7: Genomföra migreringen

Kör migreringen. Objekt som stöds skriptas först. objekt som inte stöds återskapas manuellt.

För stora klienter skriver du skript som omsluter Power BI admin-API:et för massexport och massregenerering av artefakter.

Återskapa artefakter i den ordning som definieras i Vad som stöds för migrering. Att hoppa över ordningen bryter beroenden.

Steg 8: Validering och testning

Kontrollera att innehållet har migrerats och fungerar korrekt.

Exporterade semantiska modelldefinitioner innehåller inte underliggande data. Varje importerad semantisk modell behöver minst en manuell uppdatering i målklientorganisationen.

Tip

Överväg att tillfälligt skala till en SKU med högre kapacitet under valideringen. Ett stort antal samtidiga uppdateringar kan annars mätta målkapaciteten.

Aktiviteter

  • Verifiera data: radantal, nyckelaggregeringar, uppdateringsframgång.
  • Verifiera säkerhet: RLS-regler, åtkomst till arbetsytor, delningsomfång.
  • Verifiera prestanda: rapportinläsningstider, svarstider för frågor, kapacitetsutrymme.

Steg 9: Användarövergång och införande

Flytta användare till målklientorganisationen och uppdatera underordnade program.

Aktiviteter

  • Ge användare åtkomst till arbetsytor och artefakter i målklientorganisationen.
  • Uppdatera inbäddade rapport-URL:er, SharePoint länkar, Power Apps anslutningar och Power Automate flöden som refererar till Power BI innehåll.
  • Inaktivera redigering i källklienten (skrivskyddsläge) före den slutliga avvecklingen.
  • Kör korta aktiveringssessioner som täcker vad som har ändrats och var du hittar innehåll.

Relaterat innehåll

  • Last updated on