översikt över migrering Power BI Premium till Microsoft Fabric

Microsoft avvecklar Power BI Premium-SKU:er per kapacitet (P-SKU:er). Varje P SKU-prenumeration upphör i slutet av sin nuvarande avtalsperiod och Microsoft inte längre säljer nya P SKU:er. För att hålla dina Power BI-arbetsbelastningar igång migrerar du till kapacitets-SKU:er för Microsoft Fabric (F-SKU:er). Den här artikeln ger dig en översikt över migreringen från slutpunkt till slutpunkt: varför Fabric F-SKU:er är vägen framåt, vilka ändringar och vad som förblir desamma för slutanvändare och administratörer, stegen i en typisk migrering och de scenarier som avgör hur komplex migreringen är.

Den här artikeln gäller Fabric administratörer, Power BI administratörer, IT-arkitekter och kapacitetsägare som planerar och kör migreringen.

Important

Planera att slutföra migreringen innan din P SKU-prenumeration upphör. När din prenumeration upphör går din kapacitet in i en respitperiod på 30 dagar. Från och med dag 31 begränsas åtkomsten (interaktiva åtgärder fördröjs). Dag 91 och senare avvisas alla åtgärder – dina data behålls men är otillgängliga tills du migrerar arbetsytorna till en Fabric F SKU-kapacitet eller tar bort kapaciteten. Om du vill undvika störningar omtilldela dina arbetsytor till en Fabric F SKU-kapacitet innan din P SKU-prenumeration upphör. Mer information finns i Migrera arbetsytor från Power BI Premium till Microsoft Fabric.

Note

Enterprise-avtalskunder. Om ditt Enterprise-avtal fortfarande är aktivt kan du fortsätta att köra befintlig P SKU-kapacitet och förnya den årligen via ditt avtal tills EA-perioden upphör. Kunder med utgående Enterprise-avtal eller Microsoft Cloud-avtal kan inte lägga till eller köpa ny P SKU-kapacitet via sitt avtal. Bekräfta dina specifika avtalsvillkor med din Microsoft-konto representant innan du bestämmer när du ska migrera.

Note

Den här tillbakadragningen har två viktiga omfångsgränser:

Licenser per användare påverkas inte.Power BI Pro och Power BI Premium per användare (PPU) fortsätter as-is. Mer information finns i Har Power BI Premium per användare (PPU) också dragits tillbaka?
Inbäddade licenser (EM, A) påverkas inte. Dessa SKU:er är inte en del av den här tillbakadragningen.
Suveräna moln har ännu inte påverkats. Microsoft Fabric är inte tillgängligt i nationella moln, så P SKU:er stöds fortfarande där. Microsoft ger separat vägledning när Fabric blir tillgänglig i dessa miljöer.

Varför migrera till Microsoft Fabric

Tillbakadragandet av P SKU:er är den omedelbara drivkraften, men Fabric F SKU:er ger också funktioner som P SKU:er inte kan:

Du betalar bara för det du använder. F SKU:er har som standard Azure-fakturering enligt betala per användning, med valfria ettåriga eller fleråriga reservationer för förutsägbara arbetslaster. Du kan också pausa en kapacitet när den är inaktiv för att stoppa faktureringen utanför arbetstid och senare återuppta den på begäran.
Skala upp eller ned när som helst. Ändra storlek på kapaciteter via Azure portalen när dina arbetsbelastningar ändras, i stället för att binda till en fast storlek för prenumerationsperioden.
Använd den Azure interna driftsmodellen. Etablera och hantera kapacitet via Azure-portalen, tillämpa Azure taggar för återbetalning och räkna Fabric utgifter för ditt Microsoft Azure förbrukningsåtagande (MACC). Många Fabric-arbetsbelastningar (till exempel Lakehouses, Warehouses, Notebooks och Data Factory-pipelines) körs på antingen P- eller F-kapacitet, men Azures driftsmodell är endast F-baserad.
Använd Power BI Embedded utan separata SKU:er. Inbäddade scenarier omfattas av varje F SKU, så du behöver inte separata EM- eller A-SKU:er.
Använd Azure inbyggda säkerhet och åtgärder. Hanterade privata slutpunkter, åtkomst till betrodda arbetsytor, Azure Monitor och Microsoft Cost Management är alla tillgängliga med F-SKU:er.

