Migracja z Dynamics AX do Dynamics 365: jak wybrać partnera, koszt i etapy (2026)

Migracja z Dynamics AX do Dynamics 365 to nie zwykła aktualizacja, lecz przejście na inną architekturę systemu, inny model licencyjny i inny rytm utrzymania oprogramowania. Dla zarządu jest to decyzja inwestycyjna, a nie wyłącznie informatyczna: zmienia się sposób księgowania kosztu (z nakładu kapitałowego na abonament operacyjny), rozkład ryzyka w czasie oraz sposób finansowania kolejnych lat rozwoju procesów. O powodzeniu w największym stopniu decyduje partner, ponieważ to on ocenia stan obecnego środowiska, przenosi i waliduje dane, odtwarza integracje oraz modernizuje procesy narosłe wokół starego systemu.

‍
Poniżej odpowiadamy na pytania, które najczęściej zadają osoby odpowiedzialne za ten projekt: jak wybrać firmę i partnera, ile realnie kosztuje migracja, jak przebiega proces oraz kto wykona migrację danych i integracje. Traktujemy je jednak jako zestaw decyzji strategicznych, w których największą wartość ma nie sama migracja, lecz to, jak ograniczono jej ryzyko i skrócono okres podwójnego utrzymywania dwóch środowisk — bo to ten okres, a nie licencje, generuje najwięcej ukrytych kosztów.
‍

Najważniejsze fakty w skrócie:
• Kogo wybrać. Partnera z udokumentowanym doświadczeniem w samych migracjach z AX (nie tylko we wdrożeniach D365), statusem Microsoft Solutions Partner, własnym zespołem oraz kompetencjami w migracji danych i integracjach.
• Dwie ścieżki migracji. Reimplementacja (nowe środowisko D365 z migracją danych) albo aktualizacja narzędziami Microsoft; wybór zależy od stopnia customizacji AX i zapada dopiero po audycie przedmigracyjnym.
• Ile to kosztuje. Suma trzech składników: licencji Microsoft (Dynamics 365 Finance od 182 € za użytkownika miesięcznie), prac partnera i utrzymania po go-live. Rzetelną kwotę daje audyt, a nie cennik.
• Ile trwa i jak przebiega. Sześć faz: audyt przedmigracyjny, projekt rozwiązania docelowego, migracja danych, integracje, testy i szkolenia oraz go-live z opieką.
• Co decyduje o koszcie i ryzyku. Stan i stopień customizacji obecnego AX, jakość oraz ilość danych do przeniesienia, liczba i złożoność integracji, a także zakres modernizacji procesów.
• Dlaczego teraz. Wszystkie wersje Dynamics AX są już poza wsparciem Microsoft (12 kwietnia 2022 dla AX 2009/2012/2012 R2, 10 stycznia 2023 dla 2012 R3), co oznacza brak poprawek zabezpieczeń i rosnący dług technologiczny.

‍

Jak wybrać firmę i partnera do migracji z Dynamics AX do D365

Najlepszą firmę do migracji z Dynamics AX do D365 rozpoznasz po udokumentowanym doświadczeniu w samych migracjach z AX, statusie Microsoft Solutions Partner (Business Applications), własnym zespole konsultantów oraz kompetencjach w migracji danych i integracjach. Migracja rządzi się innymi prawami niż nowe wdrożenie, dlatego liczy się partner, który przeprowadził już podobne projekty, a nie tylko wdrażał D365 od zera.

‍
Różnica jest fundamentalna i często niedoceniana przez kupujących. Nowe wdrożenie zaczyna się od pustej kartki i projektuje procesy tak, jak być powinny. Migracja zaczyna się od zastanego stanu, obciążonego latami customizacji, wyjątków i nieudokumentowanych zależności, i musi ten stan najpierw zrozumieć, zanim cokolwiek przeniesie.
Partner bez śladu migracyjnego zwykle nie docenia właśnie tej fazy rozpoznania, przez co zaniża wycenę na starcie i renegocjuje ją w połowie projektu, gdy pojawiają się integracje i modyfikacje, o których nikt nie wiedział. „Najlepszy" partner to ten z realnym śladem migracyjnym i modelem dalszej modernizacji systemu, a nie z najgłośniejszą marką.

‍
Przy wyborze warto oddzielić kompetencję sprzedażową od kompetencji dostarczeniowej: prezentacja handlowa pokazuje docelowy system, natomiast referencje migracyjne pokazują, jak partner radził sobie z chaosem stanu wyjściowego, opóźnieniami po stronie klienta i danymi gorszej jakości niż zakładano. Pytaj więc nie o to, co partner potrafi zbudować, lecz o to, jak zachował się, gdy projekt odbiegał od planu, kto ponosił konsekwencje przekroczeń i w jaki sposób dzielono odpowiedzialność za dane wejściowe.
Odpowiedzi na te pytania rozróżniają dostawcę oprogramowania od partnera, który realnie zarządza ryzykiem przedsięwzięcia.

‍

‍

