Power BI-leietakermigrasjonsmønstre og strategier

Organisasjoner står overfor ulike leietakermigrasjonsscenarier i Power BI, drevet av fusjoner og oppkjøp, selskapsavsalg, krav til dataresidens eller regionale krav til etterlevelse. Leietakermigreringer er komplekse oppgaver som krever nøye planlegging, omfattende sikkerhetskopieringsstrategier og systematisk gjennomføring. Denne artikkelen gir veiledning for bedriftsskala Power BI-leietakermigreringer, inkludert beslutningsrammeverk for å avgjøre om migrering er nødvendig, samt detaljerte implementeringsmetoder for ulike migrasjonsmønstre.

Important

Leietakermigrasjoner innebærer betydelig risiko og krever omfattende manuelt arbeid. Microsoft tilbyr ikke direkte støtte for å migrere innhold mellom leietakere eller innenfor samme leietaker under regionale flyttinger. Før du går videre med noen migrering, bør du nøye vurdere alternativer som multi-geografiske kapasiteter som kan håndtere mange scenarier uten kompleksiteten og risikoen ved full leietakermigrering.

Leietakermigrasjonsscenarier

Power BI-leietakermigrasjon dekker tre scenarier. Identifiser hvilken som gjelder for din situasjon før du planlegger migrasjonen.

Scenario Beskrivelse Typisk utløser
Side-ved-side (kryss-leietaker) migrering To separate Microsoft 365-leietakere opererer parallelt. Artefakter flyttes individuelt fra kildeleietakeren til målleietakeren. Fusjoner og oppkjøp som konsoliderer to organisasjoner til én leietaker.
Leietakerdeling En enkelt Power BI-leietaker er delt opp i to uavhengige leietakere. Artefakter, arbeidsområder og brukere som tilhører den avtroppende virksomheten blir selektivt utskåret. Avviklinger og spin-offs.
Leietakerkartlegging (leietakerflytting) Power BI-leietakeren slettes og opprettes på nytt i en ny hjemmeregion innenfor samme Microsoft 365-tenant. Microsoft 365-leietaker-ID, domene og brukeridentiteter bevares. For mer informasjon, se Flytt Power BI mellom geografiske områder. Databostedskrav som tvinger leietakerens hjemregion til et spesifikt land/region.

Side-ved-side migreringer og leietakerdelinger er kryss-leietakeroperasjoner . Leietakerkartlegging er en region-relokasjon innenfor samme Microsoft 365 leietaker.

Note

For hensyn og begrensninger knyttet til leietakerommapping (regional relocation) med Microsoft Kundestøtte, se Flytt din Power BI leietaker til en annen region. Microsoft Kundestøtte-hjelp er begrenset til å slette forrige leietaker og remappe en ny leietaker til den angitte regionen; migreringshjelp tilbys ikke. Du må ha en rehydreringsplan for både data og metadata, enten gjennom skriptet sikkerhetskopiering og gjenoppretting, manuelle handlinger eller en rekreasjons- og lasteprosess. Denne prosedyren innebærer betydelig risiko, inkludert potensiell tap av data eller artefakter hvis sikkerhetskopier er ufullstendige eller artefakter utelates. Nedetid under leietaker-ommapping kan variere fra tre til 24 timer, med mer nedetid nødvendig for gjenoppretting av artefakter.

Vurder alternativer før du migrerer

Leietakermigrasjon innebærer betydelig risiko og innsats. Utforsk alternative alternativer før du går videre. Følgende strategier kan hjelpe deg med å unngå leietakermigrasjon eller flytting.

Multi-geo utplassering

En multi-geo deployment lar deg distribuere Power BI og Fabric kapasitet i en region du ønsker, samtidig som leietakerens hjemmeregion forblir uendret. Dataene innenfor disse kapasitetene holder seg nær sluttbrukerne dine, og du kan ha flere kapasiteter i forskjellige regioner under samme leietaker.

Å migrere artefakter til en kapasitet i en annen region er enklere enn å migrere leietakeren selv. For å flytte et arbeidsområde til et annet område, tilordne arbeidsområdet fra én kapasitet til en annen. Omfordelingen er sømløs for Power BI-elementer.

Important

Fabric-produkter tåler ikke omfordeling av arbeidsplasser på tvers av kapasiteter i ulike regioner. Slett Fabric-elementer før arbeidsområdets omfordeling og lag dem på nytt etterpå, eller bruk Git-integrasjon for å sikkerhetskopiere og gjenopprette Fabric-elementer.

