Koniec LCS: jak przygotować się na migrację do Power Platform Admin Center

Lifecycle Services towarzyszy środowiskom Dynamics 365 Finance & Operations od początku ich istnienia. Do tego stopnia, że dla wielu zespołów administracyjnych „zarządzanie F&O” i „praca w LCS” to synonimy. Ta era się kończy. Żywotność LCS jest już określona: choć terminy jego decommissioningu bywały przesuwane i platforma może przeżyć jeszcze wiele miesięcy, klienci F&O będą finalnie zobligowani do rezygnacji z tego środowiska i przeniesienia się do Power Platform Admin Center (PPAC).

Dla zespołów utrzymania to nie jest zmiana kosmetyczna. To migracja miejsca, w którym wykonuje się operacje krytyczne dla ciągłości usług: zarządzanie środowiskami, wdrożenia, refreshe baz. Przygotowanie prac administracyjnych pod tę zmianę jest obligatoryjne, aby zachować ciągłość. A im wcześniej się zacznie, tym mniejsze ryzyko, że przejście zbiegnie się z incydentem albo krytycznym terminem biznesowym. W tym artykule porządkujemy stan faktyczny, mapujemy obszary funkcjonalne i proponujemy plan przygotowań.

‍

Status decommissioningu: co już przeniesiono, co jeszcze działa

Fundament zmiany jest już dostarczony: Unified Admin Experience. Przeniesienie funkcjonalności LCS-owych do Power Platform Admin Center. Zostało wypuszczone w trybie ogólnej dostępności (GA). To zmienia charakter rozmowy: nie dyskutujemy o zapowiedzi, lecz o działającym rozwiązaniu, które Microsoft rozwija jako docelowe. Równolegle wskazywane są kolejne terminy routingu nowych klientów bezpośrednio do PPAC. Nowe wdrożenia będą omijać LCS, przez co baza jego użytkowników zacznie się naturalnie kurczyć, a wraz z nią priorytet utrzymywania starej platformy. Daty finalnego wyłączenia bywały korygowane. Jak wiele elementów szerszego programu One Dynamics One Platform. Ale korekta terminu to nie zmiana kierunku. Rozsądne planowanie zakłada, że LCS zniknie; niepewna jest tylko data, a nie zdarzenie.

‍

Mapa obszarów: co przenosi się z LCS do PPAC

Zamiast wyliczać pojedyncze ekrany, warto spojrzeć na trzy obszary kompetencji, które zespół administracyjny musi „przemapować” na nowe środowisko.

Zarządzanie środowiskami

Pierwszy i najważniejszy obszar to cykl życia środowisk: ich tworzenie, konfiguracja, refreshe baz danych, przywracanie z backupu. To operacje, od których zależy zarówno codzienna praca zespołów projektowych, jak i reagowanie na incydenty. Dlatego właśnie od nich należy zacząć naukę nowego środowiska. Dobra wiadomość jest taka, że PPAC jest wspólnym centrum administracyjnym całej Power Platform, więc kompetencje zdobyte przy F&O procentują też przy pozostałych aplikacjach w tenancie.

Monitoring i diagnostyka

Drugi obszar to obserwowalność: stan środowisk, diagnostyka problemów, dostęp do informacji potrzebnych przy analizie incydentów. Tu różnice w filozofii narzędzi bywają najbardziej odczuwalne w codziennej pracy. Dlatego warto przećwiczyć scenariusze diagnostyczne na spokojnie, zanim trzeba będzie je wykonywać pod presją awarii.

Elementy licencyjne i capacity

Trzeci obszar jest w kontekście naszego cyklu szczególnie istotny: PPAC to miejsce, w którym widać należną i konsumowaną pojemność Database Storage Capacity tenanta, z rozbiciem na środowiska. Dostęp do tych widoków wymaga uprawnień do przeglądania elementów licencyjnych. I to jest pierwsza praktyczna rzecz do załatwienia, bo bez niej zespół nie zobaczy ani stanu konsumpcji, ani nadchodzących problemów.

