Omówienie migracji Power BI Premium do Microsoft Fabric

Microsoft wycofuje jednostki SKU Power BI Premium na pojemność (jednostki SKU P). Każda subskrypcja jednostki SKU P kończy się na końcu bieżącego okresu umowy, a Microsoft nie sprzedaje już nowych jednostek SKU P. Aby zachować uruchamianie obciążeń Power BI, przeprowadź migrację do jednostek SKU pojemności Microsoft Fabric (F SKU). Ten artykuł przedstawia całościowy obraz migracji: wyjaśnia, dlaczego jednostki SKU F w usłudze Fabric są właściwym kierunkiem na przyszłość, co się zmienia, a co pozostaje bez zmian dla użytkowników końcowych i administratorów, jakie są etapy typowej migracji oraz jakie scenariusze decydują o tym, jak bardzo złożona będzie migracja.

Ten artykuł dotyczy administratorów Fabric, administratorów Power BI, architektów IT i właścicieli pojemności, którzy planują i przeprowadzają migrację.

Important

Zaplanuj zakończenie migracji przed końcem subskrypcji SKU P. Po zakończeniu subskrypcji wydajność przechodzi w 30-dniowy okres karencji. Począwszy od dnia 31, dostęp jest ograniczany (operacje interakcyjne są opóźnione). Od 91. dnia wszystkie operacje są odrzucane — dane są przechowywane, ale pozostają niedostępne do czasu zmigrowania obszarów roboczych do pojemności Fabric F SKU lub usunięcia pojemności. Aby uniknąć zakłóceń w działaniu, przypisz ponownie obszary robocze do pojemności Fabric z jednostką SKU F, zanim wygaśnie subskrypcja jednostki SKU P. Aby zapoznać się z procedurą, zobacz Migrowanie obszarów roboczych z usługi Power BI Premium do Microsoft Fabric.

Note

Klienci z umową Enterprise Agreement. Jeśli Twoja umowa Enterprise Agreement jest nadal aktywna, możesz nadal korzystać z istniejącej pojemności w jednostce SKU P i odnawiać ją co roku w ramach tej umowy do końca okresu obowiązywania umowy EA. Klienci z wygasającą umową Enterprise Agreement lub umowami Microsoft Cloud nie mogą dodawać ani kupować nowej jednostki SKU P za pośrednictwem umowy. Przed podjęciem decyzji o migracji potwierdź określone warunki umowy z przedstawicielem konto Microsoft.

Note

To wycofanie z użycia ma dwa istotne ograniczenia zakresowe:

Licencje przypisane do użytkowników pozostają bez zmian.Power BI Pro i Power BI Premium na użytkownika (PPU) pozostają bez zmian. Aby uzyskać więcej informacji, zobacz Czy Power BI Premium na użytkownika (PPU) również zostanie wycofany?
Licencje osadzone (EM, A) nie mają wpływu. Te numery SKU nie są objęte tym wycofaniem.
Chmury suwerenne nie są jeszcze tym dotknięte. Microsoft Fabric nie jest dostępna w suwerennych chmurach, więc jednostki SKU P pozostają tam obsługiwane. Microsoft udostępni oddzielne wskazówki, gdy Fabric stanie się dostępna w tych środowiskach.

Dlaczego warto przeprowadzić migrację do Microsoft Fabric

Wycofanie jednostek SKU P jest bezpośrednią przyczyną, ale jednostki SKU Fabric F oferują również możliwości, których jednostki SKU P nie zapewniają:

Płacisz wyłącznie za rzeczywiste użycie. Jednostki SKU F domyślnie korzystają z rozliczeń platformy Azure w modelu płatności zgodnie z rzeczywistym użyciem, z opcjonalnymi rezerwacjami rocznymi lub wieloletnimi dla przewidywalnych obciążeń. Możesz również wstrzymać zasób, gdy jest bezczynny, aby wstrzymać naliczanie opłat po godzinach, a następnie uruchomić go ponownie w razie potrzeby.
Zwiększaj lub zmniejszaj skalę w dowolnym momencie. Zmiana rozmiaru pojemności za pośrednictwem portalu Azure w miarę zmiany obciążeń zamiast zatwierdzania stałego rozmiaru dla okresu subskrypcji.
Użyj natywnego modelu operacyjnego Azure. Udostępniaj pojemność i zarządzaj nią w portalu Azure, stosuj tagi Azure do rozliczeń zwrotnych i uwzględniaj wydatki na usługę Fabric w ramach zobowiązania Microsoft Azure Consumption Commitment (MACC). Wiele obciążeń w usłudze Fabric (takich jak lakehouse’y, hurtownie danych, notesy i potoki usługi Data Factory) działa w pojemnościach P lub F, ale model operacyjny platformy Azure obsługuje wyłącznie pojemności F.
Użyj Power BI Embedded bez oddzielnych jednostek SKU. Scenariusze wbudowane są uwzględnione w każdym wariancie SKU F, więc nie trzeba osobnych wariantów SKU EM ani A.
Użyj Azure natywnych operacji i zabezpieczeń. Zarządzane prywatne punkty końcowe, zaufany dostęp do obszaru roboczego, Azure Monitor i Microsoft Cost Management są dostępne w jednostkach SKU F.

Aby zapoznać się ze szczegółowym porównaniem funkcji, zobacz Kluczowe różnice między jednostkami SKU P usługi Power BI Premium a jednostkami SKU F usługi Fabric.

Co zmienia się i co pozostaje takie same

Migracja obejmuje przede wszystkim zmianę licencjonowania i infrastruktury. Środowiska użytkownika końcowego i większość zachowań administracyjnych pozostają takie same. Niektóre obszary operacyjne zmieniają się.

Area	Zmienić?	Po migracji do jednostki SKU F
Raporty, modele semantyczne, pulpity nawigacyjne	To samo	Kontynuuj pracę bez zmian w pojemnościach F64 lub większych.
Licencje użytkowników (Pro, PPU, Bezpłatna)	To samo	Niezmienione. W jednostkach SKU F64 i wyższych użytkownicy z bezpłatną licencją Fabric oraz rolą Viewer mogą wyświetlać zawartość, podobnie jak w jednostkach SKU P. W przypadku F2 do F32 każda osoba przeglądająca potrzebuje licencji Pro lub PPU.
Obszary robocze i aplikacje	To samo	Obszary robocze są ponownie przypisywane do nowej pojemności. Aplikacje obszarów roboczych, potoki wdrażania i integracja z usługą Git nadal działają.
Odświeżanie harmonogramów i potoków	To samo	Kontynuuj działanie przy użyciu nowej wydajności. Aktywne odświeżanie może zostać przerwane podczas ponownego przypisania.
Serwer raportów usługi Power BI	To samo z zmianą licencji	Nadal jest dostępna w ramach rezerwacji pojemności usługi Fabric lub SQL Server Enterprise Edition z pakietem Software Assurance.
Power BI Embedded	Takie same, prostsze	Dołączone do każdego wariantu SKU F. Oddzielne jednostki SKU EM i A nie są wymagane.
Zakup i rozliczenia	Changes	Przejdź z rozliczania w ramach zobowiązania Microsoft 365 na rozliczanie Azure. Jednostki SKU F obsługują model płatności zgodnie z rzeczywistym użyciem oraz rezerwacje roczne lub wieloletnie.
Zarządzanie pojemnością	Changes	Zarządzana głównie za pośrednictwem portalu Fabric (przypisań obszarów roboczych i ustawień na poziomie pojemności). Operacje wstrzymywania, wznawiania, skalowania w górę i skalowania w dół są wykonywane za pośrednictwem portalu Azure.
Autoskalowanie	Changes	Automatyczne skalowanie jednostek SKU P nie jest dostępne w jednostkach SKU F. Zamiast tego jednostki SKU F używają zmiany rozmiaru na żądanie — skaluje się je ręcznie w górę lub w dół w portalu Azure.
Zarządzanie wydajnością	Nowe możliwości	Nowe funkcje zarządzania kosztami są dostępne dla jednostek SKU F, takie jak ochrona przed skokowym wzrostem użycia na poziomie obszaru roboczego oraz ochrona przed przekroczeniem pojemności. Używaj ich do kontrolowania zużycia i zapobiegania niekontrolowanemu wzrostowi kosztów.
Obsługa elementów międzyregionalnych	Nowa uwaga	Standardowe elementy Power BI są zachowywane po ponownym przypisaniu między regionami. Modele semantyczne w dużym formacie przechowywania wymagają wykonania kopii zapasowej i przywrócenia albo wyczyszczenia i przekonwertowania do małego formatu przechowywania przed ponownym przypisaniem. Wszystkie elementy Fabric (Lakehouses, Warehouses, Notebooks, Data Factory pipelines) powodują niepowodzenie ponownego przypisania.