Osobnym, często pomijanym kryterium jest model podziału odpowiedzialności między organizację a partnera. W migracji z AX granica odpowiedzialności rzadko przebiega tam, gdzie wskazuje umowa, ponieważ jakość danych źródłowych, dostępność wiedzy o starych procesach i decyzyjność po stronie klienta bezpośrednio wpływają na wynik prac partnera.
Dojrzały dostawca formułuje tę granicę wprost: określa, za jaką jakość danych wejściowych odpowiada klient, w jakim czasie musi zapadać decyzja biznesowa, aby nie zatrzymać harmonogramu, oraz które ryzyka są współdzielone.

‍
Warto zwrócić uwagę na sposób, w jaki partner zarządza tak zwanym ryzykiem wiedzy niejawnej, czyli zależnością od pojedynczych osób, które jako jedyne rozumieją, dlaczego dany moduł AX działa w określony sposób. Partner z własnym zespołem in-house buduje redundancję kompetencji i dokumentuje decyzje, dzięki czemu odejście jednego konsultanta nie zatrzymuje projektu, podczas gdy model oparty na podwykonawcach rozprasza wiedzę i utrudnia egzekwowanie odpowiedzialności.

‍
Równie istotny jest sposób, w jaki partner planuje transfer wiedzy do wewnętrznego zespołu klienta, ponieważ organizacja, która po go-live pozostaje całkowicie zależna od dostawcy, traci możliwość realnej kontroli nad kosztem utrzymania i tempem dalszych zmian. Dlatego ocena partnera powinna obejmować nie tylko kompetencje wdrożeniowe, lecz także jego zdolność do usamodzielnienia klienta, jasność w rozgraniczaniu ról oraz gotowość do przyjęcia współodpowiedzialności za te elementy projektu, na które realnie ma wpływ. To zwykle rozróżnia partnera strategicznego od zwykłego wykonawcy zleceń.

‍

Inwentaryzacja długu technologicznego AX i decyzja, co migrować

Pierwszą decyzją strategiczną w migracji nie jest wybór technologii docelowej, lecz uczciwa inwentaryzacja tego, co organizacja przez lata zbudowała wokół Dynamics AX, oraz świadome rozstrzygnięcie, które z tych elementów w ogóle warto przenosić. Wieloletnie środowisko AX to nie jeden system, lecz warstwowa konstrukcja: standardowa funkcjonalność, dziesiątki lub setki modyfikacji, obejścia procesowe wprowadzone doraźnie, integracje dopisywane pod konkretne potrzeby oraz raporty, których nikt już świadomie nie utrzymuje.

‍
Znaczna część tej konstrukcji to dług technologiczny, czyli funkcjonalność, która kiedyś rozwiązywała realny problem, lecz dziś powiela możliwości standardu, obsługuje procesy, które już nie istnieją, albo utrzymuje wyjątki wprowadzone dla klientów czy rynków, których organizacja od dawna nie obsługuje. Migracja jest jedynym momentem w cyklu życia systemu, w którym ten dług można spłacić bez dodatkowej inwestycji, ponieważ i tak dokonuje się przeglądu całości.

‍
Przeniesienie długu na nową platformę jest natomiast najkosztowniejszym z możliwych błędów: organizacja płaci za odtworzenie modyfikacji, których nie potrzebuje, a następnie płaci ponownie za ich utrzymanie przez kolejne lata. Rzetelna inwentaryzacja odpowiada na trzy pytania dla każdego elementu środowiska: czy jest jeszcze używany, czy jego funkcję pokrywa standard D365 oraz jaki jest koszt jego odtworzenia w porównaniu z korzyścią, jaką daje. Odpowiedzi rzadko są oczywiste, ponieważ wymagają połączenia wiedzy technicznej z wiedzą procesową, którą posiadają rozproszeni użytkownicy biznesowi. To dlatego audyt przedmigracyjny nie jest formalnością, lecz najważniejszą inwestycją całego przedsięwzięcia. To on rozstrzyga, czy migracja stanie się okazją do uproszczenia organizacji, czy jedynie przeniesie dotychczasową złożoność na droższą infrastrukturę i utrwali ją na kolejną dekadę.

‍

Reimplementacja czy aktualizacja: dwie ścieżki migracji z AX

Migrację z Dynamics AX do D365 można przeprowadzić na dwa sposoby: jako reimplementację (nowe środowisko D365 z migracją danych) albo jako aktualizację z użyciem narzędzi Microsoft do przeniesienia kodu, danych i konfiguracji. Wybór zależy od tego, jak mocno zmodyfikowany jest obecny AX i jak duży jest zakres zmian w procesach. Doświadczony partner rekomenduje ścieżkę dopiero po audycie przedmigracyjnym. Za tym z pozoru technicznym rozstrzygnięciem kryje się jednak zasadnicza decyzja ekonomiczna: czy taniej jest przenieść istniejący kod i konfigurację, czy odtworzyć funkcjonalność od nowa w oparciu o standard.