Vurder multigeo-utrulling for følgende krav:

  • Datalatens. Plasser data og beregning nærmere sluttbrukerne ved å deployere kapasitet i deres region.
  • Dataopphold. Data og datakraft er knyttet til kapasitetsregionen din, ikke leietakerregionen. En multi-geo distribusjon holder data innenfor dataresidensgrensene for de fleste arbeidsbelastninger.

Vurder kun en leietakerommapping når kravene til dataresidens er strenge nok til at selv leietakermetadata (arbeidsområdedefinisjoner, metadata for semantiske modeller, visuell metadata, innstillinger, policyer) og Microsoft 365-brukerinformasjon må forbli innenfor dataresidensgrensene.

Ta med din egen lagringskonto for Dataflow Gen1

Dataflow Gen1 skriver sitt output til en Azure Data Lake Storage (ADLS) Gen2-konto som som standard ligger i Power BI leietakers hjemmeregion. Hvis Dataflow Gen1-lagringsplassering er din eneste residensbekymring, kan du konfigurere en bring-your-own ADLS Gen2-konto i ønsket region i stedet for å flytte leietakeren.

Custom Azure relay for gateway region mismatch

Hvis kapasiteten din er distribuert i en annen region enn leietakerens hjemregion, ruter standard lokal datagateway-endepunkt trafikken tilbake til hjemmeregionen. For å holde gateway-trafikken i kapasitetsområdet ditt, konfigurere en custom Azure relé. En gateway-regionmismatch alene bør ikke utløse en leietakermigrering.

Gå gjennom forretningscasen

Hvis en leietakermigrering drives av et forretningsbehov (for eksempel faktureringskonsolidering), bør du veie innsatsen og risikoen opp mot utfallet. En liten leietaker kan være enkel å flytte; en stor leietaker med betydelig Fabric-innhold kan være verdt å revurdere forretningsbehovet før man går videre.

Hva støttes for migrasjon

De fleste Power BI elementer støtter definisjonseksport via Power BI Admin API eller Workspace Scanner API og kan skriptes. De fleste Fabric-elementer støtter ikke definisjonseksport og må gjenskapes manuelt.

Tabellen nedenfor oppsummerer migrasjonsstien for hver artefakttype.

Bestilling Kulturgjenstand Overføringsbane
1 Gatewayer Ingen migrasjonsvei. Må konfigureres på nytt i målleietakeren av en Power BI-administrator.
2 Workspaces Ingen migrasjonsvei. Må gjenskapes i mål-leietakeren. Masseopprettelse er mulig ved bruk av Power BI Admin API.
3 Stoffelementer Elementer som støtter Git-integrasjon kan sikkerhetskopieres ved å committe til Git, koble fra kildearbeidsområdet og koble til et nytt arbeidsområde i mål-leietakeren. Bare definisjonen er støttet; Data er ikke inkludert. Elementer som ikke støtter Git-integrasjon må gjenskapes manuelt. For Lakehouse bevares kun metadata; delta-tabeller og skjemaer overføres ikke.
4 Dataflyt Last ned definisjons-JSON og importer på nytt til målleietakeren. Skripting er mulig ved å bruke Admin-API-et.
5 Semantiske modeller / datasett Bruk sikkerhetskopiering og gjenoppretting til en ADLS Gen2-lagringskonto, eller last ned definisjonen og importer på nytt. Skripting er mulig ved å bruke Admin-API-et.
6 Rapporter Eiere eller administratorer laster ned .pbix og publiserer på nytt til mål-leietakeren. Alternativt kan du eksportere JSON-definisjonen. Skripting er mulig ved å bruke Admin-API-et.
7 Instrumentbord Ingen migrasjonsvei. Må gjenskapes manuelt.
8 Power BI-apper Ingen migrasjonsvei. Må gjenskapes manuelt.
9 Paginerte rapporter Eiere eller administratorer laster ned RDL-filen og publiserer til mål-leietakeren.

Important

Gjenskap alltid artefakter i denne rekkefølgen. Nedstrøms artefakter er avhengige av oppstrøms artefakter, og å hoppe over rekkefølgen kan føre til ødelagte referanser under utførelsen. Å utføre en Git-synkronisering sletter alle elementer i arbeidsområdet som ikke finnes i repotet.

Migrasjonsmetodikk

