Power BI-lejermigreringsmønstre og strategier

Organisationer står over for forskellige lejermigreringsscenarier i Power BI, drevet af fusioner og opkøb, virksomhedsfrasalg, krav om dataophold eller regionale compliance-behov. Lejermigrationer er komplekse opgaver, der kræver omhyggelig planlægning, omfattende backup-strategier og systematisk eksekvering. Denne artikel giver vejledning til enterprise-skala Power BI-lejermigreringer, herunder beslutningsrammer for at afgøre, om migrering er nødvendig, samt detaljerede implementeringsmetoder for forskellige migrationsmønstre.

Vigtigt!

Lejermigrationer indebærer betydelig risiko og kræver omfattende manuel indsats. Microsoft tilbyder ikke direkte support til at migrere indhold mellem lejere eller inden for samme lejer under regionale flytninger. Før du går videre med nogen migration, bør du nøje vurdere alternativer som multi-geografiske kapaciteter, der kan håndtere mange scenarier uden kompleksiteten og risikoen ved fuld lejermigration.

Lejermigrationsscenarier

Power BI-lejermigrering dækker tre scenarier. Identificer hvilken der passer til din situation, før du planlægger din migration.

Scenarie Beskrivelse Typisk udløser
Side-om-side (kryds-lejer) migration To separate Microsoft 365-lejere opererer parallelt. Artefakter flyttes individuelt fra kildelejeren til mållejeren. Fusioner og opkøb, der konsoliderer to organisationer til én lejer.
Lejerdeling En enkelt Power BI-lejer er opdelt i to uafhængige lejere. Artefakter, arbejdsområder og brugere tilhørende den afgående forretningsenhed udskæres selektivt. Afsalg og spin-offs.
Lejeromlægning (lejereflytning) Power BI-lejeren slettes og genoprettes i en ny hjemmeregion inden for samme Microsoft 365-lejer. Microsoft 365 lejer-ID, domæne og brugeridentiteter bevares. For mere information, se Flyt Power BI mellem geografiske områder. Data-bopælskrav, der tvinger lejerens hjemregion til et bestemt land/region.

Side-om-side migreringer og lejeropdelinger er tværlejeroperationer . Lejeromlægning er en regionsflytning inden for samme Microsoft 365 lejer.

Bemærkning

For overvejelser og begrænsninger ved lejeremapping (regional flytning) med Microsoft Support, se Flyt din Power BI lejer til en anden region. Microsoft Support-assistance er begrænset til at slette den tidligere lejer og gentilknytte en ny lejer til den angivne region; migrationshjælp tilbydes ikke. Du skal have en rehydreringsplan for både data og metadata, hvad enten det er gennem scriptet backup og genoprettelse, manuelle handlinger eller en rekreations- og genindlæsningsproces. Denne procedure indebærer betydelig risiko, herunder potentielt tab af data eller artefakter, hvis backups er ufuldstændige eller artefakter udelades. Nedetid under lejeremapping kan variere fra tre til 24 timer, hvor der kræves mere nedetid for at gendanne artefakter.

Vurder alternativer, før du migrerer

Lejermigration indebærer betydelig risiko og indsats. Undersøg alternative muligheder, før du fortsætter. Følgende strategier kan hjælpe dig med at undgå en lejermigration eller flytning.

Multi-geo udrulning

En multi-geo deployment lader dig implementere Power BI og Fabric kapacitet i et område efter eget valg, samtidig med at din lejers hjemmeregion forbliver uændret. Dataene inden for disse kapaciteter forbliver tæt på dine slutbrugere, og du kan have flere kapaciteter i forskellige regioner under samme lejer.

At migrere artefakter til en kapacitet i en anden region er enklere end at migrere selve lejeren. For at flytte et arbejdsområde til et andet område, skal du omfordele arbejdsområdet fra én kapacitet til en anden. Omfordelingen er problemfri for Power BI-elementer.

Vigtigt!

Fabric-produkter overlever ikke omplacering af arbejdspladser på tværs af kapaciteter i forskellige regioner. Slet Fabric-elementer før arbejdsområde-omfordelingen og genskab dem bagefter, eller brug Git-integration til at tage backup og gendanne Fabric-elementer.

