Dynamics AX czy Dynamics 365: kiedy warto migrować

Migracja z Dynamics AX do Dynamics 365 opłaca się wtedy, gdy koszt i ryzyko pozostania przy AX zaczynają przewyższać koszt przejścia. Dla większości firm ten moment już minął. Rozszerzone wsparcie dla Dynamics AX 2012 zakończyło się 12 kwietnia 2022 roku, więc system działa dziś bez poprawek bezpieczeństwa i bez aktualizacji regulacyjnych. Poniżej zestawiamy Dynamics AX i Dynamics 365 po najważniejszych różnicach, a potem pokazujemy, kiedy migrować teraz, a kiedy można jeszcze świadomie poczekać.

Decyzja o migracji nie jest w istocie decyzją technologiczną, tylko finansową: to porównanie zdyskontowanego strumienia kosztów utrzymania stanu obecnego z jednorazowym nakładem na przejście i niższym, przewidywalnym kosztem eksploatacji po nim. Kluczowa różnica polega na tym, że koszt pozostania przy AX nie jest stały — rośnie w czasie w sposób, którego nie widać w budżecie rok do roku. Składają się na niego rosnące stawki dzienne malejącej puli specjalistów, koszt samodzielnego utrzymywania zgodności regulacyjnej, narastające ryzyko operacyjne przestarzałej infrastruktury oraz utracone korzyści z automatyzacji, których stara architektura nie udźwignie.

Porównanie dynamics ax vs 365 sprowadza się więc nie do tego, który system ma więcej funkcji, tylko do momentu, w którym krzywa kosztu trwania przecina się z kosztem zmiany. Dla zarządu istotne jest też to, że nakład na migrację jest jednorazowy i policzalny, podczas gdy koszt bezczynności jest rozproszony, odroczony i trudny do zauważenia, dopóki nie zmaterializuje się w postaci incydentu bezpieczeństwa, nieobsłużonej zmiany prawa albo braku ludzi zdolnych utrzymać system. Ten artykuł traktuje pytanie „AX czy Dynamics 365” jako problem zarządzania ryzykiem i kapitałem, a nie jako wybór narzędzia.

‍

Dynamics AX vs Dynamics 365: najważniejsze różnice

‍

‍

Tabela wygląda jak lista przewag nowszego systemu i po części nią jest, ale sama w sobie nie odpowiada na pytanie „kiedy”. Różnica, która faktycznie przesądza o decyzji, kryje się w dwóch wierszach: aktualizacje i wsparcie. Warto czytać tę tabelę nie jako zestawienie funkcji, lecz jako rejestr ryzyk i zobowiązań. Wiersz „model działania” to w istocie decyzja, kto odpowiada za dostępność, skalowanie i odtwarzanie środowiska po awarii: w AX ciężar ten spoczywa na dziale IT i jego dostawcach sprzętu, w Dynamics 365 przechodzi na Microsoft w ramach umowy o poziomie usługi.

Wiersz „licencje” przenosi wydatek z nakładu inwestycyjnego na koszt operacyjny, co zmienia nie tylko rachunek zysków i strat, lecz także sposób, w jaki projekt jest finansowany i amortyzowany. Porównując microsoft dynamics ax vs 365, najłatwiej przeoczyć, że każdy z tych wierszy ma inny horyzont czasowy: część różnic działa na korzyść nowego systemu od pierwszego dnia, a część — jak model aktualizacji — ujawnia wartość dopiero w cyklu kilkuletnim, gdy znika powtarzalny koszt dużego upgrade'u. Dwa wiersze, aktualizacje i wsparcie, są jednak nadrzędne wobec pozostałych, ponieważ wyznaczają nie przewagę, lecz termin: to one zamieniają porównanie na kalendarz i przenoszą rozmowę z „czy” na „kiedy”.

