Microsoft NAV, czyli Dynamics NAV, to system ERP, który przez lata porządkował finanse, zakupy, sprzedaż, magazyn i produkcję w firmach średniej wielkości. Dziś najważniejsze pytanie nie brzmi już wyłącznie, czym ten system jest, ale jak bezpiecznie go utrzymać, kiedy przesiąść się na nowszą platformę i co zrobić z lokalnymi dostosowaniami. W tym tekście pokazuję to praktycznie: od roli NAV w firmie, przez status wsparcia w 2026 roku, po ścieżkę migracji i typowe pułapki.
Najważniejsze fakty o Dynamics NAV w 2026 roku
- To dojrzały ERP dla firm, które chcą spiąć procesy operacyjne w jednym systemie.
- W 2026 roku NAV 2016 jest już poza wsparciem, NAV 2017 kończy wsparcie 11 stycznia 2027, a NAV 2018 11 stycznia 2028.
- Wspierana migracja prowadzi przez Business Central 14, a następnie przez nowszą wersję on-premises i dopiero dalej do chmury.
- Największym problemem nie jest sama baza danych, tylko customizacje w C/AL, integracje i lokalne raportowanie.
- W praktyce trzeba zdecydować, czy system ma jeszcze tylko dowieźć czas, czy ma stać się pomostem do modernizacji.
Czym jest Dynamics NAV i gdzie leży jego wartość
W praktyce NAV był systemem, który scalał codzienną operację firmy w jednym miejscu. Nie chodziło tylko o księgowość, ale o pełniejszy obraz biznesu: dokumenty sprzedaży, stany magazynowe, zamówienia do dostawców, rozrachunki, planowanie produkcji i raportowanie zarządcze. To właśnie dlatego tak wiele wdrożeń NAV nie było „programem do faktur”, tylko centralnym układem nerwowym przedsiębiorstwa.
Microsoft opisuje ten system jako rozwiązanie dla małych i średnich organizacji, ale ja patrzę na niego szerzej: jako na platformę, która długo dobrze znosiła wzrost złożoności, o ile firma miała uporządkowane procesy. W praktyce najlepiej działał tam, gdzie liczba wyjątków była ograniczona, a dane były prowadzone konsekwentnie. Jeśli ktoś wdrażał go do pracy w produkcji, zwykle liczył na przewidywalność, nie na efektowność interfejsu.
- Finanse - dawały spójny obraz rozrachunków, kosztów i rentowności.
- Magazyn - pozwalał kontrolować przyjęcia, wydania i dostępność towaru.
- Sprzedaż i zakupy - porządkowały obieg dokumentów i relacje z kontrahentami.
- Produkcja - była istotna tam, gdzie trzeba było połączyć BOM, zlecenia i planowanie materiałowe.
Im lepiej firma miała opisany proces, tym większą wartość dawał ten ERP. A kiedy procesów zaczynało przybywać szybciej niż dyscypliny operacyjnej, NAV stawał się bardziej wymagający niż pomocny. To prowadzi naturalnie do pytania, w jakich organizacjach nadal ma sens.
W jakich firmach ten system dawał najwięcej korzyści
Najlepiej sprawdzał się tam, gdzie procesy były powtarzalne, a zarządzanie oparte na danych z kilku podstawowych obszarów. W firmie produkcyjnej oznaczało to zwykle kontrolę nad materiałami, zleceniami, stanami magazynowymi i rozliczeniem kosztów. W dystrybucji dochodziły obsługa wielu lokalizacji, sprzedaż wielokanałowa i integracje z systemami zewnętrznymi.| Obszar | Co porządkował | Dlaczego to było ważne |
|---|---|---|
| Produkcja | Receptury, zlecenia, zużycie materiałów, planowanie | Ułatwiało kontrolę nad kosztami i dostępnością komponentów |
| Magazyn | Przyjęcia, wydania, rezerwacje, stany | Zmniejszało chaos operacyjny i liczbę błędów na wydaniu |
| Finanse | Rozrachunki, płatności, księga główna | Dawało szybki obraz płynności i wyniku |
| Integracje | EDI, sklepy internetowe, BI, systemy logistyczne | Pozwalało spinać ERP z resztą środowiska IT |
Gdy liczba wyjątków rośnie, a każda działka firmy chce własny wyjątek od reguły, system zaczyna się męczyć. Wtedy warto rozróżnić dwie rzeczy: to, co nadal jest zdrowym użyciem ERP, i to, co jest już tylko próbą utrzymania starego modelu za wszelką cenę. I właśnie tu pojawia się temat wsparcia oraz ryzyka dalszej eksploatacji.
Co status wsparcia oznacza w 2026 roku
W dokumentacji Microsoft widać bardzo jasno, że mówimy dziś o platformie z różnym statusem życia w zależności od wersji. To nie jest detal techniczny, tylko granica między systemem, który nadal można utrzymywać, a takim, który powinien już być traktowany jako projekt do wygaszenia lub modernizacji.
| Wersja | Status w 2026 roku | Praktyczny wniosek |
|---|---|---|
| NAV 2016 | Wsparcie zakończyło się 14 kwietnia 2026 | To już obszar pilnego audytu i planu wyjścia |
| NAV 2017 | Wsparcie kończy się 11 stycznia 2027 | Jest jeszcze czas na uporządkowaną migrację, ale okno jest krótkie |
| NAV 2018 | Wsparcie kończy się 11 stycznia 2028 | To ostatni sensowny moment, by zaplanować przejście bez pośpiechu |
Ważne rozróżnienie: koniec wsparcia nie oznacza jedynie braku nowych funkcji. To także brak standardowych poprawek bezpieczeństwa, ograniczona pomoc techniczna i coraz większy problem z kompatybilnością środowiska, integracji oraz zależnych komponentów. W firmie produkcyjnej zwykle najpierw widać to na styku z raportowaniem, integracjami i utrzymaniem infrastruktury.
Jeśli firma nadal pracuje na starszej instalacji, pytanie nie brzmi więc „czy kiedyś przejdziemy”, tylko „czy robimy to planowo, czy po awarii”. A to już prowadzi do konkretnej ścieżki migracji.
Jak wygląda migracja do Business Central bez złudzeń
Najkrótsza wspierana ścieżka nie prowadzi z NAV prosto do chmury. W praktyce trzeba przejść przez Business Central 14 on-premises, następnie przez nowszą wspieraną wersję on-premises i dopiero później do Business Central online. W dokumentacji Microsoft dla migracji wprost widać też, że starsze wersje NAV wymagają etapów pośrednich, zamiast jednej skokowej konwersji.
| Wersja startowa | Wspierana ścieżka | Co to oznacza w praktyce |
|---|---|---|
| NAV 2015-2018 | Business Central 14 on-premises → nowsza wersja on-premises → online | To najczęstsza ścieżka dla firm, które chcą wejść do chmury |
| NAV 2013 / 2013 R2 | NAV 2018 → Business Central 14 → nowsza wersja on-premises → online | Potrzebny jest dodatkowy etap pośredni |
| NAV 2009 SP1 / 2009 R2 | NAV 2013 lub 2015 → NAV 2018 → Business Central 14 → nowsza wersja on-premises → online | To już projekt z większą liczbą kroków i testów |
Są tu dwa podejścia. Pełna migracja przenosi wszystkie dane i dostosowania, ale wymaga konwersji C/AL do rozszerzeń AL. AL to język rozwoju używany w Business Central do rozszerzania systemu bez grzebania w rdzeniu aplikacji. Reimplementacja przenosi tylko dane kluczowe: kartoteki, salda, ustawienia i wybrane dane historyczne. Jest prostsza, ale świadomie zostawia za sobą część starego bagażu.
W polskich projektach największy ciężar zwykle siedzi nie w samej bazie danych, tylko w lokalizacji, raportowaniu podatkowym i integracjach z systemami zewnętrznymi. Właśnie dlatego migrację zaczynam od inwentaryzacji tego, co naprawdę jest krytyczne dla operacji, a nie od samego pytania o wersję ERP. I to prowadzi do najważniejszego źródła problemów: customizacji.
Na co uważać przy utrzymaniu starszej instalacji
Najdroższe w utrzymaniu starego NAV rzadko bywa samo działanie systemu. Koszt generuje wszystko wokół niego: poprawki w kodzie, dodatki, integracje, raporty, wymiany danych i ciche obejścia wdrożone „na chwilę”, które żyją już kilka lat. Z mojego punktu widzenia to właśnie tam powstaje dług technologiczny.
- Customizacje w C/AL - są trudniejsze do rozwijania niż standardowe rozszerzenia i zwykle komplikują migrację.
- Integracje punkt-punkt - im więcej pojedynczych połączeń z innymi systemami, tym większe ryzyko awarii po aktualizacji jednego z nich.
- Jakość danych - stare kartoteki, duplikaty, zamknięte okresy i niejednolite słowniki potrafią zablokować migrację bardziej niż kod.
- Lokalne obowiązki - raportowanie podatkowe, e-fakturowanie i wymogi regionalne trzeba sprawdzić osobno, a nie zakładać, że „jakoś się przeniosą”.
- Infrastruktura - starsze środowiska często zależą od wersji SQL, systemu operacyjnego i komponentów, których nie da się utrzymywać bez końca.
Jeżeli nie ma jeszcze budżetu na zmianę, ustawiłbym minimum operacyjne: cykliczny test odtworzenia kopii, dokumentację wszystkich rozszerzeń, listę integracji z właścicielami biznesowymi i plan reakcji na awarię zamknięcia miesiąca. To nie rozwiązuje problemu, ale ogranicza ryzyko, że system przestanie działać w najgorszym możliwym momencie. A skoro już wiemy, co boli, trzeba odpowiedzieć na pytanie, kiedy jeszcze warto zostać, a kiedy lepiej ruszyć dalej.
Jak rozstrzygam, czy zostać, modernizować czy migrować
Nie patrzę na to jak na wybór między „nowym” a „starym”. Dla mnie ważniejsze jest to, czy system nadal wspiera biznes w przewidywalny sposób, czy tylko opóźnia konieczną zmianę. W praktyce decyzja zwykle sprowadza się do czterech scenariuszy.
| Sytuacja | Co bym zrobił | Dlaczego |
|---|---|---|
| System działa stabilnie, zmian jest mało | Zostałbym chwilowo, ale od razu planowałbym migrację | Masz czas na uporządkowanie procesu, zamiast reagować po awarii |
| Firma ma dużo lokalnych integracji i sprzętu na miejscu | Najpierw modernizacja on-premises, potem dopiero chmura | Zmniejszasz ryzyko operacyjne i nie wywracasz produkcji jednym ruchem |
| Chcesz standardu, zdalnej pracy i mniejszego ciężaru infrastruktury | Przygotowałbym pełną ścieżkę do Business Central online | To zwykle lepszy kierunek niż dalsze dokładanie poprawek do starego rdzenia |
| Wersja jest poza wsparciem lub zaraz z niego schodzi | Traktowałbym migrację jako projekt priorytetowy | Ryzyko techniczne i biznesowe rośnie szybciej niż komfort utrzymania |
Najbardziej praktyczny test, jaki stosuję, jest prosty: jeśli każda zmiana wymaga długiej sesji z programistą, a integracje trzeba utrzymywać „na pamięć”, to system przestaje być przewagą. Jeśli natomiast biznes nadal działa, ale potrzebuje czystszej architektury, wtedy NAV może jeszcze chwilę pełnić rolę pomostu. To właśnie wtedy warto zadać ostatnie, bardzo konkretne pytania o samą organizację pracy.
Co sprawdziłbym przed decyzją w firmie produkcyjnej
W zakładzie produkcyjnym nie zaczynałbym od listy funkcji ERP, tylko od mapy procesów. Najpierw trzeba wiedzieć, co dokładnie system obsługuje dziś, gdzie kończy się standard, a gdzie zaczynają lokalne obejścia. Dopiero wtedy widać, czy migracja jest operacją techniczną, czy reorganizacją całego sposobu pracy.
- Zakres produkcji - czy system naprawdę obsługuje BOM, zlecenia, zużycia i rozliczenie kosztów, czy tylko ich fragment.
- Stany i lokalizacje - czy magazyn działa spójnie między oddziałami, strefami i procesem wysyłki.
- Integracje - czy ERP rozmawia z WMS, MES, e-commerce, BI i bankowością bez ręcznego przepisywania danych.
- Raportowanie lokalne - czy zespół księgowy i controlling ma to, czego potrzebuje do pracy w Polsce.
- Próba generalna - czy potrafisz odtworzyć zamknięcie miesiąca, pełne zlecenie produkcyjne i wysyłkę testową bez improwizacji.
Jeśli te punkty są dobrze opisane, NAV da się jeszcze przez pewien czas utrzymać bez paniki. Jeśli nie są, to system nie jest już tylko ERP, ale zlepkiem zależności, który trzeba uporządkować zanim zacznie przeszkadzać w produkcji i rozliczeniach. W praktyce właśnie tu wygrywa nie najgłośniejsza decyzja, tylko ta, którą da się wdrożyć bez zatrzymania operacji.