Overvej multi-geo deployment for følgende krav:

  • Datalatens. Placer data og compute tættere på slutbrugerne ved at deployere kapacitet i deres region.
  • Dataophold. Dine data og compute er knyttet til din kapacitetsregion , ikke din lejerregion. En multi-geo implementering holder data inden for dataresidensens grænser for de fleste arbejdsbelastninger.

Overvej kun en lejeremapping, når kravene til dataophold er så strenge, at selv lejermetadata (arbejdsområdedefinitioner, semantiske modelmetadata, visuelle metadata, indstillinger, politikker) og Microsoft 365-brugerinformation skal forblive inden for dataresidensens grænser.

Medbring din egen lagringskonto til Dataflow Gen1

Dataflow Gen1 skriver sit output til en Azure Data Lake Storage (ADLS) Gen2-konto, som som standard ligger i Power BI tenants hjemmeregion. Hvis Dataflow Gen1 lagringsplacering er din eneste bopælsbekymring, så opret en bring-your-own ADLS Gen2-konto i den ønskede region i stedet for at flytte lejeren.

Custom Azure relay for gateway region mismatch

Hvis din kapacitet er deployeret i en anden region end din lejers hjemregion, dirigerer den standard on-premises datagateway-endpoint trafikken tilbage til hjemmeregionen. For at holde gateway-trafikken i din kapacitetsregion, konfigurere en custom Azure relæ. En gateway-region-mismatch alene burde ikke udløse en lejermigrering.

Gennemgå forretningscasen

Hvis en lejermigration drives af et forretningsbehov (for eksempel faktureringskonsolidering), bør du veje indsatsen og risikoen op imod resultatet. En lille lejer kan være nem at flytte; en stor lejer med betydeligt Fabric-indhold kan have brug for at genoverveje forretningsbehovet, før man går videre.

Hvad understøttes for migration

De fleste Power BI-elementer understøtter definitionseksport via Power BI Admin API eller Workspace Scanner API og kan scriptes. De fleste Fabric-elementer understøtter ikke definitionseksport og skal manuelt genskabes.

Følgende tabel opsummerer migrationsstien for hver artefakttype.

Sortér Artefakt Overførselssti
1 Gateways Ingen migrationsvej. Skal omkonfigureres i mållejeren af en Power BI-administrator.
2 Arbejdsområder Ingen migrationsvej. Det skal genskabes i mållejeren. Masseoprettelse er mulig ved hjælp af Power BI Admin API'en.
3 Stofelementer Elementer, der understøtter Git-integration , kan sikkerhedskopieres ved at committe til Git, afkoble fra kildearbejdsområdet og genlinke til et nyt arbejdsområde i mållejeren. Kun definitionen understøttes; Data er ikke inkluderet. Elementer, der ikke understøtter Git-integration, skal genskabes manuelt. For Lakehouse bevares kun metadata; delta-tabeller og skemaer overføres ikke.
4 Dataflows Download definitions-JSON og importer den til mållejeren. Scripting er muligt via Admin API'en.
5 Semantiske modeller / datasæt Brug backup og gendanne til en ADLS Gen2-lagringskonto, eller download definitionen og genimporter. Scripting er muligt via Admin API'en.
6 Rapporter Ejere eller administratorer downloader .pbix og genudgiver til mållejeren. Alternativt kan du eksportere JSON-definitionen. Scripting er muligt via Admin API'en.
7 Dashboards Ingen migrationsvej. Skal genskabes manuelt.
8 Power BI-apps Ingen migrationsvej. Skal genskabes manuelt.
9 Sideinddelte rapporter Ejere eller administratorer downloader RDL-filen og udgiver den til den målrettede lejer.

Vigtigt!

Genskab altid artefakter i denne rækkefølge. Nedstrøms artefakter afhænger af opstrøms artefakter, og at springe rækkefølgen over kan føre til ødelagte referencer under udførelsen. At udføre en Git-synkronisering sletter alle elementer i arbejdsområdet, som ikke findes i repoen.

Migrationsmetodologi

Overvej følgende referenceaktiviteter. De fleste trin gælder for alle tre scenarier. Trin, der er specifikke for et scenarie, nævnes i deres overskrifter.