‍
Odpowiedź nie jest liniowa. Aktualizacja wydaje się tańsza, ponieważ pozornie zachowuje dotychczasowy dorobek, lecz jej koszt gwałtownie rośnie wraz ze stopniem customizacji, gdyż każda modyfikacja musi zostać przełożona na nowy model rozszerzeń D365, przetestowana i utrzymywana dalej. Reimplementacja wydaje się droższa na starcie, ponieważ wymaga ponownego zaprojektowania procesów, lecz w środowiskach mocno zmodyfikowanych bywa tańsza w całym cyklu życia, bo pozwala porzucić dług technologiczny i oprzeć się na standardzie, który Microsoft utrzymuje i rozwija bez udziału klienta.

‍
Kluczowa jest tu ekonomia utrzymania po go-live, a nie jednorazowy koszt przejścia: im więcej kodu przeniesiono zamiast zastąpić go standardem, tym większe zobowiązanie do jego aktualizowania przy każdej kolejnej wersji platformy. Decyzja powinna więc wynikać z rachunku całkowitego kosztu posiadania w perspektywie kilkuletniej, a nie z porównania dwóch ofert na samą migrację. Doświadczony partner przedstawia ten rachunek wprost, pokazując, jak każda ze ścieżek obciąży organizację nie tylko w roku wdrożenia, lecz w każdym kolejnym roku eksploatacji systemu i jego kolejnych aktualizacji.

‍

‍

Najkosztowniejszym błędem w tej decyzji jest pułapka podejścia „lift and shift", czyli mechanicznego przeniesienia obecnego stanu na nową platformę bez rewizji procesów. Kusi ono pozorną prostotą i szybkością, ponieważ nie wymaga trudnych rozmów o zmianie sposobu pracy, a organizacja unika oporu użytkowników przyzwyczajonych do dotychczasowych ekranów i obejść. W praktyce jest to jednak przeniesienie problemu, a nie jego rozwiązanie.

‍
Dynamics 365 różni się od AX modelem rozszerzeń, w którym modyfikacje nie zmieniają już rdzenia systemu, lecz działają obok niego, co ma umożliwić bezbolesne aktualizacje. Odtworzenie starych customizacji jeden do jednego często łamie tę zasadę albo wymusza karkołomne rozwiązania, które podnoszą koszt każdej przyszłej aktualizacji i niweczą główną korzyść z przejścia na platformę utrzymywaną przez Microsoft.

‍
Organizacja, która wybiera „lift and shift", zwykle płaci trzykrotnie: raz za odtworzenie modyfikacji, drugi raz za ich utrzymanie przy kolejnych wersjach, a trzeci raz za utracone korzyści ze standardowej funkcjonalności, której nie wdrożyła, bo trzymała się starych rozwiązań. Alternatywą nie jest jednak przeprojektowanie wszystkiego naraz, co wprowadziłoby nadmierne ryzyko i opór organizacji. Rozsądna strategia rozróżnia procesy, w których organizacja ma realną przewagę konkurencyjną i które warto zachować w zmodyfikowanej formie, od procesów wspierających, w których standard jest w zupełności wystarczający, a każda modyfikacja to zbędny koszt. Ta selektywność, a nie doktrynalne trzymanie się jednej ścieżki, odróżnia migrację dojrzałą od migracji prowadzonej wyłącznie pod presją terminu i budżetu.

‍

Jak przebiega migracja z Dynamics AX do D365 krok po kroku

Migracja z Dynamics AX do D365 przebiega w sześciu fazach: audyt przedmigracyjny, projekt rozwiązania docelowego, migracja danych, integracje, testy i szkolenia oraz go-live z opieką powdrożeniową. Czas trwania zależy od stanu środowiska AX, liczby integracji i zakresu danych, a rzetelny harmonogram powstaje po audycie. Warto jednak spojrzeć na te fazy nie jako na sekwencję czynności technicznych, lecz jako na proces stopniowego redukowania niepewności. Każda faza ma za zadanie zamienić założenia w potwierdzoną wiedzę, zanim organizacja podejmie zobowiązania, których nie da się już łatwo cofnąć.

‍
Audyt zamienia domysły o stanie środowiska w fakty. Projekt rozwiązania docelowego zamienia oczekiwania biznesu w konkretną architekturę i decyzje o zakresie. Migracja danych i integracje weryfikują, czy przyjęty projekt wytrzymuje kontakt z rzeczywistymi danymi i rzeczywistymi systemami. Testy potwierdzają, że całość działa w warunkach zbliżonych do produkcyjnych. Ten sposób myślenia ma praktyczną konsekwencję dla zarządu: najdroższe błędy powstają wtedy, gdy organizacja skraca wczesne fazy, aby szybciej dojść do widocznych efektów, a następnie odkrywa nieznane wcześniej zależności dopiero podczas testów lub, w najgorszym wypadku, po go-live. Koszt naprawy błędu rośnie wykładniczo wraz z fazą, w której zostaje wykryty, dlatego pozorne oszczędności na audycie i projekcie zwykle wracają jako wielokrotnie większe koszty na końcu.

