Mange danske virksomheder har et forhold til Navision, som minder om en gammel varebil: Den starter hver morgen, den kan det nødvendige, og den har været betalt af i årevis. Derfor står der stadig Dynamics NAV installationer rundt omkring, fra NAV 2009 og frem til NAV 2018, ofte med mange års tilpasninger, rapporter og integrationer bygget ind i hverdagen.
Spørgsmålet er sjældent, om den “kan køre”. Det kan den typisk. Spørgsmålet er, om den kan køre sikkert, stabilt og lovmedholdeligt, når den officielle support stopper, når serveren skal opdateres, eller når en kritisk fejl rammer midt i månedsafslutningen.
Hvilke gamle Navision-versioner findes stadig i drift?
I praksis møder man alt fra NAV 2009 Classic/RTC til NAV 2013, NAV 2015 og NAV 2016. I nogle miljøer kører meget ældre Navision-løsninger stadig, men de mest udbredte “gamle” platforme i dag ligger typisk i perioden 2009 til 2016, fordi de blev implementeret bredt i danske SMV’er, især i handel, produktion og projektdrevne virksomheder.
Det, der holder liv i de gamle versioner, er sjældent nostalgi. Det er en kombination af stabil drift, kendte processer, stor historik i databasen, samt tilpasninger som ingen har lyst til at røre ved uden en plan.
En anden årsag er timing: Mange har udskudt skiftet, fordi systemet har passet forretningen “godt nok”, indtil krav om integrationer, rapportering, sikkerhed eller nye arbejdsformer langsomt flytter grænsen for, hvad “godt nok” betyder.
Support: hvad betyder “understøttet” egentlig?
Når man taler support til Navision/NAV, er det værd at skelne mellem to ting: officiel produkt-support og praktisk driftssupport.
Officiel support følger en fast livscyklus. Når en version forlader udvidet support, kommer der normalt ikke flere sikkerhedsrettelser, hotfixes eller kumulative opdateringer til selve produktet. Man kan stadig få hjælp hos en partner, men partneren kan ikke trylle nye produktpatches frem fra producenten.
Det er her, mange oplever et skifte i hverdagen: fra “vi opdaterer løbende” til “vi holder det kørende, mens vi styrer risikoen”.
Efter man har fået styr på begreberne, kan det være nyttigt at tænke support som en række konkrete leverancer:
- Sikkerhedsrettelser: Leveres kun til versioner inden for den officielle supportperiode
- Kumulative opdateringer: Samlede rettelser, der typisk kræver test af tilpasninger og integrationer
- Fejlretning i kundespecifik kode: Kan ofte laves af en partner, selv når produktet er udgået
- Teknisk drift: Backup, overvågning, SQL vedligehold, planlagte genstarter, kapacitetsstyring
Livscyklus i tal (udvalgte NAV-versioner)
Lifecycle-siderne på Microsoft Learn er den mest pålidelige kilde til datoer. Her er et hurtigt overblik over udvidet support for udvalgte versioner, som stadig findes i mange virksomheder:
Support-overblik (udvidet support)
- NAV 2013: januar 2023
Kilde: https://learn.microsoft.com/en-us/lifecycle/products/dynamics-nav-2013- NAV 2015: januar 2025
Kilde: https://learn.microsoft.com/en-us/lifecycle/products/dynamics-nav-2015- NAV 2016: april 2026
Kilde: https://learn.microsoft.com/en-us/lifecycle/products/dynamics-nav-2016- NAV 2017: januar 2027
Kilde: https://learn.microsoft.com/en-us/lifecycle/products/dynamics-nav-2017- NAV 2018: januar 2028
Kilde: https://learn.microsoft.com/en-us/lifecycle/products/dynamics-nav-2018
Hvis man sidder på NAV 2013 eller ældre, er man typisk allerede uden officiel produkt-support. Har man NAV 2015, er vinduet meget snævert. NAV 2016 til 2018 giver lidt mere tid, men tiden bør bruges til at planlægge, ikke til at håbe.
Når officiel support er væk: hvad kan man stadig få hjælp til?
Når produktet er udgået, flytter “support” karakter. Det bliver mindre et spørgsmål om opdateringer og mere et spørgsmål om viden, beredskab og kontrollerede ændringer.
Danske konsulenthuse tilbyder ofte fortsat drift og vedligehold af gamle NAV-miljøer, typisk via serviceaftaler eller klippekort. Et eksempel er Naviteam, der beskriver, at de hjælper med drift, opgraderinger og tilpasninger på eksisterende Navision-løsninger (kilde: https://navi-team.com/).
Efter man har accepteret begrænsningen om manglende producentpatches, kan en solid tredjeparts supportaftale stadig give stor værdi:
- Fejlsøgning ved driftsstop
- Vedligehold af tilpasninger
- Rådgivning om server, SQL, backup
- Hjælp til datatræk og rapportering
- Afklaring af integrationsfejl
Det, man typisk ikke kan få, er nye officielle sikkerhedsrettelser til selve NAV-platformen, hvis versionen er uden for support. Derfor bliver sikkerhed i højere grad et spørgsmål om miljøet rundt om systemet: netværk, adgangsstyring, logging, serverhardening, segmentering, backup og beredskabsplan.
De typiske risici ved at blive på en gammel NAV
Mange oplever, at NAV “bare kører”, lige indtil en ændring uden for NAV rammer. Det kan være en Windows-opdatering, en ny SQL-version, nye krav til kryptering, en ændring hos en EDI-leverandør eller en ny måde at godkende betalinger på.
Der er især fire risikoområder, der går igen.
Sikkerhed er den mest åbenlyse. Når en version er ude af officiel support, bliver det sværere at dokumentere, at platformen kan holdes opdateret på et niveau, som revisor, kunder eller interne sikkerhedspolitikker forventer.
Compliance og lovkrav kan presse på fra en anden vinkel. Det handler ikke kun om regnskab, men om sporbarhed, adgangslog, databehandling og integrationer til øvrige systemer. Hvis processer “hænger fast” i gammel teknologi, bliver små ændringer pludselig dyre.
Kompetencer er et tredje område. Det kan være udfordrende at finde konsulenter, der stadig arbejder dybt i NAV 2009 Classic eller gamle C/AL-tilpasninger. Risikoen bliver større, hvis viden kun findes hos én person, internt eller eksternt.
Til sidst kommer driftsrisikoen: En gammel applikationsserver, et ældre tredjeparts add-on, eller en integrationskomponent kan være den reelle flaskehals, selv hvis NAV-databasen i sig selv er stabil.
Hvad kan en moderne supportaftale indeholde, selv på gammel NAV?
En god supportmodel handler om at gøre fejl mere sjældne, hurtigere at løse, lettere at forklare. Det kræver struktur, ikke kun timer.
Naviteam arbejder som dansk konsulenthus med implementering, governance, forankring hos brugerne samt løbende udvikling og drift omkring Business Central og eksisterende NAV-løsninger. På gamle platforme er pointen ofte at kombinere stabil drift med en plan, så man ikke bliver låst af akut brandslukning.
En typisk supportaftale giver mest effekt, når den inkluderer en fast rytme: status på drift, prioritering af sager, releaseplan for ændringer, samt klare regler for hvad der må ændres i en gammel løsning.
Det kan være en enkelt sætning i en mail, der gør forskellen: “Vi rører ikke den integration før efter månedsafslutning, og vi tester i kopi først.” Den slags governance lyder banalt, men det er præcis det, der gør et ældre NAV-miljø mere robust.
Plan A og Plan B: stabil drift nu, kontrolleret modernisering senere
Hvis man står med en gammel NAV og spørger “hvad gør vi?”, er et praktisk svar at lave to spor: et drifts- og risikospor (Plan A) og et moderniseringsspor (Plan B). Så har man ro til at træffe beslutninger, mens systemet kører.
En enkel måde at strukturere arbejdet på:
- Kortlæg version, infrastruktur og kritiske integrationer (inkl. add-ons og batchjobs).
- Gennemgå tilpasninger: hvad er forretningskritisk, hvad er “nice to have”, hvad kan udfases.
- Etabler basis for sikker drift: backupstrategi, adgangsstyring, overvågning, patch-regime for server og SQL.
- Byg en realistisk opgraderings- eller migreringsplan med milepæle, test og cutover-principper.
- Træn superbrugere løbende, så viden ikke samler sig ét sted.
Det er sjældent nødvendigt at beslutte alt fra dag ét. Man kan godt starte med at få kontrol over drift og data, derefter tage stilling til retning.
Opgradering eller reimplementering: hvad peger pilen på?
Mange tror, at valget står mellem “at blive” eller “at skifte alt”. Der findes mellemveje, men det rigtige valg afhænger af hvor tungt systemet er tilpasset, hvor meget teknisk gæld der er, samt hvor stærkt man vil standardisere processer.
Her er en simpel beslutningshjælp, der kan bruges i en workshop:
Pejlemærker til valg af tilgang
Opgradering passer ofte når
- Kernen i processerne er sund, tilpasninger er velbeskrevne
- Datakvaliteten er høj, kontoplan og opsætning giver mening
- Man vil bevare mest muligt af nuværende måde at arbejde på
Reimplementering passer ofte når
- Tilpasninger er mange, uigennemsigtige, skabt over mange år
- Processer skal ændres markant, flere arbejdsgange skal standardiseres
- Man vil udnytte standardfunktioner i Business Central frem for at genskabe fortiden
Flere vælger at kombinere: Man migrerer data og udvalgte historikker, rydder op i processer, og bygger det nødvendige tilbage i en mere opgraderbar form med governance omkring ændringer og add-ons.
Hvis du sidder på en gammel NAV-version og har brug for support her og nu, er det ofte muligt at etablere en stabil driftsmodel relativt hurtigt. Den store gevinst kommer, når supporten ikke kun handler om at svare på fejl, men om at skabe kontrol: over kode, integrationer, releases, test og brugeradoption. Det gør den næste beslutning langt lettere, uanset om næste skridt bliver NAV 2018, en overgang til Business Central, eller en mere grundlæggende modernisering.