Vurder følgende referanseaktiviteter. De fleste steg gjelder for alle tre scenarioene. Steg som er spesifikke for et scenario er angitt i overskriftene deres.

Trinn 1: Oppdagelse og inventarvurdering

Bygg opp et komplett inventar over artefakter og avhengigheter, og identifiser hva du kan, ikke kan eller ikke bør migrere.

Aktiviteter

  • Kjør leietakerdekkende oppdagelse ved å bruke en kombinasjon av:
    • Power BI Admin-API-er
    • Fabric Admin-API-er
    • Aktivitetslogger (arbeidsområder, rapporter, datasett, oppdateringer)
    • Manuell dokumentasjon for elementer som ikke eksponeres av API-er
  • Fangst:
    • Arbeidsområder (type, kapasitet, region)
    • Rapporter, semantiske modeller (spesielt store lagringsformater), dataflyter
    • Fabric-artikler (Lakehouse, Warehouse, Eventhouse, notatbøker)
    • Gateways, datakilder, legitimasjon
    • Radernivå-sikkerhetsroller (RLS), arbeidsområdetillatelser, delingslenker
  • Klassifiser hvert arbeidsområde etter migrasjonskompleksitet (lav, middels, høy) basert på artefaktene det inneholder og avhengigheter.

Utdata

  • Et primært lagerregneark.
  • En klassifisering av migreringskompleksitet for hvert arbeidsområde.

Trinn 2: Bruker- og sikkerhetsoppdagelse

Fang brukeridentitet, lisensiering og tillatelser, og kartlegg dem mellom leietakere når det er nødvendig.

Ved en leietaker-ommapping bevares brukerobjekt-IDer. For side-ved-side migrering eller leietakerdeling har brukerne ulike objekt-ID-er i mål-leietakeren. Kartlegg hver kilde-leietaker-identitet til dens mål-leietaker-identitet. Tildel Power BI-lisenser på nytt (gratis, Pro, PPU). Speil sikkerhetsgrupper i den nye Microsoft 365-leietakeren.

Aktiviteter

Identifiser og registrer:

  • Power BI lisensoverdragelser (hentet fra Microsoft Graph)
  • Brukerobjekt-IDer i kildeleietakeren
  • Brukerobjekt-ID-er i målleietakeren (side om side eller kun splittet)
  • Brukertillatelser og arbeidsområdetilgangsnivåer
  • Nåværende innstillinger på leietakernivå (fang manuelt via administrasjonsportalen)
  • Nåværende styringskonfigurasjoner (sensitivitetsetiketter, godkjenningspolicyer)

Du kan hente ut arbeidsområde- og artefakttillatelser ved å bruke Power BI Admin-API-ene og Workspace Scanner API.

Trinn 3: Kommunikasjon med interessenter og endringsledelse

Kommuniser migreringsplanen tidlig for å redusere motstand og støttebelastning.

Viktige interessentgrupper

  • Overordnede sponsorer
  • Workspace-eiere og rapportforfattere
  • Sluttbrukere
  • IT-, sikkerhets- og identitetsteam

Aktiviteter

  • Utvikle en kommunikasjonsplan som omfatter:
    • Migrasjonsoversikt og begrunnelse.
    • Hva som er og ikke er migrert (for eksempel personlige arbeidsområder, inaktive arbeidsområder).
    • Hva endrer seg (URL-er, tilgang, oppdateringstidspunkt). Nedstrøms Power Apps og SharePoint-lenker som refererer til Power BI-URLer påvirkes også.
    • Hva endrer seg ikke (datasemantikk, visuelle elementer, forretningslogikk).
  • Kommuniser viktige datoer:
    • Frys vinduer (vanligvis omtrent en uke uten endringer i kildeleietakeren under siste sikkerhetskopi).
    • Forventet nedetid (for leietaker-omkartleggingsscenarier).
    • Valideringsperioder for interessenter til å verifisere sine egne rapporter i mål-leietakeren.
    • Milepæler for cutover og avviklingsdatoer for kildeleietakeren (side-ved-side-scenarier).

Utdata

  • En orienteringskortstokk for interessenter.
  • En FAQ for sluttbrukere.

Trinn 4: Send inn en forespørsel om leietakerkartlegging (kun leietakeromkartlegging)

Når migreringsdatoen er låst, send inn en supportsak og velg spesifikt alternativet for leietakeromlegging. En Microsoft-supportingeniør tar imot forespørselen.