‍
Odpowiednio poprowadzony harmonogram nie jest więc listą zadań ułożonych po kolei, lecz świadomym zarządzaniem ryzykiem w czasie: najpierw rozstrzyga się to, co najbardziej niepewne i najbardziej kosztowne w razie pomyłki, a dopiero potem to, co można bezpiecznie doprecyzować później. Partner, który tak buduje plan, chroni nie tylko termin, lecz przede wszystkim budżet i wiarygodność projektu wobec zarządu.

‍

‍

Odrębnej uwagi wymaga strategia przełączenia na nowy system, czyli tak zwany cutover, ponieważ to ona w największym stopniu decyduje o rozkładzie ryzyka i o wpływie projektu na przepływ gotówki. Możliwe są dwa podejścia. Cutover jednorazowy oznacza przełączenie całej organizacji na D365 w jednym momencie, zwykle w wybrany weekend, po którym stary system zostaje wyłączony. Cutover fazowy rozkłada przejście w czasie, uruchamiając nowy system kolejno dla wybranych spółek, krajów lub obszarów działalności.

‍
Wybór między nimi to klasyczny kompromis między ryzykiem skoncentrowanym a czasem trwania podwójnego utrzymania. Podejście jednorazowe jest krótsze i tańsze w utrzymaniu, ponieważ organizacja nie prowadzi równolegle dwóch środowisk, lecz koncentruje całe ryzyko w jednym punkcie: jeśli coś zawiedzie po przełączeniu, dotyczy to od razu całej działalności, a możliwość wycofania się jest ograniczona.

‍
Podejście fazowe rozprasza ryzyko, pozwala uczyć się na wcześniejszych etapach i ogranicza skalę potencjalnej awarii do pojedynczego obszaru, lecz wydłuża okres, w którym trzeba utrzymywać, integrować i uzgadniać dane w dwóch systemach jednocześnie, co bezpośrednio podnosi koszt i obciąża zespoły. Z perspektywy finansowej cutover fazowy rozkłada wydatek i ryzyko w czasie, natomiast jednorazowy koncentruje je, oferując w zamian krótszy okres podwyższonego kosztu.
Nie istnieje tu odpowiedź uniwersalna: organizacja o dużej tolerancji przestoju i prostej strukturze może wybrać przełączenie jednorazowe, natomiast grupa wielospółkowa i międzynarodowa niemal zawsze skorzysta na podejściu fazowym, mimo jego wyższego kosztu utrzymania.

‍

Ryzyko regresji i strategia testów

Największym niewidocznym ryzykiem migracji jest regresja, czyli sytuacja, w której procesy działające poprawnie w starym systemie przestają działać prawidłowo w nowym, mimo że nikt świadomie ich nie zmieniał. Regresja jest szczególnie groźna, ponieważ nie objawia się od razu i nie zawsze przyjmuje formę wyraźnej awarii. Częściej przybiera postać cichego błędu: nieprawidłowo naliczonego podatku, pominiętego rabatu, błędnie zaksięgowanej transakcji czy dokumentu, który generuje się z niepełnymi danymi.

‍
Takie błędy potrafią przez tygodnie pozostawać niezauważone, a wykryte dopiero przy zamknięciu okresu lub audycie, generują koszt nieproporcjonalnie większy niż koszt ich wcześniejszego wychwycenia. Dlatego strategia testów nie może ograniczać się do sprawdzenia, czy nowy system uruchamia się i czy użytkownicy potrafią się zalogować. Musi systematycznie potwierdzać, że kluczowe procesy końcowe dają w D365 taki sam poprawny wynik jak w AX, przy tych samych danych wejściowych. Wymaga to zdefiniowania scenariuszy testowych obejmujących nie tylko typowy przebieg procesu, lecz przede wszystkim wyjątki, przypadki brzegowe i sytuacje, w których stary system zachowywał się w sposób nieoczywisty, często wskutek dawnych modyfikacji.

‍
Testy akceptacyjne prowadzone przez samych użytkowników biznesowych mają tu wartość nie do zastąpienia, ponieważ to oni znają wyjątki, których żadna dokumentacja nie opisuje. Rozsądna strategia obejmuje również testy wydajnościowe na realnym wolumenie danych oraz testowe zamknięcie okresu, które weryfikuje najbardziej wrażliwe procesy finansowe przed przełączeniem produkcyjnym. Inwestycja w rzetelne testowanie jest jedną z najbardziej opłacalnych w całym projekcie, ponieważ chroni przed klasą błędów, które ujawniają się najpóźniej i kosztują najwięcej, a jednocześnie buduje zaufanie organizacji do nowego systemu w krytycznym momencie startu.

‍

Migracja danych z Dynamics AX: jak przebiega i kto ją wykona