Reszta tabeli opisuje, co firma zyskuje; te dwa wiersze opisują, ile kosztuje zwłoka, i to właśnie one powinny trafić na pierwszą stronę materiału dla zarządu, a nie lista nowych funkcji. Dla dyrektora finansowego użyteczne jest jeszcze jedno odczytanie tej tabeli: część wierszy opisuje preferencje odwracalne, które można zmienić także po migracji, podczas gdy wiersze wsparcia i aktualizacji wyznaczają zobowiązanie nieodwracalne w czasie, ponieważ raz przekroczony termin końca wsparcia nie wraca, a narosłego długu wersji nie da się skasować bez projektu. Dlatego wagi przypisane poszczególnym wierszom nie powinny być równe: dwa wiersze terminowe determinują moment decyzji, a pozostałe jedynie jej uzasadnienie ekonomiczne, i to właśnie pomylenie tych dwóch porządków — potraktowanie różnicy funkcjonalnej jako powodu do pośpiechu, a różnicy terminowej jako miękkiej preferencji — najczęściej prowadzi zarząd do odłożenia decyzji o kwartał za daleko.

‍

Co faktycznie się zmienia, i nie chodzi o interfejs

Największa zmiana między AX a Dynamics 365 nie jest wizualna, tylko dotyczy modelu utrzymania. Dynamics AX zamrażasz w jednej wersji i co kilka lat płacisz za duży, ryzykowny upgrade. Dynamics 365 działa w modelu One Version: wszyscy klienci są na jednej, stale aktualizowanej wersji, a Microsoft wydaje cztery aktualizacje rocznie, w lutym, kwietniu, lipcu i październiku. Są wstecznie zgodne i obowiązkowe, więc nie da się zostać kilka lat w tyle. Ta zmiana ma głębsze konsekwencje ekonomiczne, niż sugeruje sama liczba aktualizacji. W modelu AX firma płaciła za upgrade w postaci nieregularnych, wysokich skoków nakładu — projekt trwający wiele miesięcy, angażujący konsultantów i zamrażający rozwój na czas migracji — po czym wracała do stanu „zamrożenia” aż do następnego cyklu.

One Version zastępuje te skoki stałym, niższym kosztem bieżącym, co dla dyrektora finansowego oznacza przejście z nieprzewidywalnego nakładu inwestycyjnego na wygładzony, planowalny strumień operacyjny. Znika też ukryty koszt długu wersji: w AX każdy pominięty upgrade zwiększał dystans do wersji bieżącej, a im większy dystans, tym droższy i bardziej ryzykowny kolejny skok. Ponieważ aktualizacje Dynamics 365 są wstecznie zgodne i obowiązkowe, ten dług nie ma jak narosnąć, a dynamics 365 upgrade przestaje być projektem, a staje się rutynową operacją utrzymaniową. Dla organizacji, która przez dekadę odkładała kolejne wersje AX, to najważniejsza zmiana modelu TCO: koniec karuzeli upgrade'ów oznacza, że system nie starzeje się skokowo między projektami, tylko utrzymuje aktualność w sposób ciągły, a firma odzyskuje zdolność planowania długu technicznego, którego wcześniej nie kontrolowała.

W praktyce znika największy powtarzalny koszt AX, czyli projekt upgrade co parę lat. W zamian pojawia się nowy obowiązek: system trzeba na bieżąco testować przy każdej aktualizacji. To faktyczna zmiana w sposobie pracy działu IT, nie kosmetyka. Zmienia się też model pieniędzy: zamiast licencji wieczystej z utrzymaniem wchodzi subskrypcja, a Dynamics 365 Finance zaczyna się od 182 € za użytkownika miesięcznie (cennik Microsoft, ceny bez VAT). Nowy obowiązek testowania warto jednak wycenić uczciwie, bo bywa niedoszacowany na etapie decyzji. Cztery aktualizacje rocznie oznaczają, że proces walidacji krytycznych ścieżek — zamknięcie miesiąca, rozliczenia podatkowe, integracje z produkcją — musi być powtarzalny i najlepiej zautomatyzowany, inaczej stanie się wąskim gardłem działu IT.