Fullständig jämförelse av funktioner finns i Viktiga skillnader mellan Power BI Premium P SKU:er och Fabric F SKU:er.

Vilka ändringar och vad som förblir detsamma

Migreringen omfattar främst en licensiering och infrastrukturändring. Slutanvändarupplevelser och de flesta administrativa beteenden förblir desamma. Vissa verksamhetsområden ändras.

Område	Vill du ändra?	När du har migrerat till SKU:n F
Rapporter, semantiska modeller, instrumentpaneler	Samma	Fortsätt att fungera oförändrat på F64 eller större kapaciteter.
Användarlicenser (Pro, PPU, Free)	Samma	Oförändrad. På F64 och större kan användare med en kostnadsfri Fabric-licens och Viewer-rollen visa innehåll, precis som på P SKU:er. Från F2 till F32 behöver varje tittare en Pro- eller PPU-licens.
Arbetsytor och appar	Samma	Arbetsytor omtilldelas till den nya kapaciteten. Arbetsyteappar, distributionspipelines och Git-integrering fortsätter att fungera.
Uppdatera scheman och pipelines	Samma	Fortsätt att köra på den nya kapaciteten. Aktiva uppdateringar kan avbrytas under omtilldelningen.
Power BI Report Server	Samma sak med licensändring	Fortfarande tillgängligt, med en kapacitetsreservation för Fabric eller SQL Server Enterprise Edition med Software Assurance.
Power BI Embedded	Samma, enklare	Ingår med varje F-SKU. Separata EM- och A-SKU:er krävs inte.
Köp och fakturering	Changes	Gå från Microsoft 365 åtagandefakturering till Azure fakturering. F-SKU:er stöder betala per användning samt ettåriga eller fleråriga reservationer.
Kapacitetshantering	Changes	Hanteras främst via Fabric portalen (arbetsytetilldelningar och inställningar på kapacitetsnivå). Pausning, återupptagning, uppskalning och nedskalning genomförs i Azure-portalen.
Automatisk skalning	Changes	Autoskalning för P SKU stöds inte för F-SKU:er. I stället använder F-SKU:er storleksändring på begäran – du skalar upp eller ned manuellt via Azure portalen.
Kapacitetsstyrning	Nya funktioner	Nya funktioner för kostnadsstyrning finns tillgängliga på F-SKU:er, till exempel överspänningsskydd på arbetsytenivå och skydd mot överförbrukning av kapacitet. Använd dem för att kontrollera förbrukningen och förhindra skenande kostnader.
Stöd för objekt mellan regioner	Nytt övervägande	Standard-Power BI objekt överlever en omtilldelning mellan regioner. Semantiska modeller i stort lagringsformat kräver säkerhetskopiering och återställning eller rensning och konvertering till litet lagringsformat före omtilldelning. Alla Fabric-objekt (Lakehouses, Warehouses, Notebooks, Data Factory-pipelines) leder till att omtilldelningen misslyckas.

Migreringsresan i korthet

I sin renaste form är P-to-F-migrering en 1:1-flytt till motsvarande F SKU i samma Azure region. Kunder använder ofta migreringen som en möjlighet att konsolidera kapaciteter, flytta mellan regioner eller ändra storlek. Var och en av dessa ändringar ökar komplexiteten och risken. Behandla dessa ändringar som separata arbetsströmmar som körs när licensieringsmigreringen har slutförts.

Migreringen följer samma fem steg oavsett storlek eller komplexitet.