‍

Luki i braki: czego w PPAC jeszcze nie ma i jak z tym żyć

Popularne jest stwierdzenie o brakach występujących w nowym środowisku administracyjnym. I nie należy go ani ignorować, ani wyolbrzymiać. Część funkcjonalności LCS ma już pełne odpowiedniki, część jest uzupełniana z kolejnymi wydaniami, a status GA oznacza zobowiązanie Microsoftu do domknięcia całości. Praktyczna rada brzmi: zamiast oceniać PPAC w abstrakcji, należy ocenić go względem własnej listy operacji. Jeżeli konkretny proces zespołu opiera się o funkcję, której odpowiednika jeszcze nie ma, to jest to informacja planistyczna. Proces trzeba będzie przeprojektować albo zaplanować jego migrację na później, gdy funkcja się pojawi. Właśnie dlatego inwentaryzacja własnych procesów (o której niżej) jest ważniejsza niż jakakolwiek ogólna recenzja nowej platformy.

‍

Plan przygotowań dla administratora

Migrację administracyjną można rozłożyć na trzy uporządkowane kroki. Żaden nie wymaga czekania na oficjalne terminy.

Krok 1: audyt uprawnień w tenancie

Punkt wyjścia to odpowiedź na pytanie, kto po stronie organizacji ma dziś dostęp do PPAC i w jakich rolach. W tym kto ma uprawnienia do przeglądania elementów licencyjnych. W wielu organizacjach uprawnienia do nowego centrum nigdy nie były świadomie nadawane, bo „wszystko robiło się w LCS”. Uporządkowanie ról teraz oznacza, że w dniu, w którym LCS przestanie być opcją, nikt nie będzie blokował operacji czekaniem na dostępy.

Krok 2: inwentaryzacja procesów opartych o LCS

Drugi krok to spisanie wszystkich procesów zespołu, które dotykają LCS: refreshe środowisk testowych po kopii produkcji, pipeline'y wdrożeniowe, procedury przywracania, cykliczne czynności utrzymaniowe. Dla każdego procesu należy wskazać odpowiednik w PPAC albo oznaczyć go jako wymagający przeprojektowania. Szczególną uwagę warto poświęcić automatyzacjom. Na przykład pipeline'om w Azure DevOps powiązanym z odświeżaniem baz. Bo to one najłatwiej „pękają” po cichu przy zmianie platformy administracyjnej.

Krok 3: harmonogram przejścia bez przerwania ciągłości

Trzeci krok to przejście w praktyce: wykonywanie kolejnych kategorii operacji w PPAC równolegle z LCS, zaczynając od czynności niskiego ryzyka, a kończąc na krytycznych. Taki tryb równoległy pozwala zespołowi zbudować wprawę i wychwycić różnice zachowań, zanim stary kanał zniknie. I to jest sedno przygotowania: w dniu wyłączenia LCS nie powinno się wydarzyć nic nowego, bo wszystko powinno już działać po nowemu.

‍

Dlaczego migracja to dobry moment na przegląd storage

Na koniec argument praktyczny. Skoro zespół i tak wchodzi do PPAC, porządkuje uprawnienia i inwentaryzuje środowiska. To jest najtańszy możliwy moment, aby przy okazji odpowiedzieć na pytanie o konsumpcję pojemności. Widok licencyjny w PPAC zestawia należne i konsumowane capacity w kwadrans, a inwentaryzacja środowisk, wykonywana i tak na potrzeby migracji, naturalnie ujawnia sandboxy istniejące „na wszelki wypadek”. Czyli głównych cichych konsumentów wspólnego limitu tenanta. Połączenie obu tematów w jeden przegląd oznacza, że organizacja wychodzi z migracji nie tylko z nową platformą administracyjną, ale i z wiedzą o swojej ekspozycji finansowej zanim zasady jej egzekwowania się zaostrzą.

‍

‍

‍