Wiele firm korzystających z Dynamics NAV lub starszych wersji Dynamics 365 Business Central stoi dziś przed podobnym pytaniem: czy modernizować system już teraz, czy jeszcze poczekać?
Odpowiedź nie jest jednoznaczna. Nie każda organizacja musi natychmiast przechodzić do modelu SaaS, a sam projekt migracyjny nie powinien być traktowany wyłącznie jako aktualizacja technologiczna. Jednocześnie coraz więcej przedsiębiorstw dostrzega, że koszt utrzymywania starszych środowisk ERP rośnie, a dostęp do nowych funkcji, integracji oraz możliwości wykorzystania AI pozostaje ograniczony.
W tym artykule wyjaśniamy, czym różnią się poszczególne typy projektów migracyjnych, jakie ryzyka wiążą się z pozostawaniem na starych wersjach NAV i Business Central oraz jak podejść do decyzji w sposób racjonalny i biznesowy.
Dlaczego warto przejść do chmury?
Microsoft rozwija Dynamics 365 Business Central w modelu ciągłych aktualizacji. W przypadku Business Central Online nowe funkcje, poprawki i aktualizacje są dostarczane w ramach regularnych wydań, a Microsoft publikuje dwa główne cykle aktualizacji rocznie.
Dla wersji Business Central on-premises od wersji 15 obowiązuje Modern Lifecycle Policy. Oznacza to konieczność utrzymywania systemu na wspieranych wersjach zgodnie z polityką aktualizacji Microsoft.
Jednocześnie wiele firm nadal pracuje na Dynamics NAV 2016, 2017 lub 2018, Business Central 14, starszych środowiskach z dużą liczbą modyfikacji albo rozwiązaniach utrzymywanych przez wiele lat bez większej modernizacji.
Sama obecność starszej wersji nie oznacza jeszcze problemu. Problem pojawia się wtedy, gdy ogranicza ona rozwój procesów biznesowych, integracji lub bezpieczeństwa środowiska.
Aktualizacja, migracja czy ponowne wdrożenie? Różnice
Aktualizacja systemu
Aktualizacja oznacza przejście pomiędzy wspieranymi wersjami produktu przy zachowaniu istniejącej konfiguracji i procesów.
Przykład hipotetyczny: firma korzysta z Business Central on-premises i aktualizuje środowisko do nowszej wersji, zachowując dotychczasowy model działania.
Migracja techniczna
Migracja techniczna polega na przeniesieniu środowiska do nowej platformy lub architektury. W takim projekcie kluczowe są infrastruktura, bezpieczeństwo, integracje oraz zgodność rozszerzeń.
Przykład hipotetyczny: przejście z Business Central on-premises do Business Central Online.
Migracja danych
Migracja danych skupia się na przeniesieniu kartotek, bilansu otwarcia, sald, dokumentów, wybranych danych historycznych i danych referencyjnych. Największym wyzwaniem zwykle nie jest samo przeniesienie danych, lecz ich jakość.
Ponowne wdrożenie (reimplementation)
To najbardziej złożone podejście. Firma wykorzystuje projekt do przebudowy procesów, ograniczenia historycznych modyfikacji, uporządkowania danych i wdrożenia nowych funkcjonalności. Nie zawsze jest konieczne, ale bywa uzasadnione w organizacjach korzystających z mocno zmodyfikowanych środowisk NAV.
On-premises czy SaaS? Porównanie najważniejszych aspektów
| Obszar | On-premises | Business Central Online (SaaS) |
|---|---|---|
| Infrastruktura | Po stronie klienta | Platforma utrzymywana przez Microsoft |
| Aktualizacje | Organizacja planuje i wykonuje | Microsoft wdraża aktualizacje usługi; administrator zarządza oknami aktualizacji |
| Utrzymanie serwerów | Własna odpowiedzialność | Nie wymaga utrzymywania serwerów aplikacyjnych Business Central przez klienta |
| Skalowalność | Zależna od własnej infrastruktury | Realizowana w modelu usługi |
| Dostęp zdalny | Zależny od architektury wdrożenia | Dostęp przez usługę online |
| Bezpieczeństwo platformy | W dużej części po stronie organizacji | Model współdzielonej odpowiedzialności |
| Integracje z usługami Microsoft | Możliwe, zależne od wersji i architektury | Projektowane dla środowiska chmurowego |
| Rozszerzenia AL | Tak w aktualnych wersjach | Tak |
| Model kosztowy | Infrastruktura, licencje i utrzymanie | Subskrypcja oraz koszty wdrożenia i rozszerzeń |
Porównanie nie oznacza, że SaaS zawsze jest lepszym wyborem. Decyzja powinna wynikać z wymagań biznesowych, regulacyjnych, integracyjnych i kosztowych konkretnej organizacji.
Kiedy on-premises nadal ma uzasadnienie?
Choć rynek wyraźnie zmierza w kierunku chmury, istnieją sytuacje, w których model on-premises nadal może być uzasadniony. Najczęściej dotyczy to organizacji:
- posiadających szczególne wymagania regulacyjne lub kontraktowe dotyczące środowiska,
- korzystających z integracji silnie zależnych od infrastruktury lokalnej,
- wykorzystujących rozwiązania, których przeniesienie wymagałoby nieproporcjonalnej przebudowy,
- realizujących procesy wymagające szczególnej kontroli nad środowiskiem i cyklem aktualizacji.
W takich przypadkach celem nie musi być migracja do SaaS. Racjonalnym scenariuszem może być przejście na aktualną, wspieraną wersję Business Central on-premises.
Ryzyka pozostawania na starszych wersjach systemów ERP
Nie chodzi o straszenie końcem świata. Chodzi o świadome zarządzanie ryzykiem i ustalenie, czy obecna wersja nadal spełnia wymagania organizacji.
Rosnące koszty utrzymania
Im starsza wersja, tym mniejsza dostępność specjalistów znających dane rozwiązanie, trudniejsze aktualizacje i większy koszt utrzymania historycznych modyfikacji.
Ograniczenia integracyjne
Współczesne środowiska biznesowe coraz częściej wymagają integracji z platformami e-commerce, systemami B2B, Power Platform, usługami analitycznymi i Power BI. W starszych środowiskach takie połączenia są często realizowane przez własny kod rozwijany przez lata.
Utrudnione aktualizacje
Odkładanie modernizacji może zwiększać złożoność kolejnego projektu. Z czasem rośnie liczba zależności, zmian w kodzie, integracji i danych wymagających analizy.
Ograniczony dostęp do nowych funkcji
Microsoft rozwija Business Central przede wszystkim w aktualnych wersjach produktu. Nowe i zmieniane możliwości są publikowane w kolejnych falach wydań oraz aktualizacjach.
Największy wpływ na projekt mają modyfikacje i rozszerzenia
W większości projektów migracyjnych technologia nie stanowi jedynego ani największego wyzwania. Szczególnej uwagi wymagają własne modyfikacje. W starszych wdrożeniach NAV często spotyka się zmiany bez pełnej dokumentacji, kod tworzony przez wielu partnerów oraz rozwiązania rozwijane przez wiele lat.
Jak wygląda sytuacja w Business Central?
Nowoczesny model rozwoju Business Central opiera się na rozszerzeniach tworzonych w języku AL. Oddzielenie rozszerzeń od aplikacji bazowej może ułatwiać aktualizacje i ograniczać konflikty, ale nie zwalnia z testowania kompatybilności.
Nie każdą modyfikację należy przepisywać 1:1. Migracja jest dobrym momentem, aby ustalić, czy daną potrzebę pokrywa standard Business Central, konfiguracja, Power Platform, Power BI, rozszerzenie partnerskie albo rozwiązanie branżowe. Dopiero brak adekwatnej opcji uzasadnia przygotowanie nowego rozszerzenia.
Dlaczego analiza danych jest ważniejsza niż sama migracja?
W wielu projektach największe ryzyko kryje się nie w systemie, lecz w danych. Przykładowe problemy to duplikaty kontrahentów, nieaktualne kartoteki, błędne jednostki miary i niejednoznaczne słowniki. Jeżeli dane zostaną przeniesione bez weryfikacji, nowy system odziedziczy stare problemy.
Analiza procesów
Równie ważne jest zrozumienie, jak pracują użytkownicy, które procesy faktycznie są używane i gdzie występują obejścia poza system ERP. Na tym etapie często ujawniają się rzeczywiste źródła problemów organizacyjnych.
Analiza integracji
Przed migracją należy zinwentaryzować integracje bankowe, systemy magazynowe, platformy e-commerce, rozwiązania EDI, raportowanie Power BI i automatyzacje Power Platform. Dla każdego połączenia trzeba ustalić właściciela, zakres danych, częstotliwość wymiany, sposób uwierzytelniania i kryteria testów.
Część potrzeb może pokrywać standard Business Central. Inne wymagają konfiguracji, Power Platform, Power BI, rozszerzenia partnerskiego, rozwiązania branżowego albo indywidualnej integracji. Rozstrzygnięcie powinno nastąpić w analizie, a nie na podstawie ogólnej prezentacji funkcji.
Jak wygląda projekt migracji?
Nie istnieje jeden wiarygodny harmonogram dla każdej organizacji. Zakres zależy od wersji źródłowej, jakości danych, liczby firm, modyfikacji, integracji i gotowości użytkowników. Typowy projekt obejmuje jednak poniższe etapy:
- Analiza przedwdrożeniowa — cele biznesowe, procesy, integracje, rozszerzenia, dane i ograniczenia architektoniczne.
- Projekt rozwiązania — architektura, zakres konfiguracji, sposób migracji danych i podejście do rozszerzeń.
- Budowa środowiska — konfiguracja, przygotowanie integracji i rozszerzeń oraz środowisk testowych.
- Migracje próbne — testowe przeniesienie danych, uzgodnienie wyników i korekta reguł migracyjnych.
- Testy — testy funkcjonalne, integracyjne, uprawnień, raportów i scenariuszy krytycznych.
- Przygotowanie uruchomienia — plan przełączenia, odpowiedzialności, komunikacja i procedury awaryjne.
UAT, szkolenia i hypercare, a jakość uruchomienia?
UAT (User Acceptance Testing)
Testy akceptacyjne użytkowników pozwalają zweryfikować, czy rozwiązanie wspiera rzeczywiste procesy biznesowe. Kryteria akceptacji powinny być określone przed testami, a wyniki udokumentowane. Gotowość rozwiązania powinni oceniać właściciele procesów wraz z zespołem zarządzania projektem.
Szkolenia
Szkolenia należy dopasować do ról i scenariuszy pracy. Sam pokaz ekranów nie wystarcza, jeżeli użytkownik nie rozumie nowego przebiegu procesu, odpowiedzialności i sposobu reagowania na wyjątki.
Plan przełączenia (cutover)
Plan przełączenia powinien określać kolejność działań, odpowiedzialności, moment zatrzymania operacji w starym systemie, zakres końcowej migracji, walidację oraz procedury awaryjne.
Hypercare
Hypercare to okres wzmożonego wsparcia bezpośrednio po uruchomieniu produkcyjnym. Pomaga sprawnie klasyfikować pytania i błędy, wyznaczać priorytety oraz stabilizować codzienną pracę.
Checklista gotowości firmy do migracji systemu
- Czy znamy wszystkie aktywne integracje systemu?
- Czy mamy listę wykorzystywanych modyfikacji i ich właścicieli biznesowych?
- Czy wiemy, które modyfikacje są nadal potrzebne?
- Czy dane podstawowe zostały zweryfikowane?
- Czy mamy właścicieli procesów biznesowych?
- Czy użytkownicy zostali zaangażowani w projekt?
- Czy przygotowano strategię i kryteria testów UAT?
- Czy określono zakres historii danych do przeniesienia?
- Czy istnieje plan przełączenia produkcyjnego?
- Czy określono zasady wsparcia po uruchomieniu?
- Czy organizacja ma jasno zdefiniowane cele biznesowe migracji?
Im więcej odpowiedzi „tak”, tym lepiej organizacja rozumie punkt wyjścia. Odpowiedź „nie” nie przekreśla projektu, ale wskazuje obszar, który trzeba przeanalizować przed podjęciem zobowiązań zakresowych i kosztowych.
Najczęstsze obawy przed migracją
„Stracimy dane”
Dobrze zaplanowana migracja obejmuje migracje próbne, uzgodnienie sald i walidację danych według wcześniej ustalonych kryteriów.
„Musimy przepisać wszystko od zera”
Nie zawsze. Część potrzeb może być pokryta standardem lub konfiguracją, część istniejących rozszerzeń można dostosować, a część wyeliminować po analizie biznesowej.
„Migracja do chmury oznacza utratę kontroli”
SaaS zmienia podział odpowiedzialności za platformę i aktualizacje, ale nie odbiera organizacji odpowiedzialności za procesy, dane, uprawnienia, rozszerzenia i testy.
„To tylko problem IT”
ERP łączy finanse, sprzedaż, zakupy, magazyn, produkcję, serwis i raportowanie. Decyzje projektowe powinny więc angażować biznes, finanse, operacje i IT.
„Nasza firma jest zbyt specyficzna”
Unikalne wymagania są częste, ale każde z nich warto zweryfikować: czy wynika z przewagi biznesowej, regulacji, ograniczenia poprzedniego systemu czy przyzwyczajenia.
„Nie jesteśmy jeszcze gotowi”
To może być trafna ocena. Warto jednak nazwać braki i przygotować plan ich usunięcia, zamiast odkładać decyzję bez analizy.
Podsumowanie
Migracja NAV do Business Central nie jest celem samym w sobie. Dobrze przygotowany projekt powinien ograniczyć ryzyko technologiczne, uporządkować dane, uprościć utrzymanie oraz stworzyć warunki do dalszych integracji i rozwoju procesów.
Nie każda firma musi przechodzić do modelu SaaS. W niektórych przypadkach aktualny Business Central on-premises pozostanie właściwym wyborem. Najważniejsze jest świadome podjęcie decyzji na podstawie analizy danych, procesów, integracji, modyfikacji, odpowiedzialności i kosztów utrzymania obecnego środowiska.
Jeżeli rozważasz migrację z NAV lub starszej wersji Business Central, konsultacja z NMI ERP może pomóc uporządkować możliwe scenariusze, ryzyka i zakres analizy bez zakładania z góry jednego modelu docelowego.
FAQ
Czy migracja NAV do Business Central zawsze oznacza przejście do chmury?
Nie. Możliwe jest również przejście do aktualnej wersji Business Central on-premises, jeżeli odpowiada to wymaganiom organizacji.
Czym różni się aktualizacja od migracji?
Aktualizacja dotyczy przejścia do nowszej wersji systemu. Migracja może dodatkowo obejmować zmianę platformy, architektury, modelu utrzymania lub zakresu danych.
Czy wszystkie modyfikacje można przenieść do Business Central?
Nie można tego założyć bez analizy. Każda modyfikacja wymaga oceny technicznej i biznesowej, a część może zostać zastąpiona standardem, konfiguracją lub rozwiązaniem partnerskim.
Czy migracja danych obejmuje całą historię systemu?
Nie musi. Zakres historii zależy od potrzeb operacyjnych, raportowych, audytowych i technicznych oraz od przyjętej strategii projektu.
Jakie ryzyko niesie pozostanie na starszym NAV?
Najczęstsze obszary ryzyka to koszty utrzymania, dostępność kompetencji, ograniczenia integracyjne, bezpieczeństwo zależne od całego środowiska oraz rosnąca złożoność przyszłej modernizacji.
Czy Business Central Online aktualizuje się automatycznie?
Microsoft dostarcza aktualizacje usługi Business Central Online. Administratorzy zarządzają ustawieniami i oknami aktualizacji środowisk zgodnie z możliwościami opisanymi w dokumentacji Microsoft.
Czy Power BI jest standardem Business Central?
Business Central oferuje integrację z Power BI, ale zakres raportowania, przygotowanie modeli danych, konfiguracja, uprawnienia i licencjonowanie wymagają oceny dla konkretnego scenariusza.
Kiedy warto rozważyć ponowne wdrożenie zamiast zwykłej migracji?
Gdy obecny system zawiera wiele historycznych modyfikacji, dane są nieuporządkowane, a procesy wymagają przebudowy. Decyzję należy poprzedzić analizą kosztów, ryzyk i wpływu na organizację.