Firmy, które podchodzą do tego dojrzale, budują zestaw testów regresyjnych jako trwałe aktywo projektu: raz zainwestowany, obniża koszt każdej kolejnej aktualizacji i skraca okno ryzyka po jej wdrożeniu. Dlatego rachunek subskrypcji nie kończy się na 182 € za użytkownika — do porównania dynamics ax vs dynamics 365 należy doliczyć po stronie nowego systemu koszt utrzymania automatyzacji testów, a po stronie AX koszt utrzymania własnej infrastruktury, licencji bazy danych, kopii zapasowych i zespołu, który to wszystko obsługuje. Gdy zestawi się oba rachunki w horyzoncie pięcioletnim, przewaga kosztowa modelu subskrypcyjnego nie bierze się z samej ceny licencji, tylko z przeniesienia całej warstwy utrzymania infrastruktury na dostawcę oraz z eliminacji cyklicznych, kosztownych projektów upgrade, które w AX co kilka lat wracały jako oddzielna pozycja w budżecie inwestycyjnym.

‍

Co oznacza koniec wsparcia Dynamics AX

Najmocniejszy argument za migracją nie jest marketingowy, tylko wynika z kalendarza Microsoftu. Wsparcie główne dla Dynamics AX 2012 skończyło się 9 października 2018 roku, a rozszerzone 12 kwietnia 2022. Wszystkie odsłony AX 2012, łącznie z R2 i R3, są dziś poza rozszerzonym wsparciem. Ten kalendarz ma wymiar, który wykracza poza samą kwestię łatek. Od momentu zakończenia wsparcia rozszerzonego każda nowa podatność wykryta w warstwie, na której opiera się AX, pozostaje trwale otwarta — nie istnieje ścieżka jej domknięcia inna niż migracja albo kosztowna izolacja środowiska. Dla dyrektora IT oznacza to, że upływ czasu nie jest neutralny: liczba znanych, niezałatanych wektorów ataku rośnie monotonicznie, a wraz z nią prawdopodobieństwo incydentu, którego skutki finansowe wielokrotnie przekraczają koszt samej migracji.

To ryzyko nie jest hipotetyczne również dlatego, że wiele wymogów bezpieczeństwa i norm branżowych zakłada, iż oprogramowanie krytyczne pozostaje objęte wsparciem producenta; utrata tego statusu przesuwa AX do kategorii systemów podwyższonego ryzyka niezależnie od tego, jak stabilnie działa na co dzień, i tę zmianę statusu widać dopiero wtedy, gdy trzeba ją wykazać przed audytorem lub ubezpieczycielem. Brak wsparcia brzmi abstrakcyjnie, dopóki nie przełoży się na konkret. System bez wsparcia nie dostaje poprawek bezpieczeństwa, co jest problemem przy każdym audycie i przy polisie cyber. Nie dostaje też aktualizacji regulacyjnych, a to w polskich realiach boli najbardziej. Zmiany podatkowe, kolejne wersje JPK czy obowiązkowe e faktury w KSeF w systemie z bieżącym wsparciem przychodzą jako gotowa aktualizacja.

W Dynamics AX każdą taką zmianę trzeba zbudować i utrzymać samodzielnie, na własny koszt i własne ryzyko. Im dłużej firma zostaje przy AX, tym więcej takich łatek się nawarstwia. Warto rozwinąć wątek zgodności, bo to on najczęściej wymusza termin niezależnie od gotowości organizacji. Obowiązkowy KSeF jest przykładem wyzwalacza regulacyjnego, który działa jak twardy termin: data wejścia w życie nie jest przedmiotem negocjacji, a system musi wystawiać i odbierać faktury ustrukturyzowane w wymaganym formacie bez względu na to, czy dział IT skończył inne priorytety. W systemie z bieżącym wsparciem obsługa takiej zmiany to konfiguracja i aktualizacja; w AX to projekt deweloperski, który trzeba zaplanować, zbudować, przetestować i utrzymywać przy każdej kolejnej wersji schematu.