Podróż po migracji na pierwszy rzut oka

W najprostszej postaci migracja P-to-F polega na przeniesieniu 1:1 do równoważnego SKU F w tym samym regionie platformy Azure. Klienci często używają migracji jako okazji do konsolidacji pojemności, przenoszenia między regionami lub zmiany rozmiaru. Każda z tych zmian zwiększa złożoność i ryzyko. Potraktuj te zmiany jako odrębne strumienie prac realizowane po zakończeniu migracji licencji.

Migracja jest zgodna z tymi samymi pięcioma etapami niezależnie od rozmiaru lub złożoności.

Zdecyduj. Wybierz, kiedy przeprowadzić migrację, od której jednostki SKU F zacząć i czy pozostać w tym samym regionie Azure. Zobacz przewodnik dotyczący podejmowania decyzji o migracji jednostki SKU Power BI Premium P.
Plan. Sporządź spis obszarów roboczych, określ bazowe zużycie jednostek CU przy użyciu aplikacji Microsoft Fabric Capacity Metrics i oszacuj przyszłe zużycie za pomocą narzędzia Fabric SKU Estimator. Zarejestruj dostawcę Microsoft.Fabric zasobów w Azure i wybierz obszar roboczy pilotażowy. Aby przeprowadzić walidację praktyczną przed zakupem, aprowizuj pojemność wersji próbnej Fabric, aby przetestować obciążenia.
Zapewnienie. Kup jednostkę SKU F, zanim ponownie przypiszesz cokolwiek. Wybierz model płatności zgodnie z rzeczywistym użyciem lub rezerwację i zweryfikuj licencjonowanie programu Serwer raportów usługi Power BI, jeśli go używasz.
Migrowanie i weryfikowanie. Przypisz ponownie obszary robocze w portalu administracyjnym Fabric lub za pomocą notatnika migracji pojemności. W przypadku przenoszenia między regionami utwórz ponownie modele semantyczne w formacie Large Storage Format oraz elementy usługi Fabric w nowym regionie. Weryfikować odświeżenia, raporty i bramy danych. Zobacz Migrowanie obszarów roboczych z usługi Power BI Premium do Microsoft Fabric.
Likwiduj i operuj. Anulowanie jednostki SKU P odbywa się ręcznie — Fabric nie wycofuje automatycznie jednostki SKU P podczas aprowizacji jednostki SKU F. Po zweryfikowaniu migracji jawnie anuluj subskrypcję jednostki SKU P w Centrum administracyjne platformy Microsoft 365. Następnie skonfiguruj monitorowanie kosztów przy użyciu Microsoft Cost Management i korzystaj z możliwości wstrzymywania, wznawiania i skalowania w Fabric.

Scenariusze migracji

Większość klientów należy do jednego z następujących czterech scenariuszy. Pierwsze trzy scenariusze są zgodne ze standardowymi krokami migracji w temacie Migrowanie obszarów roboczych z Power BI Premium do Microsoft Fabric.

Scenario	Complexity	Notes
Ta sama dzierżawa, ten sam region	Low	Zalecana wartość domyślna. Przypisz ponownie każdy obszar roboczy do nowej jednostki SKU F. Nie przewiduje się przestojów, z wyjątkiem ewentualnych aktywnie trwających odświeżeń.
Ten sam tenant, między regionami	Umiarkowany do wysoki	Należy wykonać standardowe kroki migracji, ale modele semantyczne w formacie dużego magazynu oraz elementy usługi Fabric muszą zostać zarchiwizowane w kopii zapasowej lub zapisane w repozytorium Git, usunięte, a następnie ponownie utworzone w nowym regionie. Zobacz Migracje między regionami: Specjalna obsługa.
Multigeo (wiele jednostek SKU F w różnych regionach, w ramach tej samej dzierżawy)	Umiarkowane	Obejmuje standardowe kroki migracji, ale wymaga zakupu jednostek SKU F w każdym regionie docelowym oraz zaplanowania zarządzania treściami specyficznymi dla danego regionu. Zobacz Migracje multigeo.
Międzydzierżawowy	Wysokie; nieobsługiwane w ramach migracji jednym kliknięciem	Nie przestrzega standardowych kroków migracji. Wymaga ręcznego odtworzenia bram, modeli semantycznych, obszarów roboczych, raportów, aplikacji i pulpitów nawigacyjnych. Najpierw weź pod uwagę multigeo. Zobacz Migracje między dzierżawami.

