oversigt over overførsel af Power BI Premium til Microsoft Fabric

Microsoft udfaser Power BI Premium-SKU'er (P-SKU'er) pr. kapacitet. Hvert P SKU-abonnement slutter ved slutningen af den aktuelle aftaleperiode, og Microsoft sælger ikke længere nye P-SKU'er. Hvis du vil holde dine Power BI arbejdsbelastninger kørende, skal du migrere til Microsoft Fabric kapacitets-SKU'er (F SKU'er). I denne artikel får du et overblik over migreringen fra ende til anden: hvorfor Fabric F-SKU'er er vejen frem, hvilke ændringer og hvad der forbliver de samme for slutbrugere og administratorer, faserne i en typisk migrering og de scenarier, der bestemmer, hvor kompleks din migrering er.

Denne artikel henvender sig til Fabric administratorer, Power BI administratorer, it-arkitekter og kapacitetsejere, der planlægger og kører migreringen.

Vigtige oplysninger

Planlæg at fuldføre din migrering, før dit P SKU-abonnement slutter. Når dit abonnement er ophørt, går din kapacitet ind i en 30-dages respitperiode. Fra og med dag 31 begrænses adgangen (interaktive handlinger forsinkes). På dag 91 og derefter afvises alle handlinger – dine data bevares, men de er utilgængelige, indtil du overfører arbejdsområderne til en Fabric F SKU-kapacitet eller sletter kapaciteten. Hvis du vil undgå afbrydelser, skal du tildele dine arbejdsområder til en Fabric F SKU-kapacitet, før dit P SKU-abonnement slutter. Du kan se proceduren under Overfør arbejdsområder fra Power BI Premium til Microsoft Fabric.

Bemærk

Enterprise Agreement-kunder. Hvis din virksomhedsaftale stadig er aktiv, kan du fortsætte med at køre eksisterende P SKU-kapacitet og forny den årligt via din aftale, indtil EA-løbetiden udløber. Kunder med udløbne virksomhedsaftaler eller Microsoft Cloud-aftaler kan ikke tilføje eller købe ny P SKU-kapacitet via deres aftale. Bekræft dine specifikke kontraktvilkår med din Microsoft-konto repræsentant, før du beslutter, hvornår du vil migrere.

Bemærk

Denne tilbagetrækning har to vigtige områdegrænser:

  • Licenser pr. bruger påvirkes ikke.Power BI Pro og Power BI Premium pr. bruger fortsætter as-is. Du kan finde flere oplysninger under Udfases Power BI Premium pr. bruger også?
  • Integrerede licenser (EM, A) påvirkes ikke. Disse SKU'er er ikke en del af denne tilbagetrækning.
  • Nationale cloudmiljøer påvirkes endnu ikke. Microsoft Fabric er ikke tilgængelig i nationale cloudmiljøer, så P-SKU'er forbliver understøttet der. Microsoft giver separat vejledning, når Fabric bliver tilgængelig i disse miljøer.

Hvorfor migrere til Microsoft Fabric

Udfasning af P-SKU'er er den umiddelbare faktor, men Fabric F-SKU'er leverer også egenskaber, som P-SKU'er ikke kan:

  • Betal kun for det, du bruger. F-SKU'er er som standard betalt efter forbrug Azure fakturering med valgfri årlige eller flerårige reservationer for forudsigelige arbejdsbelastninger. Du kan også afbryde en kapacitet midlertidigt, når den ikke er i brug, for at stoppe faktureringen uden for arbejdstiden og senere genoptage den efter behov.
  • Skaler op eller ned når som helst. Tilpas størrelsen på kapaciteter via Azure-portalen, efterhånden som dine arbejdsbelastninger ændres, i stedet for at angive en fast størrelse for abonnementsperioden.
  • Brug den Azure oprindelige operativsystemmodel. Klargør og administrer kapacitet via Azure-portalen, anvend Azure-mærker til tilbageførsel, og optæl Fabric forbrug i forhold til din MACC (Microsoft Azure Consumption Commitment). Mange Fabric arbejdsbelastninger (f.eks. Lakehouses, Warehouses, Notebooks og Data Factory-pipelines) kører på enten P- eller F-kapaciteter, men den Azure driftsmodel er kun F.
  • Brug Power BI Embedded uden separate SKU'er. Integrerede scenarier dækkes af alle F SKU'er, så du behøver ikke separate EM- eller A-SKU'er.
  • Brug Azure oprindelige sikkerhed og handlinger. Administrerede private slutpunkter, adgang til arbejdsområder, der er tillid til, Azure Monitor og Microsoft Cost Management er alle tilgængelige med F-SKU'er.

Du kan se en komplet sammenligning af funktioner under Nøgleforskelle mellem Power BI Premium P-SKU'er og Fabric F-SKU'er.

Hvilke ændringer og hvad forbliver de samme

Migreringen omfatter primært en licens- og infrastrukturændring. Slutbrugeroplevelser og de fleste administrative funktionsmåder forbliver de samme. Nogle driftsområder ændres.

Areal Ændre? Når du har overført til F SKU
Rapporter, semantiske modeller, dashboards Samme Fortsæt med at arbejde uændret på F64-kapaciteter eller større kapaciteter.
Brugerlicenser (Pro, Premium pr. bruger, gratis) Samme Uændret. På F64 og større kan brugere med en Fabric gratis licens og rollen Seer få vist indhold på samme måde som på P-SKU'er. På F2 til og med F32 skal alle seere have en Pro- eller Premium pr. bruger-licens.
Arbejdsområder og apps Samme Arbejdsområder overdrages til den nye kapacitet. Arbejdsområdeapps, udrulningspipelines og Git-integration fungerer fortsat.
Opdater tidsplaner og pipelines Samme Fortsæt med at køre på den nye kapacitet. Aktive opdateringer kan blive afbrudt under omfordeling.
Power BI-rapportserver Det samme med licensændring Stadig tilgængelig med en Fabric kapacitetsreservation eller SQL Server Enterprise Edition med Software Assurance.
Power BI Embedded- Samme, enklere Inkluderet i hver F SKU. Separate EM- og A-SKU'er er ikke påkrævet.
Køb og fakturering Ændringer Flyt fra Microsoft 365 fakturering af forpligtelse til Azure fakturering. F SKU'er understøtter reservationer, der betales efter forbrug og år eller år.
Kapacitetsstyring Ændringer Primært administreret via Fabric-portalen (arbejdsområdetildelinger og indstillinger på kapacitetsniveau). Handlingerne pause, resume, scale up og scale down udføres via Azure-portalen.
automatisk skalering Ændringer P SKU-autoskalering findes ikke på F-SKU'er. I stedet bruger F-SKU'er størrelsen efter behov – du skalerer op eller ned manuelt via Azure-portalen.
Kapacitetsstyring Nye funktioner Nye funktioner til omkostningsstyring er tilgængelige på F SKU'er, f.eks. overspændingsbeskyttelse på arbejdsområdeniveau og beskyttelse mod overbeladning af kapacitet. Brug dem til at styre forbruget og forhindre løbske omkostninger.
Understøttelse af elementer på tværs af områder Ny overvejelse Standard Power BI elementer overlever en omfordeling på tværs af områder. Semantiske modeller i store lagerformater kræver sikkerhedskopiering og gendannelse eller rydning og konvertering til et mindre lagerformat, før der omfordeles. Alle Fabric elementer (Lakehouses, Warehouses, Notebooks, Data Factory-pipelines) medfører, at omfordeling mislykkes.

Et hurtigt overblik over migreringsrejsen

I sin reneste form er P-to-F-migrering en 1:1-flytning til den tilsvarende F-SKU i det samme Azure område. Kunder bruger ofte migreringen som en mulighed for at konsolidere kapaciteter, flytte på tværs af områder eller tilpasse størrelsen. Hver af disse ændringer tilføjer kompleksitet og risiko. Behandl disse ændringer som separate arbejdsstreams, der kører, når licensoverførslen er fuldført.

Migreringen følger de samme fem faser, uanset størrelse eller kompleksitet.

  1. Beslutte. Vælg, hvornår du vil migrere, hvilken F SKU der skal starte med, og om du vil forblive i det samme Azure område. Se beslutningsvejledningen Power BI Premium P SKU-migrering.
  2. Planlæg. Lagerarbejdsområder, oprindeligt CU-forbrug ved hjælp af appen Microsoft Fabric Capacity Metrics og anslå fremtidigt forbrug med Fabric SKU-estimat. Microsoft.Fabric Registrer ressourceudbyderen i Azure, og vælg et pilotprojekt. Til praktisk validering før køb skal du klargøre en Fabric prøvekapacitet til test af arbejdsbelastninger.
  3. Bestemmelse. Køb F SKU'en, før du omfordeler noget. Vælg pay-as-you-go eller en reservation, og bekræft Power BI-rapportserver licensering, hvis du bruger den.
  4. Overfør og valider. Tildel arbejdsområder på Fabric administrationsportal eller ved hjælp af notesbogen til migrering af kapacitet. I forbindelse med flytninger på tværs af områder skal du genoprette semantiske modeller i stort lagerformat og Fabric elementer i det nye område. Valider opdateringer, rapporter og gateways. Se Overfør arbejdsområder fra Power BI Premium til Microsoft Fabric.
  5. Nedlukning og drift. Annullering af P-SKU er manuel – Fabric fjerner ikke automatisk din P SKU, når du klargør en F SKU. Når du har valideret migreringen, skal du udtrykkeligt annullere P SKU-abonnementet i Microsoft 365 Administration. Konfigurer derefter omkostningsovervågning ved hjælp af Microsoft Cost Management, og udnyt fleksibiliteten ved at afbryde, genoptage og skalere Fabric.

Migreringsscenarier

De fleste kunder falder ind i et af følgende fire scenarier. De første tre scenarier følger standardtrinnene til migrering i Overfør arbejdsområder fra Power BI Premium til Microsoft Fabric.

scenarie Kompleksitet Bemærkninger
Samme lejer, samme område Lav Den anbefalede standard. Omfordel hvert arbejdsområde til den nye F SKU. Nul forventet nedetid bortset fra aktive opdateringer.
Samme lejer, på tværs af områder Moderat til høj Følger standardtrinnene for migrering, men semantiske modeller i stort lagerformat og Fabric elementer skal sikkerhedskopieres eller registreres i Git, slettes og oprettes igen i det nye område. Se Migreringer på tværs af områder: Særlig håndtering.
Multigeo (flere F-SKU'er i forskellige områder, samme lejer) Moderat Følger standardtrinnene til migrering, men du køber F-SKU'er i hvert målområde og planlægger styring for områdespecifikt indhold. Se Multigeo-migreringer.
Tværgående lejer Høj; understøttes ikke som en migrering med et enkelt klik Følger ikke standardtrinnene til migrering. Kræver manuel rekreation af gateways, semantiske modeller, arbejdsområder, rapporter, apps og dashboards. Overvej multigeo først. Se Migreringer på tværs af lejere.

Forsigtigt

Migreringer på tværs af områder indebærer en betydeligt større indsats end migreringer i samme område. Ud over de elementtyper, der ikke overlever omfordeling på tværs af områder, skal du planlægge:

  • Fabric elementer overlever ikke flytninger på tværs af områder. Lakehouses, Warehouses, Notebooks og Data Factory-pipelines medfører, at omfordeling mislykkes. Hent deres definitioner til Git (eller eksportér dem), før de omfordeles, og opret dem derefter igen i målområdet.
  • Genbinding af rapport. Når du sikkerhedskopierer og gendanner (eller sletter og geninstallerer) en stor semantisk lagermodel, får den genoprettede model et nyt GUID. Rapporter, der refererede til den oprindelige model, skal sendes tilbage til den genoprettede model.
  • Gatewayspild. Mål på tværs af områder kræver ofte yderligere konfiguration og validering af datagatewayen i det lokale miljø, især hvis dine gateways bruger Azure relæer under Byor (Bring Your Own Relay), fordi relæslutpunkter er områdebundne.

Vælg kun overførsel på tværs af områder, når dataopbevaring eller en anden hård begrænsning kræver det. Overførsel af samme område er den anbefalede standard.

Når du har overført

Når du har omfordelt arbejdsområder og valideret, at rapporter og opdateringer fungerer på den nye F SKU, skal du give dig selv et stabiliseringsvindue, før du annullerer P-SKU'en, og før du påtager dig valgfrit moderniseringsarbejde. Følgende aktiviteter hjælper dig med at bekræfte, at migreringen landede rent og beslutter, hvad du skal gøre.

Stabilisere omkostninger

F SKU-forbrug er forudsigeligt, hvis du lader kapaciteter køre døgnet rundt. Dine månedlige omkostninger forbliver stabile, selvom taksterne efter forbrug typisk er højere end den tilsvarende P SKU. Brug reservationer til at låse besparelserne for konstante arbejdsbelastninger, og brug pause og genoptagelse for kapaciteter, der virkelig er inaktive for dele af dagen. Sådan stabiliserer du omkostningerne:

  • Spor forbrug dagligt i de første 30 dage ved hjælp af Microsoft Cost Management.
  • Angiv Azure budgetter og beskeder for kapacitetens ressourcegruppe, så du får besked, før forbruget overskrider planen.
  • Evaluer en årlig Fabric kapacitetsreservation, når det daglige forbrug er konstant. Reservationer giver typisk rabat på forudsigelige arbejdsbelastninger.
  • Afbryd kapaciteter, der er inaktive uden for åbningstiden, midlertidigt for at stoppe faktureringen under disse vinduer.

Stabiliser ydeevnen

For en 1:1-migrering i området til den tilsvarende F SKU skal CU-forbruget svare nøje til din P SKU-basislinje efter stabilisering. Forvent ydeevnevariation, når migreringen omfatter en konfigurationsændring – et andet område, en anden SKU-størrelse eller konsolidering af arbejdsbelastninger – og valider, før du tager P-SKU'en ud af drift. Rapporterede overbelastninger efter migrering skyldes ofte ændringer af arbejdsbelastningen (en række opdateringer, tilføjet indhold, ændrede tidsplaner for opdatering) i stedet for selve migreringen. Kontrollér forbrugsmønstre, før du antager, at F-SKU'en er årsagen. Sådan stabiliserer du ydeevnen:

  • Overvåg den nye kapacitet med appen Microsoft Fabric Capacity Metrics i en til to uger efter cutover.
  • Sammenlign med den oprindelige plan, du har hentet på P-SKU'en. Undersøg store deltaer i opdateringshyppighed, datasætstørrelse eller interaktiv belastning, før du tilpasser størrelsen.
  • Skaler efter behov via Azure-portalen, hvis du kan se vedvarende begrænsning. Se Skaler din kapacitet.
  • Valider på tværs af en fuld forretningsproces – inkluder månedsafslutning og kvartalslukning – før du behandler den oprindelige plan som endelig.
  • Kontrollér den oprindelige plan igen, hver gang du tilføjer væsentligt nyt indhold eller ændrer tidsplaner for opdatering.
  • Valider igen efter en konfigurationsændring i din ende (SKU-størrelse, område, arbejdsbelastningstildeling).
  • Du kan finde en bredere vejledning i planlægning af kapacitetsvækst og styring i Microsoft Fabric vejledning til kapacitetsplanlægning.

Gennemse handlinger og styring

Nogle driftsindstillinger overføres ikke automatisk, når arbejdsområder flyttes til en F SKU. Gennemse følgende:

  • Bekræft Azure RBAC-tildelinger på kapacitetsressourcen, så de rette administratorer kan administrere den.
  • Anvend indstillingerne for arbejdsbelastninger på kapacitetsniveau igen (f.eks. grænser for semantisk modelhukommelse) på Fabric administrationsportal, hvis de er tilpasset på P-SKU'en.
  • Kontrollér lejerindstillingen for Fabric elementer og alle delegeringer, der er begrænset af kapacitet, igen.
  • Anvend Azure mærker på kapacitetsressourcen, så tilbageførsler og tilbagesendelsesrapporter attributér forbrug til det rette omkostningssted.
  • Evaluer nye funktioner til styring af kapacitetsforbrug, der er tilgængelige på F SKU'er (f.eks. overspændingsbeskyttelse på arbejdsområdeniveau og beskyttelse mod overbelastning af kapacitet) for at angive gelændere, før du åbner kapaciteten til et bredere forbrug.

Udforsk muligheder for modernisering

Mange Fabric moderniseringsscenarier er også teknisk mulige på P-SKU'er. Ændringerne i F SKU'er er driftsmodellen: Azure oprindelig omkostningsstyring, funktioner til styring af kapacitet (f.eks. beskyttelse mod overspænding og overbelægning) og samlet Azure RBAC gør det lettere at tage disse scenarier med tydeligere omkostningsafskærmninger og bedre driftssikkerhed. Disse indstillinger er valgfrie opfølgninger, ikke overførselskrav:

  • Hent eksisterende data til OneLake ved hjælp af Spejling og Genveje.
  • Konvertér semantiske DirectQuery-modeller til Direct Lake , hvor arbejdsbelastninger er en fordel.
  • Brug OneLake-sikkerhed til kontrolelementer til samlet dataadgang på tværs af Fabric arbejdsbelastninger.

Behandl disse indstillinger som separate arbejdsstreams, der kører, når licensoverførslen er fuldført. De blokerer ikke migrering og bør ikke udvide tidslinjen.

Relateret indhold

  • Last updated on