Migracja danych Dynamics 365 do chmury budzi u architektów systemowych jeden konkretny strach: utratę dorobku, który zespół budował latami. Niestandardowe encje, pluginy .NET, klasyczne workflows i integracje z systemem ERP to często osiem lat pracy, której nikt nie chce stracić w jednym projekcie. Ten strach jest częściowo uzasadniony, ponieważ nie każdy komponent przenosi się jeden do jednego. Nasi konsultanci podczas audytów migracyjnych widzą jednak powtarzalny wzorzec: większość customizacji trafia do chmury bez zmian, część wymaga refaktoryzacji, a tylko ułamek trzeba przepisać. W tym artykule pokazujemy dokładną mapę tego podziału na bazie sześciu realnych migracji, żebyś mógł zaplanować migrację Dynamics 365 on-premise do chmury i ocenić, co stanie się z każdą kategorią Twoich rozszerzeń w Dynamics 365 Sales.
Decyzja o migracji rzadko zatrzymuje się na argumentach finansowych czy regulacyjnych. Zatrzymuje się na pytaniu architekta: co stanie się z kodem, który pisaliśmy przez lata. Często identyfikujemy ten strach jako realną przyczynę odkładania projektu, nawet w organizacjach, które już policzyły koszt zwlekania i wiedzą, dlaczego dalsze utrzymanie środowiska on-premise stało się decyzją o ryzyku regulacyjnym i operacyjnym. Trzy scenariusze poniżej pokazują, skąd ten strach się bierze i dlaczego w większości przypadków jest większy niż faktyczna skala pracy.
Nasi konsultanci podczas audytów migracyjnych najczęściej spotykają środowiska Dynamics CRM rozbudowywane nieprzerwanie od wdrożenia w 2016 lub 2017 roku. Przez ten czas powstają dziesiątki pluginów .NET, setki klasycznych workflows i niestandardowe encje obsługujące procesy, których nie ma w standardzie produktu. Każdy z tych komponentów rozwiązywał realny problem biznesowy w momencie powstania, dlatego zespół traktuje je jako dorobek, nie jako dług. Strach przed migracją danych Dynamics 365 do chmury bierze się stąd, że wygląda ona jak ryzyko zresetowania całej tej pracy w jednym projekcie.
W rzeczywistości reset całego środowiska to scenariusz, który spotykamy najrzadziej. Większość pluginów obsługujących logikę biznesową, walidacje i automatyzacje pól przenosi się do chmury bez zmiany kodu, ponieważ model rozszerzeń Dynamics 365 pozostał spójny między wersją on-premise a chmurową.
Problem nie polega więc na utracie dorobku, ale na braku wiedzy, które konkretnie komponenty wymagają uwagi. Bez tej wiedzy całe środowisko wygląda na zagrożone, choć faktyczne ryzyko dotyczy zwykle kilkunastu procent rozszerzeń.
Drugi scenariusz dotyczy komponentów, które na on-premise korzystają z bezpośredniego dostępu do bazy SQL Server. Często identyfikujemy pluginy i konektory do systemu ERP, które odpytują tabele SQL wprost lub zapisują dane z pominięciem standardowego Web API. To rozwiązanie działało lokalnie, ponieważ baza i aplikacja były w tym samym środowisku. W Dynamics 365 Cloud bezpośredni dostęp do SQL jest ograniczony, dlatego właśnie te integracje wymagają zmiany podejścia, nie zaś automatycznego przeniesienia.
Ta kategoria budzi największy niepokój architektów, ponieważ integracja z systemem ERP zwykle obsługuje proces krytyczny, na przykład synchronizację faktur albo statusów zamówień. Awaria takiej integracji podczas migracji oznaczałaby realną przerwę operacyjną.
Mechanizm rozwiązania jest jednak znany i powtarzalny: bezpośredni dostęp do SQL zastępuje się wywołaniem przez Dataverse, a logikę przenosi się do warstwy, która w chmurze odpowiada za integracje. Efektem jest komponent stabilniejszy niż pierwotny, ponieważ przestaje zależeć od struktury bazy, która i tak zmienia się przy każdej aktualizacji.
Trzeci scenariusz jest najbardziej kosztotwórczy, choć na pierwszy rzut oka wygląda niewinnie. Podczas pierwszych rozmów klient zwykle deklaruje, że ma może dziesięć pluginów i kilkanaście workflows. Na projektach wdrożeniowych nauczyliśmy się, że deklaracja i rzeczywistość rozjeżdżają się o rząd wielkości, ponieważ przez lata customizacje dokładali różni dostawcy, a dokumentacja rzadko nadążała za zmianami. Skutkiem jest wycena migracji oparta na założeniach zamiast na danych, co prowadzi wprost do przekroczenia budżetu i terminu.
Różnica między deklaracją a inwentarzem nie wynika ze złej woli, lecz z natury środowiska, które rosło organicznie. Workflow dodany na potrzeby jednego działu trzy lata temu nadal działa w tle i nikt o nim nie pamięta, dopóki narzędzie inwentaryzacyjne go nie wykryje.
Implikacja dla decydenta jest prosta: realny business case migracji powstaje dopiero po inwentaryzacji, a nie przed nią. Każda liczba podana wcześniej jest prognozą, a nie wyceną, i traktowanie jej jak wyceny jest najczęstszą przyczyną rozjazdu projektu.
Diagnoza strachu z poprzedniej sekcji prowadzi do pytania, na które architekt potrzebuje konkretnej odpowiedzi: co dokładnie stanie się z każdą kategorią rozszerzeń. Nasi konsultanci po sześciu migracjach środowisk produkcyjnych widzą powtarzalny podział na trzy grupy komponentów. Około sześćdziesiąt do osiemdziesięciu procent przenosi się bezpośrednio, piętnaście do dwudziestu pięciu procent wymaga refaktoryzacji, a pięć do piętnastu procent trzeba przepisać lub zastąpić. Te trzy liczby są szkieletem całego business case migracji danych Dynamics 365 do chmury, ponieważ od nich zależy nakład pracy i harmonogram projektu.
Często identyfikujemy największą grupę komponentów jako tę, która przenosi się do chmury bez zmiany. Niestandardowe encje, pola, relacje, formularze, widoki i większość klasycznych workflows opierają się na modelu metadanych, który jest wspólny dla wersji on-premise i chmurowej. Po migracji te elementy działają w Dynamics 365 Sales tak samo jak wcześniej, ponieważ nie dotykają warstwy, która zmieniła się między platformami. To właśnie ta grupa odpowiada za uczucie ulgi, które obserwujemy u zespołów po pierwszym dniu inwentaryzacji.
Bezpośrednia migracja nie oznacza, że komponent zostaje skopiowany w niezmienionej formie. Oznacza, że jego logika i konfiguracja działają bez przepisywania kodu, choć zostają osadzone w nowym środowisku rozwiązania i objęte modelem zarządzania chmurowego.
Dla architekta praktyczna konsekwencja jest taka, że większość pracy wykonanej przez lata zachowuje swoją wartość. Im wyższy udział tej grupy w Twoim środowisku, tym tańszy i krótszy projekt migracji, co inwentarz pokazuje już w pierwszym tygodniu.
Druga grupa to komponenty, które działają poprawnie, ale w chmurze powinny opierać się na innej technologii. Refaktoryzacja oznacza tu zachowanie funkcji biznesowej przy zmianie sposobu jej realizacji. Najczęściej dotyczy to klasycznych workflows, które warto przenieść do Power Automate, oraz pluginów korzystających z bezpośredniego dostępu do SQL Server. Po migracji ten zakres często domykamy w ramach optymalizacji Dynamics 365, ponieważ refaktoryzacja jest dobrym momentem na uproszczenie logiki, która narastała latami.
Refaktoryzacja budzi obawę o czas, ale zwykle jest tańsza, niż wygląda. Logika biznesowa workflow zostaje ta sama, zmienia się narzędzie, które ją wykonuje, a Power Automate odwzorowuje większość wzorców klasycznych workflows gotowymi akcjami.
Korzyść wykracza poza samą migrację. Przeniesiona logika staje się łatwiejsza w utrzymaniu, ponieważ zespół konfiguruje ją wizualnie zamiast utrzymywać kod, a każda przyszła zmiana procesu nie wymaga już dewelopera.
Trzecia grupa jest najmniejsza, ale wymaga najwięcej uwagi architektonicznej. Widzimy częsty problem komponentów, które na on-premise rozwiązywały lukę w funkcjonalności produktu, a w chmurze ta luka już nie istnieje, ponieważ Microsoft dodał natywny odpowiednik. Inne komponenty są tak mocno związane z lokalną infrastrukturą, że ich przeniesienie nie ma sensu, a tańszym kierunkiem jest zastąpienie ich dedykowanym rozwiązaniem opartym na aplikacji Microsoft tworzonej na zamówienie lub funkcją Azure.
Przepisanie komponentu brzmi jak strata, ale w praktyce często jest najlepszą wiadomością z całego inwentarza. Oznacza, że proces, który przez lata wymagał własnego kodu, ma teraz odpowiednik dostępny w standardzie platformy lub w usłudze chmurowej.
Decyzja w tej grupie zawsze jest indywidualna i wynika z trzech parametrów komponentu, które opisujemy w kolejnej sekcji. Bez tej analizy łatwo przepisać coś, co dało się zachować, albo zachować coś, co taniej było zastąpić.
Podział na trzy grupy komponentów odpowiada na pytanie, co się przenosi. Pozostaje pytanie, ile to kosztuje, a na nie nie da się odpowiedzieć bez inwentarza. Postrzeganie refaktoryzacji wyłącznie przez pryzmat dodatkowego kosztu jest częstym błędem strategicznym, który spotykamy w organizacjach budujących business case migracji danych Dynamics 365 do chmury. Podczas konsultacji często wskazujemy na to, że koszt refaktoryzacji jest policzalny dopiero wtedy, gdy każdy komponent zostanie sklasyfikowany według trzech parametrów, a sam inwentarz zwraca się szybciej niż jakakolwiek inna faza projektu.
Nasi architekci systemowi podkreślają, że wycena migracji nie wynika z liczby komponentów, lecz z ich klasyfikacji. Każdy plugin, workflow i integracja dostaje odpowiedź na trzy pytania: czy jest aktywny, czy obsługuje proces krytyczny i czy ma natywny odpowiednik w chmurze. Komponent nieaktywny znika z zakresu projektu, co od razu obniża wycenę. Komponent aktywny, ale z natywnym odpowiednikiem trafia do grupy do zastąpienia, a nie do przepisania. Dopiero komponent aktywny, krytyczny i bez odpowiednika wymaga rzeczywistej pracy refaktoryzacyjnej.
Ta klasyfikacja jest powodem, dla którego dwa środowiska z tą samą liczbą pluginów mogą mieć zupełnie różną wycenę migracji. Liczy się nie ilość, ale udział komponentów wymagających pracy, a ten ujawnia się dopiero po przejściu trzech parametrów.
Dla decydenta oznacza to, że pierwsza rozmowa o cenie migracji bez inwentarza jest przedwczesna. Realna liczba pojawia się po klasyfikacji, a różnica między prognozą a wyceną potrafi sięgać kilkudziesięciu procent.
Często identyfikujemy brak rzetelnego inwentarza jako najczęstszą przyczynę przekroczenia budżetu i terminu migracji. Mechanizm jest prosty: wycena oparta na deklaracji zakłada mniejszą liczbę komponentów wymagających pracy, niż ujawnia rzeczywistość. Gdy w trakcie projektu pojawiają się workflows i pluginy, o których nikt nie pamiętał, zakres rośnie, a wraz z nim koszt i harmonogram. Inwentarz odwraca tę kolejność, ponieważ ujawnia pełen zakres przed podpisaniem umowy, a nie w jej trakcie.
Doświadczenie z sześciu migracji pokazuje, że różnica między oszacowaniem własnym klienta a rzeczywistym zakresem regularnie sięga kilkudziesięciu procent, zawsze w stronę niedoszacowania. To nie jest wyjątek, lecz reguła środowisk rosnących organicznie przez wiele lat.
Inwentarz przeprowadzony przed wyceną zamienia tę niepewność w policzalny zakres. Dlatego traktujemy go jako pierwszy etap dający zwrot, a nie jako koszt wstępny, ponieważ chroni cały budżet projektu przed rozjazdem.
Refaktoryzacja przy migracji ma drugą stronę, której decydenci zwykle nie biorą pod uwagę. Każdy komponent przenoszony z on-premise jest okazją do oceny, czy nadal odpowiada na aktualny proces biznesowy. Część workflows i pluginów obsługuje procedury, które zmieniły się przez lata, a kod został przy starej wersji. Migracja jest jedynym momentem, w którym ten dług technologiczny da się spłacić bez osobnego projektu, ponieważ komponent i tak przechodzi przez ręce architekta.
Ważne: refaktoryzacja generuje koszt, którego nie ma przy migracji bezpośredniej, ale warto liczyć go w kontekście tego, co eliminuje, czyli utrzymania kodu, którego zespół nie chce już rozwijać. Dokładny udział każdej z trzech grup w Twoim środowisku oraz wycenę refaktoryzacji przygotowujemy indywidualnie podczas bezpłatnego Audytu Migracyjnego, którego wynikiem jest inwentarz z klasyfikacją komponentów i planem dla każdej kategorii.
Spłata długu technologicznego przy okazji migracji jest tańsza niż osobny projekt porządkowy, ponieważ nie wymaga ponownego wdrażania zespołu w kontekst komponentu. Architekt analizuje go raz, na potrzeby migracji, i przy tej samej okazji decyduje o uproszczeniu.
Efektem jest środowisko po migracji lżejsze niż przed nią, ponieważ nieaktywne komponenty zostały odcięte, a logika narosła przez lata została uproszczona. To korzyść, której nie widać w arkuszu wyceny, ale którą zespół odczuwa od pierwszych tygodni pracy w chmurze.
Klasyfikacja komponentów daje obraz zakresu, ale architekt potrzebuje wiedzieć, co dokładnie dzieje się z kodem na każdej z trzech ścieżek. Nasi architekci systemowi podkreślają, że poprawne rozpoznanie mechanizmu technicznego decyduje o tym, czy refaktoryzacja zamknie się w przewidzianym czasie. Trzy obszary mają tu kluczowe znaczenie: pluginy .NET, klasyczne workflows oraz warstwa danych, na której opiera się cała migracja danych Dynamics 365 do chmury. Każdy z nich ma własną logikę przenoszenia i własne granice odwzorowania jeden do jednego.
Często identyfikujemy pluginy .NET jako komponent, który budzi największy niepokój, a okazuje się najprostszy. Plugin operujący na danych przez standardowy model rozszerzeń Dynamics 365, czyli reagujący na zdarzenia rekordów i modyfikujący pola, przenosi się do chmury bez przepisywania kodu, ponieważ ten model pozostał spójny między platformami. Refaktoryzacji wymagają dopiero pluginy korzystające z bezpośredniego dostępu do SQL Server lub z zasobów lokalnego serwera, których w chmurze nie ma. Te przenosi się na Azure Functions, gdzie logika działa jako usługa wywoływana przez Dataverse.
Granica przebiega więc nie po samym pluginie, ale po tym, czego on dotyka. Plugin zamknięty w modelu danych Dynamics 365 jest bezpieczny. Plugin sięgający poza ten model, do bazy SQL albo do plików na serwerze, wymaga przeniesienia tej części logiki na usługę chmurową.
Dla zespołu praktyczna konsekwencja jest taka, że nie trzeba przepisywać całego pluginu, lecz wydzielić fragment sięgający poza platformę. Reszta kodu zostaje, co znacząco skraca pracę w porównaniu z przepisaniem komponentu od zera.
Drugi obszar to klasyczne workflows, które w chmurze warto przenieść do Power Automate. Na projektach wdrożeniowych nauczyliśmy się, że większość wzorców klasycznych workflows ma gotowy odpowiednik w postaci akcji Power Automate, dlatego ich przeniesienie jest konfiguracją, a nie programowaniem. Granica odwzorowania jeden do jednego pojawia się przy workflows wywołujących własny kod lub zależnych od kolejności wykonania w obrębie transakcji, ponieważ Power Automate działa w innym modelu wykonania. Te fragmenty rozdziela się na akcję konfiguracyjną i wydzieloną logikę.
Najczęstszy błąd na tym etapie to założenie, że każdy workflow przeniesie się bez zmian, albo odwrotnie, że żaden się nie przeniesie. Prawda leży pośrodku i wynika z analizy konkretnego workflow, nie z ogólnej reguły.
Korzyść z przeniesienia do Power Automate wykracza poza migrację. Proces staje się czytelny dla zespołu biznesowego, który może go modyfikować bez angażowania dewelopera, co obniża koszt utrzymania w każdym kolejnym roku.
Trzeci obszar to warstwa danych, na której opiera się różnica między platformami. On-premise przechowuje dane w bazie SQL Server z dostępem przez Web API oraz bezpośrednio przez SQL. Dynamics 365 Cloud opiera się na Dataverse, wspólnej warstwie danych dla aplikacji Microsoft. Tu konieczne jest precyzyjne rozróżnienie, które często bywa upraszczane. Natywnie wyłącznie funkcje sztucznej inteligencji i Microsoft Copilot dla Dynamics 365 wymagają Dataverse i nie uruchomią się na żadnej ścieżce poza chmurą, co opisujemy szerzej w kontekście ekosystemu AI niedostępnego dla wersji on-premise.
Power Automate, Power Apps i Power BI potrafią pracować z danymi z on-premise CRM, ale wymagają wtedy dodatkowej warstwy, najczęściej On-Premises Data Gateway, oraz akceptacji ograniczeń wydajnościowych i funkcjonalnych w porównaniu z natywną pracą na Dataverse. To istotne, ponieważ zależność od Dataverse dotyczy natywnie tylko warstwy AI, a nie całego Power Platform.
Dla architekta wniosek jest praktyczny. Migracja na Dataverse nie jest warunkiem korzystania z Power Platform, ale jest warunkiem korzystania z niego bez dodatkowej warstwy integracyjnej i bez ograniczeń, które ta warstwa wprowadza. Pełną ocenę tej zależności w Twoim środowisku przygotowujemy w ramach projektu migracji Dynamics 365 do chmury.
Wiedza o tym, co przenosi się bezpośrednio, co wymaga refaktoryzacji, a co przepisania, prowadzi do jednego pytania operacyjnego: od czego zacząć. Nasi konsultanci podczas spotkań z architektami i sponsorami projektów regularnie wskazują na ten sam wzorzec. Migracja danych Dynamics 365 do chmury nie zaczyna się od przenoszenia komponentów, lecz od decyzji o inwentaryzacji, ponieważ to ona zamienia strach przed utratą dorobku w policzalny plan dla każdej kategorii rozszerzeń.
Decyzja o starcie inwentaryzacji nie wymaga spełnienia wszystkich warunków jednocześnie. Wystarczą trzy z pięciu poniższych sygnałów, żeby audyt customizacji miał sens biznesowy. Pierwszym sygnałem jest sytuacja, w której nikt w zespole nie potrafi podać dokładnej liczby aktywnych pluginów i workflows, co oznacza, że środowisko rosło szybciej niż dokumentacja. Drugim sygnałem jest obecność integracji z systemem ERP opartej na bezpośrednim dostępie do SQL Server, ponieważ to ona najczęściej wymaga zmiany podejścia w chmurze. Trzecim sygnałem jest zatwierdzony przez zarząd plan wykorzystania sztucznej inteligencji lub Copilota w sprzedaży albo obsłudze, którego nie da się zrealizować bez warstwy Dataverse. Czwartym sygnałem jest rosnący koszt utrzymania komponentów, których nikt nie chce już rozwijać, a które nadal wymagają uwagi dewelopera. Piątym sygnałem jest planowana zmiana w procesie biznesowym, która i tak wymusi modyfikację istniejących workflows, co czyni migrację naturalnym momentem na ich uporządkowanie.
Każdy z tych sygnałów osobno wygląda na problem jednego zespołu lub jednego komponentu. Razem stają się argumentem za inwentaryzacją, ponieważ pokazują, że środowisko przekroczyło próg, powyżej którego ręczne panowanie nad customizacjami przestaje być możliwe.
Próg trzech sygnałów nie jest przypadkowy. To granica, powyżej której koszt braku wiedzy o własnym środowisku zaczyna przewyższać koszt jej zdobycia, a inwentaryzacja przestaje być opcją, a staje się warunkiem racjonalnej wyceny.
Inwentaryzacja jest pierwszym etapem, ale nie jedynym, w którym rola partnera wdrożeniowego jest decydująca. Po inwentarzu następuje klasyfikacja każdego komponentu według trzech parametrów, a po niej projekt migracji, w którym dane, encje i formularze przenoszą się bezpośrednio, workflows trafiają do Power Automate, a pluginy sięgające poza model danych na Azure Functions. Ostatnim etapem jest optymalizacja Dynamics 365 po migracji, podczas której dostrajamy przeniesione komponenty i uruchamiamy funkcje niedostępne wcześniej na on-premise.
Migracja danych Dynamics 365 do chmury bez utraty customizacji nie jest pytaniem o to, czy zachowasz dorobek zespołu, lecz o to, ile z niego wymaga uwagi — a tę liczbę daje wyłącznie inwentarz. Pierwszym krokiem, który możesz wykonać w ciągu najbliższych dwóch tygodni, jest umówienie audytu, którego wynikiem jest klasyfikacja każdego komponentu i plan dla trzech grup, zanim podejmiesz jakąkolwiek decyzję o zakresie i koszcie projektu.
W tej sekwencji rola partnera jest najbardziej widoczna na początku i na końcu. Inwentarz wymaga doświadczenia w rozpoznawaniu komponentów, które wyglądają na proste, a kryją zależność od lokalnej infrastruktury. Optymalizacja po go-live wymaga znajomości funkcji platformy, które dopiero teraz wchodzą do codziennej pracy zespołu. Pełny zakres projektu migracji omawiamy podczas migracji Dynamics 365 on-premise do chmury, a pierwszą ocenę gotowości środowiska w trakcie bezpłatnego Audytu Migracyjnego.
Sześć pytań, które najczęściej zadają architekci i sponsorzy projektów planujący migrację danych Dynamics 365 do chmury bez utraty pracy własnego zespołu.
Podczas Audytu Migracyjnego architekt ARP Ideas inwentaryzuje Twoje pluginy, workflows i integracje, klasyfikuje każdy komponent według ścieżki migracji i pokazuje, ile z Twojego dorobku przenosi się bezpośrednio, a ile wymaga uwagi. Bez zobowiązań i bez presji decyzji.
Ocena gotowości środowiska w 30-minutowej rozmowie
Od lat łączy analizę biznesowo-systemową z projektowaniem rozwiązań idealnie dopasowanych do potrzeb klienta. Prowadził liczne wdrożenia Dynamics 365 CRM, SharePoint oraz aplikacji niestandardowych. Pasjonat nowych technologii i AI, którym interesuje się od 2019 (zanim to było modne). W ARP Ideas odpowiada za rozwój standardów pracy konsultantów i usprawnienia organizacyjne.