Bestäm. Välj när du ska migrera, vilken F SKU som ska börja med och om du vill stanna kvar i samma Azure region. Se beslutsguiden för Power BI Premium P SKU-migrering.
Plan. Inventera arbetsytor, fastställ baslinjen för CU-förbrukning med Microsoft Fabric Capacity Metrics app och uppskatta framtida förbrukning med Fabric SKU Estimator. Registrera resursprovidern Microsoft.Fabric i Azure och välj en pilotarbetsyta. För praktisk validering före köp etablerar du en utvärderingskapacitet för Fabric för att testa arbetsbelastningar.
Etablera. Köp F SKU innan du omtilldelar något. Välj Betala per användning eller en reservation och kontrollera Power BI Report Server licensiering om du använder den.
Migrera och verifiera. Tilldela om arbetsytor i Fabric-administratörsportalen eller genom att använda anteckningsboken för kapacitetsmigrering. Vid flytt mellan regioner återskapa semantiska modeller med stort lagringsformat och Fabric-objekt i den nya regionen. Verifiera uppdateringar, rapporter och gatewayer. Se Migrera arbetsytor från Power BI Premium till Microsoft Fabric.
Ta ur drift och driva. Annullering av P SKU:n är manuell – Fabric avvecklar inte automatiskt din P SKU när du etablerar en F SKU. När du har verifierat migreringen avbryter du uttryckligen P SKU-prenumerationen i Administrationscenter för Microsoft 365. Konfigurera sedan kostnadsövervakning med hjälp av Microsoft Cost Management och dra nytta av att pausa, återuppta och skala flexibiliteten i Fabric.

Migreringsscenarier

De flesta kunder hamnar i något av följande fyra scenarier. De första tre scenarierna följer standardmigreringsstegen i Migrera arbetsytor från Power BI Premium till Microsoft Fabric.

Scenario	Complexity	Noteringar
Samma klientorganisation, samma region	Låg	Den rekommenderade standardinställningen. Omtilldela varje arbetsyta till den nya F-SKU:n. Noll förväntad stilleståndstid förutom aktiva uppdateringar.
Samma klientorganisation, mellan regioner	Måttlig till hög	Följer standardmigreringsstegen, men semantiska modeller i stort lagringsformat och Fabric objekt måste säkerhetskopieras eller hämtas till Git, tas bort och återskapas i den nya regionen. Se Migreringar mellan regioner: Särskild hantering.
Multigeo (flera F SKU:er i olika regioner, samma klientorganisation)	Medel	Följer standardmigreringsstegen, men du köper F SKU:er i varje målregion och planerar styrning för regionspecifikt innehåll. Se Multigeo-migreringar.
Klientorganisationsövergripande	Hög; stöds inte som en migrering med ett klick	Följer inte standardmigreringsstegen. Kräver manuell återskapande av gatewayer, semantiska modeller, arbetsytor, rapporter, appar och instrumentpaneler. Överväg multigeo först. Se Migreringar mellan klientorganisationer.

Caution

Migreringar mellan regioner innebär betydligt mer arbete än migreringar i samma region. Utöver de objekttyper som inte överlever omtilldelning mellan regioner planerar du för:

Fabric objekt överlever inte flyttningar mellan regioner. Lakehouses, Warehouses, Notebooks och Data Factory-pipelines gör att omtilldelningen misslyckas. Samla in deras definitioner till Git (eller exportera dem) före omtilldelningen och återskapa dem sedan i målregionen.
Ombindning av rapporter. När du säkerhetskopierar och återställer (eller tar bort och distribuerar om) en stor semantisk modell i lagringsformat får den återskapade modellen ett nytt GUID. Rapporter som refererade till den ursprungliga modellen måste återställas till den återskapade modellen.
Gateway-omkostnader. Mål mellan regioner kräver ofta ytterligare konfiguration och validering av lokal datagateway, särskilt om dina gatewayer använder Azure reläer under Byor (Bring Your Own Relay), eftersom reläslutpunkter är regionbundna.

Välj migrering mellan regioner endast när datahemvist eller en annan hård begränsning kräver det. Migrering i samma region är det rekommenderade standardvärdet.

När du har migrerat

När du har tilldelat om arbetsytor och verifierat att rapporter och uppdateringar fungerar på den nya F SKU:n, ger du dig själv ett stabiliseringsfönster innan du avbryter P SKU:n och innan du påbörjar valfritt moderniseringsarbete. Följande aktiviteter hjälper dig att bekräfta att migreringen genomfördes utan problem och att avgöra vad du ska göra härnäst.

Stabilisera kostnaden

F SKU-utgifter är förutsägbara om du lämnar kapaciteter igång dygnet runt. Din månatliga kostnad förblir stabil, även om betala per användning-priser vanligtvis är högre än motsvarande P SKU. Använd reservationer för att säkra besparingar för stabila arbetsbelastningar, och använd funktionerna för att pausa och återuppta för kapaciteter som faktiskt är inaktiva delar av dagen. Så här stabiliserar du kostnaden:

Spåra utgifter dagligen under de första 30 dagarna med hjälp av Microsoft Cost Management.
Ange Azure budgetar och aviseringar för kapacitetens resursgrupp så att du meddelas innan utgifterna överskrider planen.
Överväg en årlig Fabric-kapacitetsreservation när den dagliga förbrukningen har stabiliserats. Reserveringar ger vanligtvis rabatt för förutsägbara arbetslaster.
Pausa kapaciteter som är inaktiva utanför kontorstid för att stoppa faktureringen under dessa fönster.

Stabilisera prestanda

Vid en 1:1-migrering inom samma region till motsvarande F SKU bör CU-förbrukningen i stort sett motsvara baslinjen för P SKU efter att allt har stabiliserats. Förvänta dig prestandavariationer när migreringen innehåller en konfigurationsändring – en annan region, en annan SKU-storlek eller arbetsbelastningskonsolidering – och verifiera innan du inaktiverar P SKU:n. Rapporterade överbelastningar efter migreringen orsakas ofta av arbetsbelastningsändringar (en ökning av uppdateringar, lagt till innehåll, ändrade uppdateringsscheman) i stället för själva migreringen. Kontrollera användningsmönster innan du antar att F SKU är orsaken. Så här stabiliserar du prestanda:

Övervaka den nya kapaciteten med Microsoft Fabric Capacity Metrics-appen under en till två veckor efter driftsättningen.
Jämför med den baslinje som du registrerade på P-SKU:n. Undersök stora avvikelser i uppdateringsfrekvens, datauppsättningens storlek eller interaktiv last innan du ändrar storleken.
Skala upp på begäran via Azure-portalen om du ser varaktiga begränsningar. Se Skala upp kapaciteten.
Verifiera under en fullständig konjunkturcykel – inkludera månadsslut och kvartalsvis stängning – innan du behandlar baslinjen som slutgiltig.
Kontrollera baslinjen igen när du lägger till betydande nytt innehåll eller ändra uppdateringsscheman.
Omvalidera efter eventuella konfigurationsändringar på din sida (SKU-storlek, region, arbetsbelastningstilldelning).
Mer information om hur du planerar kapacitetstillväxt och styrning finns i Microsoft Fabric guide för kapacitetsplanering.

Granska åtgärder och styrning

Vissa driftinställningar överförs inte automatiskt när arbetsytor flyttas till en F SKU. Granska följande:

Bekräfta Azure RBAC-tilldelningar på kapacitetsresursen så att rätt administratörer kan hantera den.
Använd arbetsbelastningsinställningarna på kapacitetsnivå igen (till exempel minnesgränser för semantisk modell) i Fabric administratörsportalen om de har anpassats på P SKU:n.
Kontrollera tenantinställningen Användare kan skapa Fabric-objekt igen samt eventuella delegeringar med kapacitetsomfång.
Använd Azure-taggar på kapacitetsresursen så att chargeback- och showback-rapporter kan hänföra kostnader till rätt kostnadsställe.
Utvärdera nya funktioner för kapacitetsanvändningsstyrning som är tillgängliga på F-SKU:er (till exempel överspänningsskydd på arbetsytenivå och skydd mot överförbrukning av kapacitet) för att ange skyddsräcken innan du öppnar kapaciteten till en bredare förbrukning.

Utforska moderniseringsmöjligheter

Många Fabric moderniseringsscenarier är tekniskt möjliga även på P-SKU:er. Det som ändras på F-SKU:er är driftsmodellen: Azure inbyggd kostnadshantering, funktioner för kapacitetsstyrning (till exempel överspännings- och överförbrukningsskydd) och enhetlig Azure RBAC gör det enklare att ta sig an dessa scenarier med tydligare kostnadsskydd och bättre driftsäkerhet. De här alternativen är valfria uppföljningar, inte migreringskrav:

Flytta befintliga data till OneLake med hjälp av Mirroring och Shortcuts.
Konvertera DirectQuery-semantiska modeller till Direct Lake där arbetsbelastningar gynnas.
Använd OneLake-säkerheten för enhetlig kontroll av dataåtkomst i Fabric-arbetsbelastningar.

Behandla dessa alternativ som separata arbetsströmmar som körs när licensieringsmigreringen har slutförts. De blockerar inte migrering och bör inte förlänga tidslinjen.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-07-22