Migrację danych z Dynamics AX wykonuje partner wdrożeniowy w ramach projektu migracji, w pięciu krokach: ekstrakcja, oczyszczenie, mapowanie, przeniesienie i walidacja. Dane są najczęstszym źródłem ryzyka w całym projekcie, dlatego kluczowe jest doświadczenie zespołu w mapowaniu struktur AX na model danych D365 oraz w walidacji kompletności po migracji.
Ryzyko wynika stąd, że dane w wieloletnim środowisku AX niemal nigdy nie są tak spójne, jak zakłada dokumentacja: zawierają duplikaty, rekordy osierocone, pola wykorzystywane niezgodnie z pierwotnym przeznaczeniem oraz historyczne zapisy, które powstały w innych realiach procesowych. Mechaniczne przeniesienie takiego stanu do nowego systemu przenosi wraz z nim wszystkie te wady, a dodatkowo naraża projekt na to, że nieprawidłowości ujawnią się dopiero na produkcji.

‍
Dlatego doświadczony zespół traktuje etap oczyszczenia i mapowania nie jako czynność techniczną, lecz jako decyzję biznesową o tym, co i w jakiej formie ma trafić do nowego systemu. Wymaga to bliskiej współpracy konsultantów z osobami znającymi procesy, ponieważ tylko one potrafią rozstrzygnąć, czy nietypowy zapis to błąd do usunięcia, czy świadomy wyjątek do zachowania. Równie istotna jest walidacja, która nie może ograniczać się do porównania liczby rekordów, lecz musi potwierdzać poprawność sald, sum kontrolnych i kluczowych powiązań między obiektami. Warto pamiętać, że odpowiedzialność za dane jest współdzielona: partner odpowiada za metodę, narzędzia i przebieg migracji, natomiast organizacja odpowiada za merytoryczne rozstrzygnięcia dotyczące treści danych oraz za ich potwierdzenie w fazie walidacji. Jasny podział tej odpowiedzialności na wczesnym etapie eliminuje jedno z najczęstszych źródeł sporów i opóźnień w całym projekcie, zwłaszcza gdy jakość danych okazuje się gorsza od pierwotnych założeń przyjętych na etapie oferty.

‍
Badania nad migracjami ERP potwierdzają, że jakość danych źródłowych — duplikaty, braki w polach obowiązkowych i niespójne formaty — należy do głównych źródeł ryzyka, dlatego dojrzałe projekty prowadzą migrację w kilku fazach próbnych (mock, SIT, UAT) z rekonsyliacją na każdym etapie (analiza strategii migracji danych ERP).

‍

‍

Osobną decyzją strategiczną jest strategia archiwizacji, czyli świadome rozstrzygnięcie, że nie wszystkie dane historyczne należy migrować do nowego systemu. To jedno z bardziej kontrintuicyjnych ustaleń w projektach migracyjnych, ponieważ naturalnym odruchem organizacji jest chęć przeniesienia całej historii, aby niczego nie utracić.
W praktyce migrowanie pełnej historii transakcyjnej za wiele lat wstecz podnosi koszt i czas migracji, obciąża nowy system wolumenem danych, którego użytkownicy w bieżącej pracy niemal nie wykorzystują, oraz komplikuje testy i walidację.

Rozsądniejsze jest rozdzielenie danych na trzy kategorie:
• Dane operacyjne. Potrzebne do bieżącej pracy — otwarte zobowiązania, aktualne stany magazynowe, trwające zamówienia — migruje się w całości.
• Ograniczona historia. Zwykle z kilku ostatnich okresów, migrowana po to, aby zachować ciągłość analiz i porównań rok do roku.
• Głęboka historia. Potrzebna głównie do celów zgodności i ewentualnych kontroli, może pozostać w bezpiecznym archiwum poza systemem produkcyjnym, dostępnym na żądanie, zamiast obciążać środowisko robocze. Takie podejście wymaga jednak wcześniejszego rozstrzygnięcia wymogów prawnych dotyczących okresu przechowywania danych oraz zapewnienia, że archiwum pozostaje czytelne i dostępne przez cały wymagany czas.

‍
Decyzja o zakresie archiwizacji ma bezpośredni wpływ na koszt migracji, wydajność nowego systemu oraz na ryzyko audytowe, dlatego powinna zapadać świadomie na poziomie zarządu, a nie jako uboczny efekt ustaleń technicznych. Właściwie zaprojektowana archiwizacja godzi wymóg zgodności z ekonomiką eksploatacji nowego środowiska.
Przykładem migracji danych w skali enterprise jest projekt dla sieci New Yorker: przejście z Dynamics AX na Dynamics 365 Finance objęło ponad 1000 sklepów w 40 krajach, wraz z dedykowanym komponentem migracji danych i silnikiem zarządzania cenami.

‍

Złożone integracje w Dynamics 365

Złożone integracje w Dynamics 365 realizuje partner z kompetencjami w architekturze danych i doświadczeniem w łączeniu D365 z systemami zewnętrznymi. Stare środowiska AX mają zwykle wiele integracji (produkcja, logistyka, e-commerce, analityka), a migracja to moment, w którym warto je odtworzyć i zmodernizować, a nie tylko przepiąć.

