Migracja Dynamics CRM on-premise do chmury w 2026 roku przestała być decyzją technologiczną i stała się decyzją o ryzyku. Mainstream support dla Dynamics CRM 2015–2017 się zakończył, dyrektywa NIS2 i rozporządzenie DORA podnoszą wymagania wobec systemów przetwarzających dane klientów, a koszt utrzymania własnej infrastruktury rośnie szybciej niż abonament chmurowy. Pytanie, które słyszymy podczas audytów, nie brzmi już „czy migrować", tylko „kiedy zacząć, żeby nie zacząć za późno". W tym artykule pokazujemy, dlaczego dalsze odkładanie tej decyzji jest dziś droższe niż sam projekt migracji, jakie ryzyka regulacyjne, kosztowe i operacyjne się kumulują, oraz jak rozpocząć migrację Dynamics CRM on-premise do chmury w sposób, który da się obronić przed zarządem.
Jeszcze dwa lata temu utrzymanie Dynamics CRM 2015–2017 on-premise było racjonalnym kompromisem. System działał, zespół go znał, inwestycja w infrastrukturę i licencje została już zamortyzowana. Nasi konsultanci podczas audytów migracyjnych w 2025 i 2026 roku obserwują jednak zmianę, której nie da się dłużej ignorować. Trzy sygnały, które wcześniej pojawiały się sporadycznie, dziś występują równocześnie w niemal każdej średniej i dużej organizacji B2B działającej na legacy CRM. Nie chodzi o technologię, ale o zmianę otoczenia regulacyjnego, rynkowego i kosztowego, w którym ten system pracuje.
Pierwszym sygnałem, który pojawia się w rozmowach z dyrektorami IT, jest pytanie z działu compliance: czy Wasz CRM jest zgodny z NIS2 i DORA? Dyrektywa NIS2 (Network and Information Security Directive 2) obowiązuje w Polsce od października 2024 i obejmuje firmy średnie oraz duże w sektorach uznanych za kluczowe lub ważne dla gospodarki. Rozporządzenie DORA (Digital Operational Resilience Act) wprowadziło od stycznia 2025 dodatkowe wymagania dla sektora finansowego i jego dostawców usług ICT. Oba akty wymagają udokumentowanej oceny ryzyka systemów przetwarzających dane klientów oraz zarządzania podatnościami w cyklu life-cycle dostawcy.
Dynamics CRM 2015 i 2016 są poza mainstream support Microsoft od kilku lat, a Dynamics CRM 2017 (czyli Dynamics 365 Customer Engagement on-premise w pierwszej wersji) zbliża się do końca extended support. W praktyce oznacza to, że nowe luki bezpieczeństwa publikowane w bazach CVE nie są dla tych wersji łatane. Audytor compliance nie pyta, czy system działa. Pyta, kiedy ostatnio została zainstalowana łatka bezpieczeństwa i kto odpowiada za zarządzanie podatnościami. Na on-premise Dynamics CRM 2016 odpowiedź na to drugie pytanie brzmi: nikt, ponieważ producent już tego nie robi.
W praktyce każdy audyt compliance, który dotyka systemu CRM przetwarzającego dane osobowe klientów, kończy się tym samym wnioskiem: brak aktualnych patchy bezpieczeństwa = wymagana decyzja o rekompensacji ryzyka. Rekompensacja może oznaczać izolację sieciową, dodatkowe ubezpieczenie cyber albo plan migracji w określonym terminie.
Każdy z tych scenariuszy generuje koszt, którego nie było w pierwotnym budżecie utrzymania CRM. Bez planu migracji rozliczanie się z audytów staje się stałą pozycją operacyjną, a nie incydentalną.
Drugi sygnał pochodzi z miejsca, którego dział IT zwykle się nie spodziewa: od zespołu sprzedaży. Handlowcy w Twojej firmie obserwują na LinkedIn i konferencjach branżowych, że konkurencja używa Microsoft Copilot do generowania podsumowań spotkań, draftowania ofert i predykcji szans sprzedażowych. Pytanie, które trafia do dyrektora sprzedaży, a stamtąd do dyrektora IT, brzmi prosto: dlaczego my tego nie mamy?
Odpowiedź techniczna brzmi: Microsoft Copilot for Sales i Copilot wbudowany w Dynamics 365 nie działają na on-premise. To nie jest decyzja produktowa, którą można obejść, lecz konsekwencja architektury. Copilot wymaga Dataverse (warstwy danych Microsoft Cloud), modeli językowych hostowanych w Azure i integracji z Microsoft Graph. Żaden z tych komponentów nie jest dostępny w wersji on-premise CRM. Często identyfikujemy sytuację, w której dyrektor IT po raz pierwszy słyszy o tym ograniczeniu wtedy, gdy zarząd już zatwierdził budżet na „wdrożenie AI w sprzedaży".
Dla zespołu sprzedaży brak Copilot oznacza godziny tygodniowo na czynnościach, które konkurencja oddała AI. Draftowanie maili po spotkaniach, podsumowania rozmów telefonicznych, ocena szans w pipeline, wszystko ręcznie. To nie jest tylko koszt produktywności; to różnica w prędkości reakcji na zapytania ofertowe.
W ostatnich projektach widzimy, że firmy używające Copilot raportują 20–25% więcej czasu handlowca na pracę z klientem, ponieważ administracja CRM dzieje się w tle. Dla on-premise CRM ta ścieżka rozwoju jest zamknięta.
Trzeci sygnał ma najbardziej finansowy charakter i często to on przekonuje CFO szybciej niż dwa pozostałe. Serwery, na których działa Dynamics CRM wdrożony w 2017 lub 2018 roku, są dziś po cyklu odpisów amortyzacyjnych i wchodzą w okres, w którym ich wymiana lub leasing kolejnej generacji to wydatek inwestycyjny porównywalny z 2–3-letnim abonamentem chmurowym. Do tego dochodzi koszt licencji Windows Server, SQL Server, backupu, monitoringu, a coraz częściej także third-party support, który zastępuje brak wsparcia Microsoft.
Na projektach wdrożeniowych nauczyliśmy się, że koszt utrzymania on-premise CRM rośnie nieliniowo. W trzecim i czwartym roku po zakończeniu mainstream support pojawiają się pozycje, których wcześniej nie było: stawki za godzinę pracy zewnętrznej firmy wsparcia rosną 15–20% rocznie, a ekipa wewnętrzna spędza coraz więcej czasu na obsłudze integracji, które wcześniej działały bez nadzoru. Część organizacji decyduje się w tym momencie na audyt i naprawę istniejącego wdrożenia Dynamics 365. Przy próbie modernizacji często okazuje się jednak, że ten kierunek pomaga tylko wtedy, gdy organizacja jest już w chmurze. Dla on-premise CRM diagnoza ARP Ideas najczęściej kończy się rekomendacją: migracja jest tańsza niż dalsze utrzymanie.
Najbardziej niedoceniana pozycja to czas zespołu IT. Każda godzina spędzona na utrzymaniu legacy CRM jest godziną nieprzeznaczoną na projekty rozwojowe. W organizacjach, które kompleksowo policzyły ten koszt podczas Analizy Gotowości do Migracji, okazywało się, że łączny TCO on-premise w 3-letnim oknie był wyższy od TCO chmury o 25–35%.
Co ważne, ta różnica rośnie z roku na rok, ponieważ abonament chmurowy jest przewidywalny, a koszty on-premise zaczynają eskalować szczególnie w trzecim roku po końcu wsparcia.
Trzy sygnały opisane wcześniej pokazują, dlaczego dalsze utrzymanie on-premise CRM kumuluje ryzyko. Drugą stroną tej samej decyzji jest pytanie, co konkretnie pojawia się w organizacji po migracji do Dynamics 365 Cloud, czego wcześniej nie było. Nasi konsultanci często wskazują na jeden ważny rozdzielnik: chmura nie jest „lepszą wersją tego samego CRM". To inna kategoria narzędzia, ponieważ działa w ekosystemie, którego on-premise nie ma dostępu. Trzy obszary tej różnicy mają największe znaczenie dla decydenta budującego business case dla zarządu.
Pierwszy obszar to natywna integracja z Microsoft Copilot, opisana wcześniej z perspektywy braku. Po migracji do Dynamics 365 Sales handlowiec otrzymuje Copilot jako element standardowego interfejsu pracy z szansą sprzedaży. System samodzielnie podsumowuje historię relacji z klientem przed spotkaniem, drafty maili powstają na bazie wcześniejszej korespondencji i notatek, a po rozmowie telefonicznej zapisanej w Teams Copilot generuje listę kolejnych kroków oraz aktualizację statusu szansy w pipeline.
W Dynamics 365 Customer Service Copilot pracuje analogicznie po stronie obsługi posprzedażowej. Agent otrzymuje sugerowane odpowiedzi na zgłoszenia, automatycznie generowane podsumowania case'ów przy eskalacji oraz wnioski wyciągnięte z bazy wiedzy. W ostatnich projektach widzimy, że organizacje, które uruchomiły Copilot w Customer Service, raportują redukcję średniego czasu obsługi zgłoszenia o 25–30% bez zmiany liczebności zespołu. Dla on-premise CRM nie istnieje ścieżka, która by ten wynik powtórzyła, i nie pojawi się, ponieważ Microsoft nie buduje już funkcji AI dla wersji on-premise.
Najbardziej mierzalna korzyść z Copilot pojawia się w pierwszych 90 dniach po uruchomieniu. Handlowcy odzyskują czas wcześniej spędzany na administracji CRM, a obsługa klienta domyka zgłoszenia szybciej, ponieważ rozwiązania z bazy wiedzy są sugerowane w czasie pisania odpowiedzi.
W skali roku przekłada się to na różnicę 20–25% w produktywności zespołu sprzedaży i porównywalną w obsłudze posprzedażowej, bez konieczności rekrutacji nowych osób.
Drugi obszar dotyczy integracji z resztą ekosystemu Microsoft. Na on-premise każda integracja z Outlookiem, Teams, SharePointem czy systemem ERP w chmurze wymaga dedykowanego kodu, konektora opartego o Web API CRM i utrzymania środowiska po stronie własnej infrastruktury. W Dynamics 365 Cloud te same integracje są dostępne natywnie przez Dataverse — warstwę danych, która jednocześnie obsługuje CRM, Power Apps, Power Automate i Power BI.
W praktyce oznacza to, że automatyzacja, która na on-premise wymagała 4–6 tygodni pracy developera, w Power Automate zajmuje 2–3 dni konfiguracji. Podgląd danych CRM w karcie kontaktu w Outlooku, automatyczne zapisywanie maili klientów w historii szansy, raport Power BI łączący dane CRM z systemem finansowym. To wszystko działa po migracji bez budowania własnych konektorów. Nasi architekci systemowi podkreślają, że dla działu IT to nie tylko oszczędność godzin developera, ale też przeniesienie kompetencji z utrzymania kodu na rozwój procesów biznesowych.
Różnica między on-premise a chmurą staje się szczególnie widoczna przy projektach automatyzacji procesów krzyżujących systemy. Integracja CRM z systemem fakturowym, systemem obsługi reklamacji albo zewnętrznym narzędziem marketing automation to w chmurze pytanie o godziny, nie o miesiące.
Power Platform daje również narzędzie do budowania własnych aplikacji bez developera. Workflow akceptacji oferty, ekran rejestracji zgłoszenia z poziomu klienta, własny panel handlowca, wszystko to działa na tej samej warstwie danych co CRM.
Trzeci obszar to bezpieczeństwo i compliance. W chmurze odpowiedzialność za infrastrukturę pod CRM przechodzi na Microsoft jako podmiot odpowiedzialny w rozumieniu NIS2 i DORA. Twoja organizacja nadal odpowiada za konfigurację dostępów, zarządzanie tożsamością i klasyfikację danych, ale infrastruktura, patchowanie warstwy systemu operacyjnego, ciągłość działania i fizyczne bezpieczeństwo centrum danych są elementem usługi.
Dynamics 365 Cloud działa w środowisku Azure, które utrzymuje certyfikacje ISO 27001, ISO 27018, SOC 1, SOC 2, SOC 3 oraz zgodność z RODO. Dla audytora compliance to nie jest argument marketingowy, ale konkretny zestaw raportów dostępnych w Microsoft Service Trust Portal, które stają się załącznikami do dokumentacji NIS2 i DORA. Patche bezpieczeństwa są wdrażane przez Microsoft w cyklu ciągłym, bez planowanych okien serwisowych po stronie klienta.
Dla dyrektora IT odpowiedzialnego za compliance najważniejszą zmianą jest model odpowiedzialności współdzielonej. Microsoft odpowiada za to, co dotyczy infrastruktury, hypervisora, systemów operacyjnych i warstwy aplikacyjnej Dynamics 365. Klient odpowiada za konfigurację ról, dane i integracje.
Ten podział redukuje zakres audytu po stronie klienta i przesuwa rozmowę z „czy mamy patche" na „czy mamy poprawnie skonfigurowane uprawnienia". Druga rozmowa jest łatwiejsza do wygrania niż pierwsza.
Postrzeganie migracji wyłącznie przez pryzmat kosztu projektu jest częstym błędem strategicznym, który spotykamy w organizacjach budujących business case dla zarządu. Pełny obraz wymaga porównania dwóch ścieżek finansowych w 3-letnim oknie: ścieżki utrzymania on-premise i ścieżki migracji do Dynamics 365 Cloud. Podczas konsultacji często wskazujemy na to, że pierwsza z nich zawiera kategorie kosztów, których nie ma w klasycznym arkuszu kalkulacyjnym IT, a druga ma policzalny zwrot widoczny od trzynastego miesiąca po go-live. Trzy elementy tego rachunku decydują o tym, czy projekt migracji zostanie zatwierdzony w pierwszym podejściu.
Standardowy arkusz porównawczy utrzymania CRM zawiera zwykle pozycje sprzętowe i licencyjne. Pomija cztery kategorie, które w trzecim roku stają się dominującą częścią TCO on-premise. Pierwsza to third-party support, którego stawki godzinowe firm specjalizujących się we wsparciu legacy CRM rosną 15–20% rocznie, a kontrakt na 3 lata zawiera klauzule eskalacyjne, których w pierwszym roku nie widać. Druga to godziny zespołu IT spędzane na utrzymaniu integracji i pluginów, których nikt nie aktualizuje, bo „działa". Trzecia to utracona produktywność handlowców i agentów obsługi, którzy nie mają dostępu do narzędzi AI dostępnych w chmurze. Czwarta to koszt opóźnienia projektów rozwojowych, które nie startują, bo zespół jest zajęty utrzymaniem CRM.
Drugi sposób liczenia kosztów, porównanie TCO third-party support z migracją do chmury w 3-letnim oknie, wymaga osobnego rozliczenia tych kategorii, ponieważ każda ma inną dynamikę narastania. Bez ich uwzględnienia rozmowa z CFO kończy się dyskusją o cenie abonamentu chmurowego, a nie o realnym koszcie całkowitym. W audytach migracyjnych przeprowadzonych w organizacjach średniej wielkości średnia różnica między oszacowaniem własnym klienta a rzeczywistym TCO on-premise wynosiła 35–45%, zawsze w kierunku niedoszacowania.
Najtrudniejsza do oszacowania pozycja to utracona produktywność, ponieważ nie ma jej w żadnym arkuszu. Liczy się ją porównawczo: ile czasu zajmuje obsługa typowego procesu w on-premise i ile zajęłaby z Copilot oraz Power Automate. Różnica pomnożona przez liczbę handlowców i koszt godziny pracy daje pozycję, która często przewyższa wszystkie pozostałe razem.
Druga pozycja, której często brakuje, to koszt opóźnienia projektów rozwojowych. Każdy nowy projekt biznesowy, który mógłby startować w chmurze w ciągu tygodni, na on-premise wymaga miesięcy. Ten czas to też pieniądz.
Drugi element rachunku to ryzyko regulacyjne, które do 2024 roku traktowano w business case'ach jako pozycję jakościową. Od momentu wejścia w życie NIS2 oraz DORA stało się pozycją kwotową. Maksymalna kara administracyjna z tytułu NIS2 dla podmiotów kluczowych wynosi 10 milionów euro lub 2% rocznego światowego obrotu (przyjmuje się wyższą z dwóch wartości). Dla podmiotów ważnych jest to odpowiednio 7 milionów euro lub 1,4% obrotu. DORA przewiduje analogiczne kary dla sektora finansowego oraz jego dostawców usług ICT, z dodatkową możliwością nałożenia środków naprawczych przez właściwy organ nadzoru.
Realny koszt nie kończy się jednak na potencjalnej karze. Do business case'u trzeba wpisać też koszt audytu po incydencie bezpieczeństwa, koszt powiadomienia klientów, koszt obsługi reputacyjnej, a coraz częściej także wzrost składki cyber-ubezpieczenia dla organizacji utrzymujących systemy bez aktualnych patchy. Ubezpieczyciele od 2025 roku wyceniają legacy CRM jako czynnik ryzyka i potrafią podnieść składkę o 30–50% lub odmówić ochrony konkretnego komponentu.
Ważne: Sama migracja do Dynamics 365 Cloud nie zwalnia organizacji z obowiązków NIS2 i DORA, ale przenosi część odpowiedzialności na Microsoft jako podmiot dostarczający infrastrukturę. Pełne porównanie zakresu odpowiedzialności i kosztu zgodności w obu modelach wymaga indywidualnej analizy. Tę analizę przygotowujemy podczas bezpłatnej Analizy Gotowości do Migracji, której wynikiem jest raport biznesowy zawierający wycenę projektu, TCO porównawcze i mapę ryzyka regulacyjnego.
Ryzyko regulacyjne ma jeszcze jeden wymiar, którego nie widać w arkuszu: czas reakcji audytora. NIS2 wymaga zgłoszenia incydentu istotnego w ciągu 24 godzin od jego wykrycia. Organizacja działająca na on-premise CRM bez aktualnych patchy nie jest w stanie udokumentować, że incydent nie był skutkiem znanej luki.
W Dynamics 365 Cloud cykl raportowania incydentów jest częścią umowy z Microsoft. Dla audytora to różnica między raportem 30-dniowym po incydencie a raportem na żądanie.
Trzeci element rachunku ma charakter dynamiczny i dotyczy tempa narastania kosztów w czasie. W pierwszym roku po zakończeniu mainstream support koszty utrzymania on-premise rosną stosunkowo wolno, ponieważ infrastruktura jeszcze działa, third-party support jest świeży, a zespół zna system. W drugim roku zaczynają się problemy: pierwsze podatności bez patchy, pierwsze integracje, które przestają działać po aktualizacji systemu zewnętrznego, pierwsze pytania od compliance.
Trzeci rok jest najdroższy, ponieważ kumulują się trzy czynniki jednocześnie. Sprzęt z 2017 wchodzi w okres awaryjności i wymaga wymiany. Third-party support eskaluje stawki o kolejne kilkanaście procent, ponieważ coraz mniej firm chce wspierać legacy CRM. Zespół IT zaczyna tracić kompetencje na temat starego systemu, bo nowi pracownicy uczą się chmury, a starzy odchodzą lub przesuwają się na inne projekty. Nasi konsultanci często identyfikują ten moment jako punkt, w którym koszt rocznego utrzymania on-premise przekracza koszt rocznego abonamentu Dynamics 365 Cloud, i to dwukrotnie.
Krzywa kosztu utrzymania on-premise jest wykładnicza, nie liniowa. Z każdym rokiem przybywa pozycji, których nie da się odzyskać, ponieważ wynikają z odejścia kompetencji, narastającego długu technologicznego i zmiany struktury rynku wsparcia. W trzecim roku CFO zaczyna widzieć w prognozie pozycje, których w pierwszym roku nikt nie planował.
Decyzja o migracji w pierwszym roku po końcu wsparcia jest najtańsza. W drugim roku jest droższa, ale nadal racjonalna. W trzecim roku staje się reaktywna, ponieważ wymusza ją incydent bezpieczeństwa, audyt compliance lub awaria infrastruktury.
Argumentacja regulacyjna i finansowa przedstawiona w poprzednich sekcjach jest tym, co zazwyczaj trafia do zarządu. Architekt systemowy potrzebuje jednak głębszego zrozumienia, co technicznie dzieje się z Dynamics CRM on-premise w 2026 roku, żeby ocenić skalę długu technologicznego i przygotować inwentarz środowiska przed projektem migracyjnym. Nasi architekci systemowi podkreślają, że poprawna ocena techniczna decyduje o tym, czy projekt zamknie się w przewidzianym budżecie i terminie. Trzy aspekty mają tu kluczowe znaczenie.
Microsoft Dynamics CRM 2015 zakończył mainstream support w styczniu 2021 i extended support w styczniu 2026. Dynamics CRM 2016 ma extended support do lipca 2026. Dynamics 365 Customer Engagement on-premise (wersja z 2017 roku) jest objęty modelem Modern Lifecycle Policy, który nie gwarantuje dokładnych dat, ale wymaga utrzymania bieżącej wersji, czego większość organizacji nie robi, ponieważ on-premise nie aktualizuje się automatycznie. W praktyce każda z tych wersji jest dziś poza okresem regularnych aktualizacji bezpieczeństwa.
Dług techniczny nie ogranicza się jednak do samego CRM. Wokół niego pracuje Windows Server (często 2012 R2 lub 2016, oba poza wsparciem), SQL Server (2014, 2016, czasem starszy) i Internet Information Services w wersji niezgodnej z nowoczesnymi standardami szyfrowania TLS. Każdy z tych komponentów ma własną listę CVE, którą trzeba osobno raportować audytorowi. Część organizacji, które dotychczas żyły bez incydentu, doszły do podobnych wniosków w trakcie audytu i naprawy istniejącego wdrożenia Dynamics 365. Przy próbie modernizacji okazywało się, że stos technologiczny utrzymujący CRM jest tak przestarzały, że dalsza praca nad on-premise traci sens biznesowy.
Najbardziej niedoceniany aspekt to kumulacja. Każdy z komponentów stosu osobno nie wygląda alarmująco, ale w sumie tworzą środowisko, którego nie da się obronić przed audytorem bezpieczeństwa. CRM 2016 + Windows Server 2012 R2 + SQL Server 2014 to trzy systemy bez wsparcia, działające w tym samym fizycznym środowisku, obsługujące dane klientów.
Migracja CRM do chmury automatycznie eliminuje dwa pierwsze elementy długu, ponieważ infrastruktura przechodzi na Microsoft. Zostaje SQL Server jeśli pozostaje na on-premise jako backend dla ERP, i tę pozycję trzeba zaplanować osobno.
Drugi techniczny aspekt to architektura warstwy danych. On-premise Dynamics CRM przechowuje dane w bazie SQL Server, do której dostęp odbywa się przez Web API CRM oraz bezpośrednio przez SQL (z ograniczeniami licencyjnymi). Dynamics 365 Cloud opiera się na Dataverse — warstwie danych, która jest wspólna dla CRM, Power Apps, Power Automate, Power BI i Microsoft Copilot Studio. To architektoniczna różnica, której nie da się obejść po stronie on-premise.
Konsekwencje są praktyczne. Każda nowa funkcja Microsoft, która rozwija się w Power Platform, omija on-premise. Modele AI Copilota, automatyzacja procesów cross-system w Power Automate, dashboardy łączące dane CRM z dowolnym innym źródłem w Power BI. Wszystko to wymaga Dataverse. Organizacja na on-premise nie tylko nie ma tych funkcji dziś. Nie będzie ich mieć w przyszłości, ponieważ Microsoft nie buduje już dla tej platformy. Strategicznie oznacza to, że każda decyzja inwestycyjna w on-premise CRM po 2024 roku jest decyzją o pogłębianiu izolacji od reszty ekosystemu Microsoft.
Dla architekta systemowego najistotniejsza jest świadomość, że Dataverse nie jest „kolejną bazą". To warstwa abstrakcji, która obsługuje uprawnienia, integracje, audyt i metadane jednolicie dla wszystkich aplikacji Microsoft. On-premise CRM ma własną logikę uprawnień, własny audyt i własne API, które nie współdzielą się z resztą stosu.
Po migracji do Dataverse pojawia się efekt mnożnikowy: każda nowa aplikacja zbudowana w Power Apps korzysta z tej samej warstwy danych, tych samych uprawnień i tej samej historii audytowej. Na on-premise każda taka aplikacja wymaga budowy własnej warstwy integracyjnej.
Trzeci techniczny aspekt to przygotowanie do projektu migracyjnego. Najczęstsza przyczyna przekroczenia budżetu i terminu migracji CRM to brak rzetelnej inwentaryzacji środowiska przed startem. W audytach migracyjnych przeprowadzonych przez ARP Ideas widzimy, że organizacje regularnie nie doceniają liczby aktywnych customizacji. Klient deklaruje „mamy może 10 pluginów i kilkanaście workflows", a po inwentaryzacji okazuje się, że jest 47 pluginów .NET, 130 workflows klasycznych, 22 niestandardowe encje i 18 integracji z systemami zewnętrznymi.
Inwentarz odpowiada na trzy pytania, które determinują wycenę i harmonogram migracji: co przenosi się bezpośrednio do chmury (typowo 60–80% komponentów), co wymaga refaktoryzacji do Power Platform (15–25%), a co trzeba przepisać lub zastąpić innym rozwiązaniem (5–15%). Zachowanie customizacji, pluginów i workflows przy migracji do Dynamics 365 Cloud to oddzielny temat techniczny, który wymaga osobnej decyzji architektonicznej dla każdej kategorii komponentów. Bez tej decyzji wycena migracji opiera się na założeniach, a nie na danych.
Inwentaryzacja to nie jest formalność, którą można odłożyć na fazę projektu. To pierwszy etap, od którego zależy realizm całego business case'u. Każdy plugin, workflow i integracja ma trzy parametry: czy jest aktywny, czy obsługuje krytyczny proces biznesowy i czy ma odpowiednik natywny w chmurze.
Dopiero te trzy parametry, połączone z inwentarzem danych, dają podstawę do wyceny. ARP Ideas robi tę inwentaryzację w ciągu 10 dni roboczych jako część Analizy Gotowości. Wynikiem jest dokument, który staje się załącznikiem do oferty migracyjnej i podstawą decyzji zarządu.
Argumentacja regulacyjna, finansowa i techniczna prowadzi do jednego pytania operacyjnego: jaki jest pierwszy konkretny krok, który Twoja organizacja powinna wykonać w ciągu najbliższych tygodni. Nasi konsultanci podczas spotkań z dyrektorami IT i sponsorami projektów regularnie wskazują na ten sam wzorzec: migracja Dynamics CRM on-premise do chmury rzadko zaczyna się od projektu. Zaczyna się od decyzji o przeprowadzeniu Analizy Gotowości — dokumentu, który pozwala odpowiedzieć na pytania zarządu w sposób oparty na danych, a nie deklaracjach.
Decyzja o starcie projektu migracyjnego nie wymaga, żeby wszystkie warunki zostały spełnione jednocześnie. Wystarczą trzy z pięciu poniższych sygnałów, żeby Analiza Gotowości miała sens biznesowy i żeby projekt można było obronić przed zarządem.
Migracja Dynamics CRM do chmury w metodyce ARP Ideas składa się z czterech sekwencyjnych etapów. Pierwszym jest Analiza Gotowości — pięciodniowy proces, którego wynikiem jest raport biznesowy zawierający inwentarz środowiska, mapę ryzyka regulacyjnego, TCO porównawcze i wstępną wycenę projektu. Ten dokument jest podstawą decyzji zarządu i materiałem startowym dla każdej kolejnej fazy. Drugim etapem jest inwentarz techniczny — dziesięciodniowa praca, podczas której zespół architektów ARP Ideas katalogizuje pluginy, workflows, niestandardowe encje, integracje i dane, klasyfikując każdy komponent według ścieżki migracji.
Trzecim etapem jest sama migracja — przeniesienie danych, refaktoryzacja niezbędnych komponentów, konfiguracja Dataverse i Power Platform, testy regresji i równoległe uruchomienie środowiska produkcyjnego. Konkretna roadmapa migracji od audytu po go-live w 12 tygodniach jest produktem usługowym ARP Ideas i przedmiotem osobnej rozmowy podczas Analizy Gotowości, ponieważ szczegóły harmonogramu zależą od skali środowiska i liczby komponentów wymagających refaktoryzacji. Czwartym etapem jest optymalizacja Dynamics 365 po migracji — okres pierwszych 90 dni po go-live, podczas którego dostrajamy konfigurację, uruchamiamy Copilot i wprowadzamy automatyzację Power Automate w procesach, które wcześniej działały ręcznie.
W tej sekwencji rola partnera wdrożeniowego jest najbardziej widoczna w pierwszym i czwartym etapie. Analiza Gotowości wymaga doświadczenia w wycenie migracji opartej na danych z rzeczywistych projektów, nie szacunkach. Optymalizacja po go-live wymaga znajomości funkcji platformy, które nie były jeszcze dostępne w on-premise i które dopiero teraz wchodzą do codziennej pracy zespołów. Drugi i trzeci etap są bardziej techniczne, ale ich powodzenie zależy od jakości pierwszego.
Migracja Dynamics CRM on-premise do chmury w 2026 roku nie jest projektem technologicznym, jest decyzją o redukcji ryzyka regulacyjnego, finansowego i operacyjnego. Pierwszym konkretnym krokiem, który Twoja organizacja może wykonać w ciągu najbliższych 14 dni, jest umówienie Analizy Gotowości do Migracji z doświadczonym partnerem wdrożeniowym migracji do Dynamics 365 Cloud. Wynikiem jest raport biznesowy, który zawiera odpowiedzi na wszystkie pytania zarządu, czyli TCO porównawcze, mapę ryzyka, harmonogram i wycenę projektu, w jednym dokumencie. To podstawa decyzji, którą można obronić.
Każdy z czterech etapów ma własne deliverables, mierzalne kamienie milowe i punkt decyzyjny po zakończeniu. Po Analizie Gotowości decyzja brzmi „idziemy w projekt czy nie", bez zobowiązań finansowych. Po inwentarzu technicznym zatwierdzamy ostateczną wycenę i harmonogram. Po migracji następuje go-live, którego data jest ustalona przed startem projektu, nie po jego rozpoczęciu.
Ta sekwencja redukuje ryzyko po stronie klienta. Każda kolejna faza jest decyzją na podstawie wyników poprzedniej, nie zobowiązaniem podjętym na początku.
Sześć pytań, które najczęściej pojawiają się podczas konsultacji z dyrektorami IT i sponsorami projektów rozważających migrację Dynamics CRM on-premise do Dynamics 365 Cloud, wraz z odpowiedziami opartymi na audytach migracyjnych i projektach realizowanych przez ARP Ideas.
Podczas 30-minutowej rozmowy z architektem migracji ARP Ideas omówimy stan Twojego środowiska on-premise, zidentyfikujemy obszary największego ryzyka i pokażemy zakres Analizy Gotowości do Migracji — raportu biznesowego, który dostarczamy w 5 dni roboczych jako podstawę decyzji zarządu.
Analiza potrzeb i wstępna ocena gotowości w 30-minutowej rozmowie