Caution

Migracje między regionami wymagają znacznie większego nakładu pracy niż migracje w tym samym regionie. Oprócz typów elementów, które nie przetrwają ponownego przypisania między regionami, uwzględnij:

Fabric elementy nie przetrwają przenoszenia między regionami. Lakehouses, Warehouses, Notebooks i potoki Data Factory powodują, że ponowne przypisanie kończy się niepowodzeniem. Przechwyć definicje w usłudze Git (lub wyeksportuj je) przed ponownym przypisaniem, a następnie utwórz je ponownie w regionie docelowym.
Ponowne wiązanie raportu. Podczas tworzenia kopii zapasowej i przywracania (lub usuwania i ponownego wdrażania) dużego modelu semantycznego w formacie magazynu utworzony ponownie model pobiera nowy identyfikator GUID. Raporty odwołujące się do oryginalnego modelu muszą zostać ponownie powiązane z odtworzonym modelem.
Obciążenie bramy. Cele między regionami często wymagają dodatkowej konfiguracji i weryfikacji lokalnej bramy danych, zwłaszcza jeśli bramy korzystają z przekaźników Azure w obszarze Bring Your Own Relay (BYOR), ponieważ punkty końcowe przekaźnika są powiązane z regionem.

Decyduj się na migrację międzyregionową tylko wtedy, gdy wymagają tego wymogi rezydencji danych lub inne nieprzekraczalne ograniczenie. Migracja w tym samym regionie jest zalecaną wartością domyślną.

Po przeprowadzeniu migracji

Po ponownym przypisaniu obszarów roboczych i zweryfikowaniu, że raporty oraz odświeżanie działają w nowej jednostce SKU F, należy odczekać okres stabilizacji przed anulowaniem jednostki SKU P i przed podjęciem jakichkolwiek opcjonalnych prac modernizacyjnych. Poniższe działania pomogą potwierdzić, że migracja przebiegła pomyślnie, i zdecydować, co zrobić dalej.

Stabilizuj koszt

Wydatki na jednostkę SKU typu F są przewidywalne, jeśli pozostawisz zasoby mocy obliczeniowej uruchomione przez całą dobę. Twój miesięczny koszt pozostaje stabilny, jednak stawki w modelu płatności zgodnie z rzeczywistym użyciem są zwykle wyższe niż w przypadku równoważnego modelu SKU P. Korzystaj z rezerwacji, aby zapewnić oszczędności w przypadku stałych obciążeń, oraz z funkcji wstrzymywania i wznawiania w przypadku zasobów, które przez część dnia faktycznie pozostają nieużywane. Aby ustabilizować koszt:

Śledzenie wydatków dziennie przez pierwsze 30 dni przy użyciu Microsoft Cost Management.
Skonfiguruj budżety i alerty platformy Azure dla grupy zasobów pojemności, aby otrzymać powiadomienie, zanim wydatki przekroczą plan.
Oceń roczną rezerwację pojemności w usłudze Fabric, gdy dzienne zużycie się ustabilizuje. Rezerwacje zazwyczaj oferują zniżki na przewidywalne obciążenia robocze.
Wstrzymaj bezczynne zasoby poza godzinami pracy, aby w tych okresach wstrzymać naliczanie opłat.

Stabilizacja wydajności

W przypadku migracji 1:1 w obrębie tego samego regionu do równoważnego SKU F zużycie CU po ustabilizowaniu powinno być ściśle zbliżone do wartości bazowej dla SKU P. Spodziewaj się zmian wydajności, gdy migracja obejmuje zmianę konfiguracji — inny region, inny rozmiar jednostki SKU lub konsolidację obciążeń — i sprawdź poprawność przed zlikwidowanie jednostki SKU P. Zgłaszane przeciążenia po migracji są często spowodowane zmianami obciążenia (wzrost liczby odświeżeń, dodanie zawartości, zmienione harmonogramy odświeżania) zamiast samej migracji. Zanim założysz, że przyczyną jest jednostka SKU F, sprawdź schematy użycia. Aby ustabilizować wydajność:

Monitoruj nową pojemność za pomocą aplikacji Microsoft Fabric Capacity Metrics przez okres od jednego do dwóch tygodni po przełączeniu.
Porównaj z wartością bazową zarejestrowaną dla jednostki SKU P. Zbadaj duże różnice w częstotliwości odświeżania, rozmiarze zestawu danych lub interakcyjnym obciążeniu przed zmianą rozmiaru.
W razie potrzeby zwiększ skalę w portalu Azure, jeśli widzisz utrzymujące się ograniczanie przepustowości. Zobacz Skalowanie pojemności.
Zweryfikuj cały cykl biznesowy — uwzględnij koniec miesiąca i kwartalne zamknięcie — przed traktowaniem planu bazowego jako końcowego.
Ponownie sprawdź plan bazowy za każdym razem, gdy dodasz znaczącą nową zawartość lub zmienisz harmonogramy odświeżania.
Po każdej zmianie konfiguracji po swojej stronie (rozmiar jednostki SKU, region, przypisanie obciążenia) przeprowadź ponowną walidację.
Aby uzyskać szersze wskazówki dotyczące planowania wzrostu pojemności i ładu organizacyjnego, zobacz przewodnik planowania pojemności w Microsoft Fabric.

Przegląd operacji i nadzoru

Niektóre ustawienia operacyjne nie są automatycznie przenoszone, gdy obszary robocze przechodzą do jednostki SKU F. Przejrzyj następujące treści:

Potwierdź przypisania kontroli dostępu opartej na rolach platformy Azure dla zasobu pojemności, tak aby właściwi administratorzy mogli nim zarządzać.
Ponownie zastosuj ustawienia obciążenia na poziomie pojemności (na przykład limity pamięci modelu semantycznego) w portalu administracyjnym Fabric, jeśli zostały one dostosowane w jednostce SKU P.
Sprawdź ponownie ustawienie dzierżawy Użytkownicy mogą tworzyć elementy usługi Fabric oraz wszelkie delegacje o zakresie pojemności.
Zastosuj tagi platformy Azure do zasobu przepustowości, aby w raportach rozliczeniowych i informacyjnych wydatki były przypisywane do właściwego centrum kosztów.
Oceń nowe funkcje zarządzania wykorzystaniem pojemności dostępne w jednostkach SKU F (takie jak ochrona przed skokami użycia na poziomie obszaru roboczego i ochrona przed przekroczeniem pojemności), aby ustawić odpowiednie zabezpieczenia przed udostępnieniem pojemności do szerszego wykorzystania.

Eksplorowanie możliwości modernizacji

Wiele scenariuszy modernizacji w usłudze Fabric jest również technicznie możliwych w jednostkach SKU z serii P. To, co zmienia się w jednostkach SKU F, to model operacyjny: natywne dla platformy Azure zarządzanie kosztami, funkcje zarządzania pojemnością (takie jak ochrona przed skokami użycia i przekroczeniami limitów) oraz ujednolicone mechanizmy kontroli dostępu opartej na rolach platformy Azure (Azure RBAC) ułatwiają obsługę tych scenariuszy dzięki bardziej przejrzystym mechanizmom kontroli kosztów i większej pewności operacyjnej. Są to opcjonalne działania następcze, a nie wymagania dotyczące migracji:

Przenieś istniejące dane do usługi OneLake za pomocą funkcji Mirroring i Shortcuts.
Konwertuj modele semantyczne trybu DirectQuery na Direct Lake tam, gdzie przynosi to korzyści obciążeniom.
Wdróż zabezpieczenia OneLake, aby ujednolicić mechanizmy kontroli dostępu do danych we wszystkich obciążeniach roboczych w usłudze Fabric.

Traktuj te opcje jako oddzielne strumienie prac realizowane po zakończeniu migracji licencji. Nie blokują migracji i nie powinny rozszerzać osi czasu.

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-07-22