‍
Integracje są przy tym obszarem, w którym najczęściej ujawnia się niedoszacowanie zakresu, ponieważ w wieloletnim środowisku ich rzeczywista liczba i złożoność rzadko są w pełni udokumentowane. Wiele połączeń powstawało doraźnie, część działa w tle bez świadomości bieżących właścicieli procesów, a niektóre opierają się na przestarzałych mechanizmach, które w nowej architekturze nie mają bezpośredniego odpowiednika. Dlatego pierwszym zadaniem nie jest samo odtworzenie połączeń, lecz rzetelna inwentaryzacja tego, co, z czym i w jakim celu się komunikuje oraz które z tych przepływów są nadal potrzebne. Migracja jest naturalnym momentem, aby zastąpić kruche połączenia punkt do punktu bardziej odporną architekturą opartą na jasno zdefiniowanych interfejsach, co ogranicza ryzyko, że awaria jednego systemu pociągnie za sobą kolejne.

‍
Kluczowe jest też rozróżnienie integracji krytycznych, bez których organizacja nie może prowadzić działalności, od integracji wspierających, których chwilowa niedostępność jest akceptowalna. To rozróżnienie porządkuje priorytety testów i decyzje o kolejności przełączania, ponieważ integracja krytyczna musi być gotowa i przetestowana przed go-live, natomiast mniej istotne przepływy można uruchamiać stopniowo.
Modernizacja integracji przy okazji migracji przynosi trwałą korzyść: nowe środowisko staje się nie tylko odtworzeniem starego, lecz podstawą do dalszej automatyzacji i lepszego wykorzystania danych, co jest jednym z głównych uzasadnień biznesowych całego przedsięwzięcia i argumentem, który przekonuje zarząd, że projekt jest inwestycją, a nie wyłącznie wymianą technologii.

‍

‍

Osobnym wyzwaniem, o którym rzadko mówi się na etapie planowania, są customizacje AX bez bezpośredniego odpowiednika w D365 oraz zależności decydujące o oknie migracyjnym. Część mechanizmów, które w AX zbudowano jako głębokie modyfikacje rdzenia, w nowej architekturze wymaga zupełnie innego podejścia, ponieważ Dynamics 365 celowo ogranicza możliwość ingerencji w standard, aby zabezpieczyć zdolność do bezproblemowych aktualizacji.
W takich przypadkach partner musi rozstrzygnąć, czy daną funkcję odtworzyć jako rozszerzenie, zastąpić standardem, przenieść do zewnętrznej usługi, czy porzucić, jeśli nie ma już uzasadnienia biznesowego. Każdy z tych wariantów ma inny koszt i inne konsekwencje dla przyszłego utrzymania, dlatego decyzje te powinny zapadać świadomie, a nie automatycznie na rzecz odtworzenia stanu istniejącego.

‍
Równie istotne jest zarządzanie oknem migracyjnym, czyli okresem, w którym możliwe jest bezpieczne przełączenie bez kolizji z krytycznymi wydarzeniami w kalendarzu organizacji. Migracji nie planuje się w oderwaniu od cyklu biznesowego: przełączenie tuż przed zamknięciem roku, w szczycie sezonu sprzedażowego czy w okresie inwentaryzacji wielokrotnie zwiększa ryzyko i koszt ewentualnego błędu. Do tego dochodzą zależności zewnętrzne, takie jak terminy zmian podatkowych, wymogi sprawozdawcze czy harmonogramy dostawców systemów współpracujących, które potrafią zawęzić realne okno do kilku wąskich przedziałów w roku. Świadome zarządzanie tymi zależnościami jest elementem zarządzania ryzykiem projektu, a nie jedynie logistyką harmonogramu, ponieważ błędny wybór terminu potrafi zniweczyć nawet bardzo dobrze przygotowaną migrację.

‍
Dobry partner planuje okno migracyjne od tych ograniczeń wstecz, a nie od wewnętrznej dostępności zespołu wdrożeniowego.
Skalę integracji pokazują realne projekty: dla TERG (Media Expert) środowisko Dynamics 365 Finance objęło 154 interfejsy integracyjne i rozliczenia omnichannel, a dla producenta OSTP system Dynamics zintegrowano z systemem MES oraz narzędziami logistyki i planowania łańcucha dostaw.

‍

Ile kosztuje pełna migracja z Dynamics AX 2012 do D365

Pełny koszt migracji z Dynamics AX 2012 do D365 składa się z trzech elementów: licencji Microsoft, prac wdrożeniowych partnera i utrzymania po go-live. Wycena jest indywidualna, bo zależy od stanu środowiska AX, zakresu customizacji, liczby integracji i ilości danych do migracji. Sama licencja Dynamics 365 Finance zaczyna się od 182 € za użytkownika miesięcznie (cennik Microsoft, rozliczenie roczne). Koszt prac partner wycenia po audycie przedmigracyjnym.
Z perspektywy zarządu istotniejsze od pojedynczych pozycji cennika jest jednak zrozumienie struktury kosztu w czasie oraz tego, które jego elementy są przewidywalne, a które obarczone niepewnością. Licencje są elementem najbardziej przewidywalnym, ponieważ wynikają z jawnego cennika i liczby użytkowników, i przekształcają dotychczasowy model nakładu kapitałowego w regularny koszt operacyjny, co samo w sobie zmienia sposób planowania budżetu i rozkłada wydatek równomiernie w czasie.