Drugi, rzadziej dostrzegany skutek to dryf zgodności: im dłużej firma samodzielnie łata regulacje, tym bardziej jej środowisko oddala się od standardu, a każda następna zmiana prawa nakłada się na poprzednie obejścia, podnosząc koszt i ryzyko kolejnej. Ma to również wymiar ubezpieczeniowy i audytowy — ubezpieczyciel cyber oraz audytor coraz częściej pytają wprost o status wsparcia systemów przetwarzających dane finansowe, a odpowiedź „poza wsparciem producenta” potrafi podnieść składkę, zawęzić zakres ochrony albo skutkować zastrzeżeniem w raporcie z badania. Koszt trwania przy AX materializuje się więc nie tylko w budżecie IT, lecz także w cenie ryzyka, które firma przenosi na zewnątrz.

‍

Luka kompetencyjna: kadra AX jako pozycja w rejestrze ryzyk

Argument, który w rozmowach zarządu najczęściej pada zbyt późno, dotyczy ludzi, a nie technologii. Pula specjalistów Dynamics AX kurczy się z dwóch stron jednocześnie: nowi konsultanci szkolą się już wyłącznie na Dynamics 365, a doświadczeni inżynierowie AX naturalnie przechodzą do projektów na nowej platformie, gdzie popyt i stawki są wyższe. Efekt jest podręcznikowy — malejąca podaż przy nieustającym popycie na utrzymanie działających wdrożeń podnosi stawki dzienne i jednocześnie wydłuża czas pozyskania kogokolwiek, kto zna starą technologię. Dla firmy oznacza to, że koszt utrzymania AX rośnie nie z powodu inflacji, lecz z powodu rzadkości kompetencji, a ta rzadkość będzie się tylko pogłębiać, bo rynek nie odtwarza podaży, której nikt już nie kształci.

Do tego dochodzi wymiar, który rzadko trafia do prezentacji zarządu, choć powinien figurować w rejestrze ryzyk: zależność od pojedynczych osób. W wielu firmach wiedza o tym, jak działają customizacje AX i dlaczego dany interfejs zbudowano właśnie tak, mieści się w głowach kilku konsultantów lub jednego wieloletniego pracownika. Z perspektywy bilansu jest to zobowiązanie warunkowe: odejście takiej osoby nie zmniejsza sprawności systemu o ułamek, tylko potrafi sparaliżować zdolność jego utrzymania, bo dokumentacja rzadko nadąża za latami zmian. Im dłużej trwa okno „zostajemy”, tym większe prawdopodobieństwo, że ten scenariusz się ziści, i tym trudniej go potem odwrócić.

Warto tę zależność wycenić w kategoriach, które rozumie zarząd — jako ryzyko ciągłości działania z konkretną ekspozycją finansową — a nie jako miękki problem HR, ponieważ w praktyce to ona, a nie sama technologia, najczęściej wyznacza nieprzekraczalny termin migracji. Praktyczną miarą tej ekspozycji jest pytanie, ile tygodni zajęłoby firmie odtworzenie zdolności utrzymania systemu po nagłym odejściu kluczowego konsultanta oraz jaką premię trzeba by dziś zapłacić za zastępstwo o porównywalnej wiedzy — im dłuższa odpowiedź na pierwsze pytanie i wyższa na drugie, tym bliżej ryzyko przesuwa termin migracji do teraźniejszości, niezależnie od tego, jak dobrze system działa dziś.

‍

Kiedy jeszcze można zostać przy AX

Uczciwa odpowiedź brzmi: czasem tak, ale zawsze z planem. Zostanie przy AX na kilka miesięcy ma sens, gdy środowisko jest stabilne, nie ma pilnej zmiany prawnej do obsłużenia, a zespół nie ma teraz przestrzeni na projekt tej wagi. Sensowne jest też odłożenie startu, jeśli firmę czeka duża zmiana biznesowa, na przykład przejęcie albo nowy model sprzedaży, bo lepiej zaprojektować docelowy system już pod nią, niż migrować dwa razy. Ta decyzja wymaga jednak ram, a nie przeczucia.

