Migracja Power BI Premium do Microsoft Fabric - praktyczny przewodnik dla administratorów

Dlaczego Microsoft wymusza migrację z Power BI Premium

Od marca 2024 roku Microsoft konsekwentnie realizuje strategię konsolidacji swoich usług analitycznych. Power BI Premium, zarządzane dotychczas przez Microsoft 365, ustępuje miejsca Microsoft Fabric opartemu na infrastrukturze Azure. To nie jest zmiana kosmetyczna, chodzi o fundamentalną przebudowę architektury.

Główne przyczyny tej transformacji są pragmatyczne. Azure oferuje znacznie lepsze mechanizmy zarządzania kosztami, systemy kwot i funkcje governance. Dla Microsoft utrzymywanie dwóch oddzielnych ścieżek zakupowych i administracyjnych po prostu przestało mieć sens biznesowy.

Dla administratorów DBA oznacza to jedno,  migracja nie jest opcjonalna. Klienci z umowami Enterprise Agreement mogą odnawiać Power BI Premium do momentu wygaśnięcia kontraktu. Po tym terminie przejście na Fabric staje się obowiązkowe. Wyjątkiem są użytkownicy sovereign clouds, gdzie Fabric nie jest jeszcze dostępny.

Z mojego doświadczenia wynika, że organizacje odkładające migrację na ostatnią chwilę płacą za to podwójnie, stresem zespołu i nieplanowanymi przestojami. 30 dni darmowej pojemności Fabric po wygaśnięciu P-SKU to znacznie mniej czasu, niż się wydaje przy kilkudziesięciu workspace'ach.

Krytyczne terminy i konsekwencje opóźnień

Microsoft ustalił precyzyjny harmonogram, który każdy administrator powinien znać na pamięć. Ignorowanie tych terminów prowadzi do wymiernych strat operacyjnych.

Po wygaśnięciu subskrypcji P-SKU masz 30 dni darmowej pojemności Fabric odpowiadającej poprzedniemu P-SKU. To okno czasowe na przeprowadzenie migracji bez podwójnego płacenia za dwie pojemności jednocześnie.

Dostęp do danych Power BI zachowujesz przez 90 dni od wygaśnięcia. Po tym okresie dane mogą zostać zablokowane. To nie jest teoretyczne ostrzeżenie,  widziałem organizacje, które straciły dostęp do krytycznych raportów, bo zignorowały te terminy.

Dodatkowa komplikacja pojawia się po 30 dniach od końca subskrypcji P-SKU — operacje interaktywne zaczynają być opóźniane nawet o 20 sekund. Po 90 dniach pojemność może zostać całkowicie zamrożona. Dla środowisk produkcyjnych z setkami użytkowników to scenariusz katastrofy.

Porównanie SKU — co faktycznie otrzymujesz w Fabric

Przejście z P-SKU na F-SKU to nie prosta zamiana nazwy. Microsoft Fabric wprowadza istotne różnice w modelu licencjonowania i funkcjonalności.

Podstawowa różnica dotyczy opcji zobowiązań. P-SKU oferowało model miesięczny lub roczny. F-SKU dodaje opcję pay-as-you-go, co daje większą elastyczność, ale wymaga staranniejszego monitorowania zużycia.

Struktura cenowa również się zmienia, z globalnej na regionalną. Oznacza to, że koszty mogą się różnić w zależności od lokalizacji pojemności. Dla organizacji z rozproszoną infrastrukturą to istotna zmiana w planowaniu budżetu.

F-SKU zawiera domyślnie Power BI Embedded, które w modelu Premium wymagało osobnego EM-SKU. To uproszczenie dla firm wykorzystujących osadzanie raportów w aplikacjach zewnętrznych.

Najważniejsza różnica to jednak integracja z Azure, Trusted Workspace Access, Managed Private Endpoints i zgodność z MACC (Microsoft Azure Consumption Commitment). Dla organizacji z istniejącymi zobowiązaniami Azure wydatki na Fabric mogą być wliczane do tych kontraktów.

Co zyskujesz poza Power BI

Microsoft Fabric to platforma integrująca siedem głównych komponentów: Power BI, Data Factory, Real-Time Intelligence, Data Engineering, Data Science, Data Warehouse i Databases. Wszystkie współdzielą OneLake jako centralną warstwę przechowywania danych.