‍
Prace partnera są elementem najbardziej zmiennym, ponieważ ich zakres zależy od czynników, które ujawniają się dopiero podczas audytu, takich jak rzeczywisty stopień customizacji, jakość danych i liczba integracji. Właśnie dlatego wiarygodna wycena wymaga audytu, a oferta podana bez niego jest w istocie deklaracją intencji, a nie zobowiązaniem.
Utrzymanie po go-live jest elementem najczęściej pomijanym w kalkulacjach, choć w perspektywie kilku lat potrafi przewyższyć koszt samej migracji, dlatego powinno być planowane od początku jako stały składnik całkowitego kosztu posiadania. Dojrzała ocena kosztu nie polega więc na porównywaniu ofert na samo wdrożenie, lecz na zestawieniu pełnego kosztu w perspektywie kilkuletniej, obejmującego licencje, wdrożenie, utrzymanie oraz koszt zwłoki, którą organizacja ponosi, pozostając na niewspieranym systemie.
Dopiero taki rachunek pozwala podjąć decyzję inwestycyjną w oparciu o rzeczywistą ekonomikę, a nie o najniższą cenę widoczną na pierwszej stronie oferty.

‍

‍

Co najbardziej podnosi koszt migracji: liczba i złożoność integracji, stopień customizacji obecnego AX, jakość i ilość danych do przeniesienia oraz zakres modernizacji procesów. Dlatego rzetelną wycenę uzyskasz dopiero po audycie, a nie z cennika.
Niezależne analizy rynku ERP wskazują, że to właśnie koszty ukryte — zarządzanie zmianą, oczyszczanie i migracja danych, testy oraz utrzymanie integracji — najczęściej odpowiadają za przekroczenia budżetu, a nie sama stawka licencji (Panorama Consulting).

‍

Realny koszt pozostania na niewspieranym AX

W rachunku ekonomicznym migracji najczęściej pomija się drugą stronę równania, czyli koszt zaniechania, który organizacja ponosi każdego miesiąca pozostawania na niewspieranym systemie.

‍
Koszt ten jest realny, choć rozproszony i trudniejszy do zobaczenia w budżecie niż faktura za wdrożenie, co sprawia, że decyzja o zwłoce wydaje się pozornie bezpieczna. Na koszt zaniechania składają się co najmniej cztery elementy:
• Ryzyko bezpieczeństwa. System bez poprawek zabezpieczeń staje się z każdym miesiącem bardziej podatny na znane luki, a incydent w systemie ERP dotyka rdzenia działalności, od finansów po łańcuch dostaw.
• Ryzyko zgodności. Niewspierane oprogramowanie z czasem przestaje spełniać zmieniające się wymogi prawne i sprawozdawcze, a ich doraźne obchodzenie generuje własny dług i własne ryzyko błędu.
• Ryzyko audytowe i ubezpieczeniowe. Audytorzy coraz częściej traktują pracę na niewspieranym systemie krytycznym jako słabość kontroli wewnętrznej, a ubezpieczyciele ryzyk cybernetycznych mogą podnosić składki, zawężać ochronę lub kwestionować wypłatę odszkodowania po incydencie.
• Koszt alternatywny i dług technologiczny. Dopóki organizacja utrzymuje przestarzały system, nie korzysta z automatyzacji, analityki i funkcji dostępnych standardowo w nowej platformie, a każdy kolejny rok modyfikacji i obejść zwiększa późniejszy koszt migracji.
‍

Zsumowanie tych składników zwykle pokazuje, że zwłoka nie jest oszczędnością, lecz odroczonym i rosnącym wydatkiem, obarczonym dodatkowo ryzykiem zdarzenia nagłego, którego moment i skala pozostają poza kontrolą organizacji.

‍

Dlaczego migrować z Dynamics AX teraz

Migrację z Dynamics AX warto zrealizować bez zwłoki, ponieważ wszystkie wersje AX są już poza wsparciem Microsoft. Dla Dynamics AX 2009, 2012 i 2012 R2 rozszerzone wsparcie, obejmujące już wyłącznie poprawki zabezpieczeń, zakończyło się 12 kwietnia 2022, a dla AX 2012 R3 10 stycznia 2023 (cykl życia produktu, Microsoft). W praktyce oznacza to brak poprawek bezpieczeństwa, rosnące ryzyko zgodności i brak dostępu do nowych funkcji. Im dłużej trwa praca na niewspieranym systemie, tym większy dług techniczny i koszt późniejszej migracji.