Świadome odłożenie migracji jest uzasadnione tylko wtedy, gdy firma potrafi nazwać warunek wyjścia — konkretne zdarzenie lub datę, po których pauza się kończy — oraz oszacować, co ją ta pauza kosztuje. Bez tego „poczekamy” zamienia się w cichą akumulację ryzyka, którego nikt nie wycenił. Dobrą praktyką jest potraktowanie okna oczekiwania jak świadomej pozycji: skoro środowisko jest stabilne i nie ma pilnego wyzwalacza regulacyjnego, firma kupuje sobie czas na lepsze przygotowanie zakresu, uporządkowanie danych i przemyślenie procesów docelowych, zamiast biernie odkładać nieuniknione. Jeśli natomiast na horyzoncie majaczy duża zmiana biznesowa, argument za czekaniem jest jeszcze mocniejszy, bo migracja przeprowadzona tuż przed przejęciem czy zmianą modelu operacyjnego oznacza ryzyko podwójnej pracy — najpierw odwzorowania obecnych procesów, a potem ich natychmiastowej przebudowy pod nową rzeczywistość.

Czego zostania przy AX nie usprawiedliwia, to brak decyzji. Ryzyko nie maleje z czasem, tylko rośnie: starzeje się infrastruktura, znika dostęp do specjalistów AX na rynku, a każda kolejna zmiana prawa to następna łatka do utrzymania. „Zostajemy” może więc znaczyć „migrujemy za dwa kwartały”, ale nie „nie zajmujemy się tym”. Różnica między tymi dwoma znaczeniami jest w istocie różnicą między pozycją zarządzaną a ryzykiem porzuconym. Pauza jest do obrony tylko dopóty, dopóki firma aktywnie zarządza jej kosztem — utrzymuje aktualną dokumentację, dywersyfikuje kompetencje wokół AX, monitoruje kalendarz regulacyjny i traktuje każdy kwartał zwłoki jako pozycję z ceną, a nie jako darmowy odpoczynek.

Pomocna jest tu prosta dyscyplina decyzyjna: zapisać warunki, które automatycznie zamykają okno oczekiwania, i wskazać osobę odpowiedzialną za ich pilnowanie. Takim warunkiem może być ogłoszenie sztywnej daty obowiązku regulacyjnego, awaria kluczowego komponentu sprzętowego, odejście osoby o krytycznej wiedzy albo pojawienie się integracji, której partner po drugiej stronie nie będzie już utrzymywał w starym formacie. Gdy którykolwiek z tych warunków się ziści, „czekamy” przestaje być opcją i firma powinna mieć wtedy gotowy plan, a nie zaczynać analizę od zera, bo w tym momencie traci już luksus wyboru terminu.

‍

Kiedy migrować teraz

Są sygnały, po których widać, że nie ma na co czekać. Migrację warto zacząć bez zwłoki, gdy pojawia się zmiana regulacyjna, której w AX nie da się rozsądnie obsłużyć, gdy psują się integracje z otoczeniem, gdy zbliża się wymiana serwerów lub centrum danych, albo gdy firma rośnie, wchodzi na nowe rynki i potrzebuje rolloutu w kolejnych krajach. Osobnym, coraz częstszym powodem jest kadra: zespołów utrzymujących AX jest na rynku coraz mniej, a ich czas coraz droższy.

Te sygnały łączy wspólny mianownik: każdy z nich zamienia migrację z decyzji odkładalnej w decyzję wymuszoną, a decyzja wymuszona jest zawsze droższa i bardziej ryzykowna niż zaplanowana, bo odbiera firmie możliwość wyboru terminu, wykonawcy i zakresu. Dlatego warto myśleć o nich jak o wczesnych ostrzeżeniach, a nie jak o alarmie, który dopiero wtedy uruchamia projekt. Najgroźniejszy z ekonomicznego punktu widzenia jest scenariusz, w którym kilka sygnałów pojawia się jednocześnie — na przykład twardy termin regulacyjny zbiega się z awarią infrastruktury i odejściem kluczowego specjalisty — ponieważ wtedy firma musi przeprowadzić przedsięwzięcie o dużej złożoności pod presją czasu, płacąc premię za pośpiech na każdym etapie: za dostępność konsultantów, za skrócone testy i za ryzyko, którego w spokojnym harmonogramie dałoby się uniknąć.