Trin 1: Opdagelse og lagervurdering

Byg et komplet inventar over artefakter og afhængigheder, og identificer, hvad du kan, ikke kan eller ikke bør migrere.

Aktiviteter

  • Kør lejerens opdagelse på tværs af lejere ved at bruge en kombination af:
    • Power BI Admin API'er
    • Fabric Admin API'er
    • Aktivitetslogfiler (arbejdsområder, rapporter, datasæt, opdateringer)
    • Manuel dokumentation for elementer, der ikke er eksponeret af API'er
  • Fangst:
    • Arbejdsområder (type, kapacitet, region)
    • Rapporter, semantiske modeller (især store lagringsformater), dataflows
    • Fabric-genstande (Lakehouse, Warehouse, Eventhouse, notesbøger)
    • Gateways, datakilder, legitimationsoplysninger
    • Række-niveau sikkerhedsroller (RLS), arbejdsområde-tilladelser, delingslinks
  • Klassificer hvert arbejdsområde efter migrationskompleksitet (lav, middel, høj) baseret på de artefakter, det indeholder og afhængigheder.

Udgange

  • Et primært lagerregneark.
  • En migreringskompleksitetsklassifikation for hvert arbejdsområde.

Trin 2: Bruger- og sikkerhedsopdagelse

Indsaml brugeridentitet, licenser og tilladelser, og kortlæg dem mellem lejere, når det er nødvendigt.

Ved en tenant-remapping bevares brugerobjekt-ID'er. Ved en side-om-side migration eller lejeropdeling har brugerne forskellige objekt-ID'er i mållejeren. Tilknyt hver kilde-lejer-identitet til dens mål-lejer-identitet. Tildel Power BI-licenser (gratis, Pro, PPU). Spejl sikkerhedsgrupper i den nye Microsoft 365-lejer.

Aktiviteter

Identificer og registrer:

  • Power BI licensoverdragelser (kilde fra Microsoft Graph)
  • Brugerobjekt-ID'er i kildelejeren
  • Brugerobjekt-ID'er i mållejer (side om side eller kun splittet)
  • Brugerrettigheder og adgangsniveauer til arbejdsområder
  • Nuværende lejerindstillinger (optager manuelt via admin-portalen)
  • Nuværende styringskonfigurationer (følsomhedsetiketter, godkendelsespolitikker)

Du kan udtrække arbejdsområde- og artefaktrettigheder ved at bruge Power BI Admin API'erne og Workspace Scanner API.

Trin 3: Stakeholderkommunikation og forandringsledelse

Kommunikér migrationsplanen tidligt for at reducere modstand og støttebelastning.

Nøgleinteressenter

  • Administrerende sponsorer
  • Workspace-ejere og rapportforfattere
  • Slutbrugere
  • IT-, sikkerheds- og identitetsteams