Aktiviteter

  • Send inn supporthenvendelsen.
  • Fyll ut beredskapssjekklisten levert av Microsoft.
  • Bli enige om en migreringsdato og tidsluke, inkludert en reservetid.
  • Slett eksisterende kapasitet før leietakeromleggingen finner sted.

Forventede utfall

  • En typisk omkartlegging tar omtrent tre timer, men forsinkelser på opptil 24 timer er mulig hvis det oppstår komplikasjoner.
  • Etter at omkartleggingen er fullført, har den nye leietakeren samme leietaker-ID og befinner seg i den forespurte regionen.

Trinn 5: Mål leietakerens beredskap

En nylig opprettet eller nylig ommappet leietaker er ikke umiddelbart klar til å motta innhold. Konfigurer det først.

Aktiviteter

  • Konfigurer Power BI-leietakerinnstillinger:
    • Kontroller for opprettelse av arbeidsområder
    • Delings- og eksterne tilgangspolicyer
    • Styring av tilpassede visuelle elementer
    • Følsomhetsetiketter og informasjonsbeskyttelse
    • Revisjonslogg og overvåkingsaktivering
  • Kjøp Fabric-kapasiteter med lik eller høyere SKU enn kilden.
  • Konfigurer og valider gateways, gateway-klynger og datatilkobling.
  • For side-by-side eller leietakerdelingsscenarier:
    • Opprett en bruker i målleietakeren for hver bruker i kildeleietakeren, og registrer brukerkartleggingen.
    • Gjenopprett brukergrupper fra kildeleietakeren.
    • Tildel Power BI-lisenser i målleietakeren.
  • Juster styring: sensitivitetsetiketter, integrasjon med Microsoft Purview og retningslinjer for godkjenning.

Trinn 6: Migrasjonspilot

Kjør en testmigrering på et representativt prøvearbeidsområde før produksjonsmigreringen.

For side-ved-side-migrasjoner forblir kildeleietakeren tilgjengelig som en fallback for reprøver. For leietaker-ommapping er innhold som ikke ble sikkerhetskopiert korrekt før omkartleggingen ikke mulig å gjenopprette. En vellykket pilot er den viktigste måten å redusere risikoen på omkartleggingsbanen.

Kriterier for valg av pilotarbeidsområde

  • Inneholder en blanding av artefakter: rapporter, semantiske modeller, dataflows og Fabric-elementer.
  • Bruker realistiske datakilder og oppdateringsplaner.
  • Har arbeidsplass-nivå tillatelser og ideelt sett RLS.
  • Brukes aktivt, men er ikke kritisk for oppdraget.

Trinn 7: Migrasjonsutførelse

Gjennomfør migrasjonen. Støttede elementer skriptes først; Ustøttede elementer gjenskapes manuelt.

For store leietakere, skriv skript som pakker inn Power BI Admin API for å masseeksportere og masseprodusere artefakter.

Gjenskap artefakter i rekkefølgen definert i Hva støttes for migrasjon. Å hoppe over rekkefølgen bryter avhengigheter.

Trinn 8: Validering og testing

Valider at innholdet er migrert vellykket og oppfører seg korrekt.

Definisjoner av eksporterte semantiske modeller inkluderer ikke de underliggende dataene. Hver importert semantisk modell trenger minst én manuell oppdatering i mål-tenanten.

Tips

Vurder midlertidig å skalere til en SKU med høyere kapasitet under valideringen. Et stort antall samtidige oppdateringer kan ellers mette målkapasiteten.

Aktiviteter

  • Valider data: radantall, nøkkelaggregater, oppdateringssuksess.
  • Valider sikkerhet: RLS-regler, arbeidsområdetilgang, deling av scopes.
  • Valider ytelsen: rapporter lastetider, svartid på spørringer, kapasitetskapasitet.

Trinn 9: Brukerovergang og adopsjon

Flytt brukere til målleietakeren og oppdater nedstrøms applikasjoner.

Aktiviteter

  • Gi brukerne tilgang til arbeidsområder og artefakter i målleietakeren.
  • Oppdater innebygde rapport-URL-er, SharePoint-lenker, Power Apps-tilkoblinger og Power Automate-flyter som refererer til Power BI-innhold.
  • Deaktiver redigering i kildeleietakeren (skrivebeskyttet fase) før endelig avvikling.
  • Kjør korte aktiveringsøkter som dekker hva som har endret seg og hvor du kan finne innhold.

Relatert innhold

  • Last updated on