Rozsądny model decyzyjny nie czeka więc, aż sygnałów będzie wiele, tylko traktuje pierwszy z nich jako moment uruchomienia analizy, dzięki której firma zachowuje kontrolę nad kosztem i tempem zmiany. Jeśli zastanawiasz się, czy w Twojej firmie już czas na migrację, porozmawiajmy o przejściu z Dynamics AX na Dynamics 365. Ocena środowiska, integracji i customizacji zwykle pokazuje, czy migrować teraz, czy zaplanować ją na konkretny kwartał. Sama taka ocena ma wartość niezależną od terminu migracji, ponieważ zamienia rozproszone przeczucia w policzalny rejestr: które integracje są krytyczne, ile z customizacji zastąpi standard nowego systemu, jakie dane trzeba przenieść w trybie gorącym, a jakie można zarchiwizować.

Taki rachunek pozwala zarządowi podjąć decyzję na liczbach, a nie na wrażeniu, i — co równie istotne — pokazuje koszt bezczynności w tym samym języku co koszt projektu, dzięki czemu obie strony równania stają się porównywalne. Bez tego zestawienia dyskusja zwykle grzęźnie na widocznej cenie migracji, podczas gdy droższa, lecz niewidoczna strona bilansu — koszt trwania — pozostaje nieoszacowana i przez to systematycznie niedoceniana. Ujęta w tych kategoriach migracja Dynamics AX do 365 przestaje być wydatkiem do uzasadnienia, a staje się przesunięciem ryzyka i kosztu na korzystniejszą, bardziej przewidywalną pozycję.

‍

Migracja to nie upgrade

Najkosztowniejszy błąd w planowaniu bierze się z jednego słowa. „Upgrade” sugeruje, że przejście z AX na Dynamics 365 to techniczna aktualizacja wersji. W rzeczywistości to ponowne wdrożenie z bardzo dobrym punktem startu. Trzeba na nowo przemyśleć architekturę, przenieść i oczyścić dane oraz skonfrontować dawne customizacje ze standardem nowego systemu, bo część z nich Dynamics 365 realizuje już bez kodu. To rozróżnienie ma bezpośrednie przełożenie na budżet i harmonogram, dlatego warto je doprecyzować. W teorii istnieją dwie drogi: techniczne przeniesienie „jeden do jednego”, które próbuje odtworzyć stare rozwiązanie na nowej platformie, oraz ponowne wdrożenie, które wykorzystuje migrację do uproszczenia procesów i porzucenia obejść nagromadzonych przez lata.

Pierwsza droga kusi pozorną szybkością, ale przenosi na nową platformę cały dług technologiczny starego systemu — a dług ten zachowuje się jak procent składany: każde obejście utrzymywane „na teraz” podnosi koszt każdej przyszłej zmiany, bo mnoży zależności, które trzeba uwzględnić przy kolejnej modyfikacji. Ponowne wdrożenie kosztuje więcej na wejściu, lecz spłaca ten dług, zamiast przenosić go dalej z odsetkami. Dlatego „upgrade” jest błędnym modelem myślowym nie z powodów semantycznych, tylko dlatego, że narzuca oczekiwanie niskiego kosztu i wysokiej wierności odwzorowania, podczas gdy największą wartość migracji tworzy właśnie to, czego się przy odwzorowaniu nie robi — rezygnacja z rozwiązań, które w standardzie nowego systemu są już zbędne, oraz decyzja, których lat historii danych nie trzeba przenosić w trybie produkcyjnym.

Skalę tej pracy widać po integracjach. W środowiskach AX prowadzonych przez ANEGIS, na przykład u producenta stali nierdzewnej OSTP w Polsce i Szwecji, system łączył się z produkcyjnym MES, planowaniem łańcucha dostaw i wymianą dokumentów EDI. Każdy taki interfejs to osobny fragment projektu migracyjnego, a nie pole do zaznaczenia. Dlatego zamiast myśleć „aktualizujemy AX”, lepiej potraktować to jak wdrożenie z gotowym fundamentem i zaplanować migrację do Dynamics 365 fazami. Prowadzi to do wniosku, który przewraca typowy plan projektu: rzeczywistym zakresem migracji nie jest rdzeń ERP, tylko warstwa integracji.