Aktiviteter

  • Udvikl en kommunikationsplan, der dækker:
    • Migrationsoversigt og begrundelse.
    • Hvad der bliver og ikke bliver migreret (for eksempel personlige arbejdsområder, inaktive arbejdsområder).
    • Hvad der ændrer sig (URL'er, adgang, opdateringstidspunkt). Downstream Power Apps og SharePoint-links, der refererer til Power BI-URL'er, påvirkes også.
    • Hvad ændrer sig ikke (datasemantik, visuals, forretningslogik).
  • Kommunikér nøgledatoer:
    • Frysvinduer (typisk omkring en uge uden ændringer i kildelejen under den endelige backup).
    • Forventet nedetid (for lejeremap-scenarier).
    • Valideringsperioder for interessenter til at verificere deres egne rapporter i mållejeren.
    • Milepæle i cutover og nedlukningsdatoer for kildelejeren (side-om-side scenarier).

Udgange

  • En briefing-præsentation for interessenter.
  • En FAQ for slutbrugere.

Trin 4: Indsend en anmodning om lejeremapping (kun lejeremapping)

Når migreringsdatoen er låst, indsend en supportsag og vælg specifikt muligheden for at omlægge lejeremappen. En Microsoft-supportingeniør tager imod anmodningen.

Aktiviteter

  • Indsend supportticketen.
  • Udfyld beredskabstjeklisten, som Microsoft har stillet til rådighed.
  • Aftal en migrationsdato og et tidsrum, inklusive et backup-tidspunkt.
  • Slet eksisterende kapacitet, før lejeremapping finder sted.

Forventede resultater

  • En typisk omkortlægning tager omkring tre timer, men forsinkelser på op til 24 timer er mulige, hvis komplikationer opstår.
  • Efter remapping er fuldført, har den nye lejer samme lejer-ID og er placeret i den anmodede region.

Trin 5: Mål lejerparathed

En nyoprettet eller nyomkortlagt lejer er ikke straks klar til at modtage indhold. Konfigurér det først.

Aktiviteter

  • Konfigurer Power BI-lejerindstillinger:
    • Kontroller til oprettelse af arbejdsområder
    • Delings- og eksterne adgangspolitikker
    • Styring af brugerdefinerede visuelle elementer
    • Følsomhedsetiketter og informationsbeskyttelse
    • Auditlog og overvågningsaktivering
  • Køb Fabric-kapaciteter med samme eller højere SKU end kilden.
  • Konfigurer og valider gateways, gateway-klynger og dataforbindelser.
  • For side-om-side eller lejeropdelingsscenarier:
    • Opret en bruger i mållejeren for hver bruger i kildelejeren, og registrer brugermappingen.
    • Genskab brugergrupper fra kildelejeren.
    • Tildel Power BI-licenser i mållejeren.
  • Juster styring: følsomhedsetiketter, integration af Microsoft Purview og godkendelsespolitikker.

Trin 6: Migrationspilot

Kør en testmigrering på et repræsentativt prøvearbejdsområde før produktionsmigreringen.

For side-by-side migreringer forbliver kildelejeren tilgængelig som en fallback for genforsøg. For tenant remap er indhold, der ikke blev sikkerhedskopieret korrekt før remappen, ikke genopretteligt. En succesfuld pilot er den vigtigste måde at reducere risikoen på omkortningsvejen.

Kriterier for udvælgelse af pilotarbejdspladser

  • Indeholder en blanding af artefakter: rapporter, semantiske modeller, dataflows og Fabric-elementer.
  • Bruger realistiske datakilder og opdateringsplaner.
  • Har tilladelser på arbejdsområdeniveau og ideelt set RLS.
  • Er aktivt brugt, men ikke missionkritisk.

Trin 7: Migreringsudførelse

Udfør migrationen. Understøttede elementer scriptes først; Ikke-understøttede elementer genskabes manuelt.

For store lejere, skriv scripts, der pakker Power BI Admin API'en ind for at masseeksportere og massegenskabe artefakter.

Genskab artefakter i den rækkefølge, der er defineret i Hvad understøttes for migration. At springe ordenen over bryder afhængigheder.

Trin 8: Validering og test

Valider, at indholdet er migreret korrekt og opfører sig korrekt.

Eksporterede semantiske modeldefinitioner inkluderer ikke de underliggende data. Hver importeret semantisk model kræver mindst én manuel opdatering i mållejeren.

Tip

Overvej midlertidigt at skalere til en SKU med højere kapacitet under valideringen. Et stort antal samtidige opdateringer kan ellers mætte målkapaciteten.

Aktiviteter

  • Valider data: rækketælling, nøgleaggregater, opdateringssucces.
  • Valider sikkerhed: RLS-regler, adgang til arbejdsområder, deling af scopes.
  • Valider ydeevne: rapportér indlæsningstider, forespørgselsrespons, kapacitetskapacitet.

Trin 9: Brugerskift og adoption

Flyt brugere til den ønskede lejer og opdater downstream-applikationer.

Aktiviteter

  • Giv brugerne adgang til arbejdsområder og artefakter i mållejeren.
  • Opdater indlejrede rapport-URL'er, SharePoint-links, Power Apps-forbindelser og Power Automate-flows, der refererer til Power BI-indhold.
  • Deaktiver redigering i kildelejeren (read-only-fasen) før endelig afvikling.
  • Kør korte aktiveringssessioner, der dækker, hvad der er ændret, og hvor man kan finde indhold.

Relateret indhold

  • Last updated on