Dla DBA szczególnie interesujący jest Data Warehouse, nowoczesny magazyn SQL z możliwością niezależnego skalowania i przechowywaniem danych w formacie Delta Lake. To otwiera drzwi do scenariuszy, które w czystym Power BI Premium były niemożliwe lub wymagały skomplikowanych obejść.

Procedura migracji krok po kroku

Migracja techniczna nie jest skomplikowana, ale wymaga metodycznego podejścia. Oto sprawdzony proces, który stosuję przy projektach migracyjnych.

Krok 1: Identyfikacja regionu macierzystego

W Power BI kliknij ikonę znaku zapytania i wybierz About Power BI. Zidentyfikuj region przechowywania danych. Ta informacja jest krytyczna, pojemność Fabric musi być w tym samym regionie, aby uniknąć problemów z latencją.

Krok 2: Weryfikacja umiejscowienia pojemności

Upewnij się, że zakupiona pojemność Fabric znajduje się w tym samym regionie co obecna pojemność Premium. Migracje międzyregionowe są możliwe, ale wymagają dodatkowych kroków.

Krok 3: Aktualizacja licencji workspace'ów

W ustawieniach workspace znajdź sekcję License Info. Przełącz z Power BI Premium capacity na Microsoft Fabric capacity i wybierz odpowiedni F-SKU. Dla dużej liczby workspace'ów administratorzy mogą używać zbiorczego przypisywania przez portal administracyjny.

Krok 4: Obsługa elementów Fabric

Tu pojawia się komplikacja. Jeśli workspace zawiera elementy Fabric (Lakehouses, bazy SQL) i migrujesz między regionami, wymagana jest ręczna interwencja. Przed migracją usuń istniejące elementy Fabric, po migracji odtwórz je w nowym regionie. Integracja Git znacząco przyspiesza ten proces.

Opcje automatyzacji

Microsoft udostępnia notebook do automatyzacji migracji. Wymaga włączenia funkcji Fabric w tenancie. Alternatywnie można użyć Semantic Link Labs Notebook dla bardziej zaawansowanych scenariuszy. Oba rozwiązania są dostępne w dokumentacji Microsoft.

Pułapki migracyjne i jak ich unikać

Po przeprowadzeniu kilkudziesięciu migracji mogę wskazać najczęstsze problemy, które torpedują projekty.

Duże modele semantyczne wymagają optymalizacji przed migracją. Fabric ma inne charakterystyki wydajnościowe i model, który działał akceptowalnie w Premium, może wykazywać problemy po przeniesieniu. Testuj wydajność przed przekierowaniem użytkowników produkcyjnych.

Ograniczenia regionalne są częstą przyczyną frustracji. Migracje międzyregionowe nie są automatyczne. Dodatkowo mogą wprowadzać zauważalną latencję, szczególnie przy dużych wolumenach danych.

Zgodność z regulacjami dotyczącymi rezydencji danych wymaga szczególnej uwagi przy migracji. Upewnij się, że nowa lokalizacja pojemności spełnia wymagania RODO i wewnętrzne polityki bezpieczeństwa.

Brak monitoringu po migracji to klasyczny błąd. Capacity Metrics App w Fabric pozwala śledzić wykorzystanie i wydajność pojemności. Autoskalowanie pomaga zarządzać szczytami obciążenia, ale bez monitoringu możesz nieświadomie generować wysokie koszty.

Rekomendacje wdrożeniowe

Na podstawie praktyki projektuję migracje według następującego schematu, który minimalizuje ryzyko i zakłócenia operacyjne.

Zacznij od inwentaryzacji. Zidentyfikuj wszystkie workspace'y, ich właścicieli, krytyczność biznesową i wzorce użycia. Ta wiedza pozwala priorytetyzować kolejność migracji.

Przeprowadź migrację testową w środowisku deweloperskim. Nie migruj produkcji jako pierwszej. Zbuduj kompetencje zespołu na mniej krytycznych zasobach.

Komunikuj zmiany użytkownikom końcowym. Migracja może wpływać na dostępność raportów. Zaplanuj okno serwisowe i poinformuj interesariuszy z wyprzedzeniem.

Wykorzystaj 30-dniowe okno darmowej pojemności strategicznie. To czas na weryfikację, nie na eksperymentowanie. Przed wygaśnięciem P-SKU powinieneś mieć już przetestowany plan migracji.

Po migracji zrewiduj polityki governance. Zmiana pojemności to dobry moment na uporządkowanie uprawnień, struktury workspace'ów i standardów bezpieczeństwa zgodnie z best practices Fabric.