Sam moduł finansowy czy magazynowy w Dynamics 365 jest w dużej mierze standardem, który da się skonfigurować w przewidywalnym czasie; to interfejsy do MES, EDI, systemów planowania łańcucha dostaw, bankowości i platform partnerów handlowych stanowią o rzeczywistej złożoności i pochłaniają większość ryzyka. Każdy z tych interfejsów bywał budowany latami pod konkretne wersje protokołów i założenia po obu stronach, a jego odtworzenie na nowej platformie wymaga nie tylko przepisania kodu, lecz także ponownego uzgodnienia kontraktu danych z partnerem, który po drugiej stronie łącza często sam nie planował zmian. Dlatego oszacowanie migracji, które liczy głównie moduły ERP, a integracje traktuje jako dodatek, systematycznie zaniża zakres. Zespół, który przeszedł to wcześniej, wie, że mapę integracji trzeba wykonać na samym początku, bo to ona, a nie liczba użytkowników, wyznacza czas trwania i profil ryzyka całego przedsięwzięcia.

Osobnej decyzji wymaga historia danych, bo to ona potrafi po cichu zawyżyć koszt i wydłużyć migrację. Nie każdy rok transakcji musi trafić do nowego systemu w trybie produkcyjnym — przenoszenie pełnej, wieloletniej historii „na gorąco” podnosi koszt migracji, obciąża wydajność i utrudnia oczyszczenie danych, a rzadko przynosi wartość proporcjonalną do nakładu. Dojrzały model rozdziela dane na te, które są potrzebne operacyjnie i podatkowo w bieżącej pracy, oraz te, które wystarczy zachować w tańszym archiwum dostępnym na żądanie. Granicę wyznaczają tu wymogi prawne dotyczące okresów przechowywania oraz rzeczywista częstość sięgania do starych rekordów, a nie odruch „przenieśmy wszystko na wszelki wypadek”.

Taka decyzja ma wymiar zarówno kosztowy, jak i zgodnościowy: archiwum musi pozostać czytelne i możliwe do udostępnienia audytorowi czy organowi podatkowemu przez cały wymagany okres, ale nie musi obciążać środowiska produkcyjnego. Świadome rozdzielenie danych gorących od zimnych jest jednym z niewielu miejsc, w których dobrze przeprowadzona migracja obniża koszt na starcie, zamiast go podnosić. Warto przy tym wybrać wykonawcę, który zna AX od podszewki, a nie tylko nowy system. ANEGIS jako Microsoft Solutions Partner w obszarze Business Applications ma za sobą jedno z największych wdrożeń Dynamics AX na świecie i prowadzi przejścia z AX do Dynamics 365, co przy tego typu projekcie skraca analizę i ogranicza ryzyko.

Praktyczne pytania i odpowiedzi zebraliśmy też w osobnym artykule o migracji z Dynamics AX do Dynamics 365. Wybór wykonawcy łączy się bezpośrednio ze strategią przejścia, a ta w projektach tej skali rzadko bywa jednorazowym przełączeniem. Częściej stosuje się cutover fazowy, w którym przez pewien czas AX i Dynamics 365 działają równolegle — jedne procesy lub spółki już na nowym systemie, inne wciąż na starym. Taki model obniża ryzyko pojedynczego, nieodwracalnego przełączenia, ale ma własną cenę: trzeba utrzymywać i synchronizować dwa środowiska naraz, pilnować spójności danych między nimi i pogodzić się z tym, że przez okres przejściowy koszt bieżący jest wyższy niż w którymkolwiek stanie docelowym.

Wykonawca znający obie platformy potrafi ten okres skrócić i tak zaprojektować granice faz, by minimalizować liczbę interfejsów pomostowych budowanych wyłącznie na czas współistnienia systemów, bo każdy taki pomost to koszt, który trzeba ponieść i później wycofać. To kolejny powód, dla którego znajomość samego AX, a nie wyłącznie nowego systemu, przekłada się wprost na koszt i długość projektu, a także na to, jak gładko firma przejdzie przez najbardziej wrażliwy etap całej zmiany.

‍

‍