‍
Do tych argumentów dochodzi jednak jeszcze jeden, o charakterze czysto praktycznym i rzadko poruszany na wczesnym etapie planowania: dostępność kompetencji. Rynek specjalistów znających Dynamics AX kurczy się z każdym rokiem, ponieważ konsultanci i programiści naturalnie przechodzą do technologii aktualnych, a nowe osoby nie uczą się już platformy, która nie jest rozwijana.
Organizacja, która odkłada migrację, konkuruje więc o coraz mniejszą pulę ekspertów, a koszt utrzymania i dowolnej zmiany w starym systemie rośnie nie z powodu skali prac, lecz z powodu rzadkości kompetencji. Ten sam mechanizm dotyczy wiedzy wewnętrznej: osoby, które przez lata rozumiały, dlaczego dany moduł AX działa w określony sposób, odchodzą lub zmieniają role, a wraz z nimi znika wiedza niezbędna do przeprowadzenia bezpiecznej migracji.

‍
Każdy rok zwłoki zwiększa więc nie tylko dług technologiczny, lecz również ryzyko utraty wiedzy potrzebnej do jego spłacenia. Perspektywa zarządu powinna zatem uwzględniać, że okno na migrację prowadzoną w komfortowych warunkach, z dostępem do kompetencji i zachowaną wiedzą organizacyjną, stopniowo się zamyka.
Migracja podjęta świadomie, zanim wymusi ją incydent bezpieczeństwa lub odejście kluczowych osób, jest przedsięwzięciem, które organizacja kontroluje. Migracja odłożona do momentu, w którym staje się koniecznością, jest przedsięwzięciem prowadzonym pod presją, a więc droższym i obarczonym większym ryzykiem.

‍

Kompleksowa migracja starego ERP do D365: zakres usługi ANEGIS

Kompleksowa usługa migracji starego systemu ERP do Dynamics 365 obejmuje całą ścieżkę: od audytu przedmigracyjnego, przez projekt środowiska docelowego, migrację danych i integracje, po testy, go-live i dalszą modernizację. ANEGIS prowadzi takie projekty end-to-end jako wyspecjalizowana firma konsultingowa Microsoft Dynamics 365.

• Status: Microsoft Solutions Partner (Business Applications); historycznie Microsoft Gold Partner.
• Zespół: ponad 200 certyfikowanych ekspertów Microsoft; biura we Wrocławiu, Warszawie, Sieradzu i Londynie.
• Doświadczenie migracyjne: projekty od 20 do 30 000 użytkowników, w tym jedno z największych wdrożeń Dynamics AX na świecie i migracje z AX do D365.
• Zakres: migracja danych, integracje, aktualizacje i modernizacja, opieka serwisowa oraz rollout międzynarodowy.
• Branże: produkcja, handel i dystrybucja, usługi profesjonalne, budownictwo i inżynieria.
  Model end-to-end ma znaczenie strategiczne wykraczające poza wygodę posiadania jednego dostawcy. Jego istotą jest scalenie odpowiedzialności, które w projektach rozproszonych między wielu wykonawców rozmywa się w newralgicznych punktach styku, takich jak granica między migracją danych a integracjami czy między konfiguracją systemu a testami akceptacyjnymi.
  To właśnie na tych stykach powstaje większość opóźnień i sporów, ponieważ każdy z wykonawców odpowiada wyłącznie za swój wycinek, a nikt za całość rezultatu. Partner prowadzący projekt kompleksowo eliminuje ten problem, ponieważ przyjmuje odpowiedzialność za spójność wszystkich elementów oraz za końcowy efekt, a nie za pojedyncze zadania.
  Dla zarządu oznacza to jeden punkt rozliczenia i jednoznacznego przypisania odpowiedzialności, co w projekcie o wysokim ryzyku ma wartość samą w sobie. Nie mniej istotna jest ciągłość: ten sam partner, który przeprowadził migrację i zna wszystkie decyzje podjęte po drodze, prowadzi następnie opiekę serwisową i dalszą modernizację, dzięki czemu wiedza o systemie nie ginie w momencie zakończenia wdrożenia.
  Migracja nie jest bowiem zdarzeniem jednorazowym, lecz początkiem długiego cyklu życia nowej platformy, w którym organizacja stopniowo wykorzystuje kolejne jej możliwości. Wybór partnera zdolnego towarzyszyć organizacji w całym tym cyklu, a nie jedynie w fazie przełączenia, jest decyzją, która przekłada się na koszt i tempo rozwoju systemu przez wiele lat po go-live.
  Dlatego ocena partnera powinna uwzględniać nie tylko to, jak przeprowadzi migrację, lecz także to, jak będzie z organizacją współpracował długo po jej zakończeniu.
  Przykładowe projekty:
• New Yorker (moda, handel detaliczny): migracja z Dynamics AX do Dynamics 365 Finance dla ponad 1000 sklepów w 40 krajach, z komponentem migracji danych i silnikiem cen.
• OSTP (produkcja, stal nierdzewna): środowisko Microsoft Dynamics w Polsce i Szwecji, z integracjami do systemu MES i planowania łańcucha dostaw.
• TERG / Media Expert (handel elektroniką, Polska): Dynamics 365 Finance z 154 interfejsami integracyjnymi i rozliczeniami omnichannel.

‍
Porozmawiajmy o Twojej migracji

‍

‍

‍