Microsoft stoppede NAV i 2018. Hvornår stopper I?

Det er vist ikke nogen hemmelighed at NAV er på vej ud. Microsoft skiftede navn til Business Central i 2018 og har siden bygget videre udelukkende på BC-platformen. Alle nye funktioner, alle integrationer og al AI-funktionalitet udvikles på BC. De gamle NAV-versioner følger Microsofts officielle udfasning: NAV 2009 er ude af al support, NAV 2016 mistede sin udvidede support i begyndelsen af 2026, og NAV 2018 holder til januar 2028.

Spørgsmålet er hvad I stiller op med det. I denne artikel gennemgår vi hvad “ude af support” konkret betyder, hvilke risici der følger med at vente, hvad et opgraderingsprojekt koster, hvorfor reimplementering er den dyre vej, og hvordan vores tekniske opgraderingsløsning ser ud.

Hvad “ude af support” egentlig betyder

At være ude af support lyder uskyldigt indtil noget går galt. Det betyder i virkeligheden bare: ingen sikkerhedsopdateringer, ingen rettelser når der dukker fejl op og ingen hjælp fra Microsoft. Hvis I sidder på NAV 2013, og en sårbarhed bliver fundet i morgen, så bliver den ikke rettet. Det er bare sådan det er.

Og det er ikke kun Microsoft. ISV’erne, de partnere der laver branchespecifikke add-ons til lager, fakturascanning, EDI, e-faktura, er for længst rykket videre til BC. De fleste vedligeholder ikke længere deres NAV-versioner. Hvis I bruger en lager-add-on til jeres NAV 2016, kan I stadig bruge den. Men jeres add-on får ikke flere opdateringer, og når jeres processer ændrer sig (det gør de jo altid), er der ingen til at tilpasse softwaren.

Læg dertil at NAV-konsulenterne på markedet bliver færre. De erfarne folk er enten gået på pension eller skiftet til BC. C/AL, det gamle udviklingssprog NAV blev bygget i, bliver ikke længere undervist. AL er det nye. Det betyder at hver gang I har brug for en justering i NAV, bliver det dyrere og sværere at finde nogen der både kan og vil.

Risikoen ved at vente

Risikoen er ikke, at noget pludselig holder op med at virke. Din NAV stopper jo ikke fra den ene dag til den anden. Risikoen er noget mere “snigende”.

For det første er der det operationelle. Hvis jeres SQL-server crasher en weekend, hvem sørger så for, at den virker igen? Hvor er backuppen? Har I en udvikler on-call der kan håndtere det? De fleste virksomheder vi taler med, har ikke tænkt så meget på det, før problemet er der. Hvad med de produkter I bruger? Hvad sker der den dag, hvor biblioteker og gammel teknologi bliver udfaset. Når Outlook-opgraderingen forhindrer mail-afsendelsen i at virke eller gammel TLS-teknologi udfases.

For det andet er der compliance. Danske myndigheder rykker hurtigere på e-faktura, Peppol-integrationer og digitale krav fra Skat såsom SAF-T. EU rykker på ESG-rapportering. Når I sidder på en NAV-version uden support, er der ingen automatisk vej til at leve op til de nye krav. Pludselig skal I hyre en NAV-udvikler til at få jeres faktura til at sende sig selv via Peppol. Det kan godt lade sig gøre. Det er bare dyrt.

For det tredje er der integrationsrisikoen. Når jeres bank, jeres webshop eller jeres logistikpartner opgraderer deres systemer, forventer de moderne API’er. NAV taler ikke moderne API’er, i hvert fald ikke uden at I bygger en mellemløsning. Hver integration der i dag virker, kan blive en sårbarhed i morgen.

Og endelig, og måske vigtigst, er der det forretningsmæssige. Jo længere I venter, jo længere er afstanden mellem jeres NAV og en moderne BC-installation. I 2018 kunne man have opgraderet med et begrænset projekt. I 2026 er afstanden større, og den vokser hvert år. På et tidspunkt lukker den enkle opgraderingsvej helt af, og så står I tilbage med re-implementering som eneste mulighed (mere om den fælde længere nede).

Det her er det vigtige at forstå: Prisen for at vente er ikke nul. Den vokser. Hvert år I venter, bliver opgraderingen dyrere, ikke billigere.

Hvad koster det egentlig?

Jeg kan ikke give jer en præcis pris i denne artikel, for det afhænger for meget af hvor I starter, hvor mange brugere I er, hvor mange tilpasninger I har, hvor mange integrationer der skal flyttes, og hvor meget data der skal med over.

Men jeg kan give jer en ramme.

Et opgraderingsprojekt fra NAV til BC SaaS består typisk af tre store udgiftsposter. Den første er selve projektet, den implementering vi som konsulenter laver sammen med jer. Det dækker analyse, datakonvertering, opsætning, vurdering af tilpasninger, integrationer, test og go-live. Den anden er licenserne. BC SaaS er en månedlig pris pr. bruger, så her byttes en stor on-prem-investering ud med en løbende driftsomkostning. Den tredje, og den der ofte glemmes, er jeres egen tid. Superbrugerne, økonomichefen, lagerchefen, IT, de skal alle bruge timer i projektet. Det er den udgift der ikke står på fakturaen, men som I skal regne med.

Eksempel-case:

En virksomhed med omkring 30 brugere, der i dag kører NAV 2016 med et par mindre tilpasninger og to integrationer (én til webshop, én til en lagerterminal). Et sådant projekt kan typisk afvikles på 4-7 måneder med en god projektleder og et engageret team hos jer. Der er en startomkostning til implementering. Der er en løbende månedlig licensomkostning der erstatter den gamle årlige NAV-licens. Og der er jeres interne timeforbrug. Lægger man det hele sammen, er den samlede investering større år ét og lavere år to og frem, typisk lavere end den nuværende drift af NAV når man tæller ikke-fakturerede omkostninger med.

Den vigtigste øvelse er at sammenligne med alternativet. Hvad koster det at blive på NAV i tre, fem, syv år til? Tæl løbende konsulentopgaver med, manuelle workarounds når noget ikke virker, manglende ESG- og e-faktura-funktionalitet, custom-tilpasning så I er compliant med SAF-T, hardware der bliver dyrere at vedligeholde, og den dag noget endelig går galt og I står med en akutopgave en weekend. Den regning har bare ikke en faktura.

Den klassiske faldgrube: reimplementering

Når NAV-virksomheder beslutter sig for at gå videre, dukker der typisk to veje op. Den ene er re-implementering, hvor man bygger BC op fra bunden, opsætter det som var det en ny virksomhed, og flytter data og processer over manuelt. Den anden er en teknisk opgradering, hvor I tager den eksisterende NAV-installation med over: data, opsætning, tilpasninger og det hele.

Re-implementering er den gammeldags vej. På papiret lyder den ren, friskt system, fejlene væk, mulighed for at gentænke alting. I praksis er det den dyreste, langsomste og mest risikable måde at komme på BC, og den knækker oftest af grunde folk ikke ser komme.

Den første og største er det vi kalder GAP-analyse. For at reimplementere skal I først dokumentere hvad jeres NAV faktisk gør. Det lyder enkelt indtil I prøver. Spørg en superbruger: “Den her knap, er det standard NAV, eller er det noget vi har fået bygget?” I de fleste tilfælde ved hun det ikke. Den knap har bare været der siden 2014. Eller siden installationen blev migreret fra Navision 3.70 i sin tid. Linjen mellem standard og specialudvikling er for længst visket ud, det gælder rapporter, felter, posteringsregler, godkendelsesflows, små rutiner i bogføringskoden, automatiske beregninger og integrationer ingen længere kender til. I et reimplementeringsprojekt skal det hele kortlægges manuelt før noget kan bygges. Og det I overser i de indledende faser, finder I selv under go-live.

Den anden grund handler om data. Hver datatype kræver beslutning, mapping og test. Åbne poster skal flyttes. Men hvad med åbne ordrer der har leveringskoder der findes i jeres NAV men ikke i et nyt BC-miljø? Dimensioner der har akkumuleret over ti år? Lotnumre, serienumre, itemledger med tolv års bevægelser? De fleste reimplementeringsprojekter undervurderer datadelen markant.

Den tredje handler om integrationerne. Hver eneste integration, webshop, bank, lagerterminal, EDI, EAN-fakturering, kundeportal, skal bygges eller genvalideres på ny. Det er sjældent at en integration “bare virker” på den anden side.

Og den fjerde handler om jer. Reimplementering kræver voldsomt mange interne timer over en lang periode. Superbrugerne skal kortlægge processer, økonomi skal kvalificere data, IT skal oversætte specialudvikling til specifikationer, samtidig med at produktionen skal fortsætte. Det er den slags projekter der trækker ud i 12-18 måneder (og oftere længere), hvor superbrugerne knækker, økonomichefen mister overblikket, og go-live bliver udskudt to gange.

Vores opgraderingsløsning: Behold det der virker

Vi har genopfundet den oprindelige måde at opgradere på. Ikke en reimplementering, men en rigtig opgradering.

Princippet er enkelt. Jeres data følger med. Jeres opsætning følger med. Jeres tilpasninger følger med, udlæst og pakket som AL extensions, så I ikke længere har den klassiske NAV-smerte hvor opdateringer brækker custom-kode. Når projektet er overstået, sidder I på BC SaaS med jeres egen historik intakt, jeres egne processer som I kender dem, og jeres tilpasninger fremtidssikret i den moderne arkitektur.

Forskellen i praksis er at I ikke længere skal svare på “hvad er standard og hvad er specialudvikling?” før vi kan starte. Det finder vi ud af ved at læse koden. I skal ikke beslutte hvilke tre års historik der skal flyttes med, det hele kommer over. I undgår de fleste integrationsmæssige overraskelser fordi jeres integrationer følger med og kun justeres hvor BC’s platform kræver det.

Resultatet er kortere projekter, færre interne timer, lavere risiko og lavere pris. I behøver ikke forholde jer til opgraderingen som et 18 måneders forretningsprojekt med åbent slutpunkt. Det er en teknisk opgave med et veldefineret startpunkt og et veldefineret slutpunkt.

På den anden side får I det moderne BC. Web-baseret brugergrænseflade der virker på telefon, iPad og pc. Månedlige opdateringer der passer bedre med jeres tilpasninger. Power Automate, Power BI og Copilot direkte tilgængelige. AI-funktioner der udvides hvert kvartal (kun på BC SaaS, ikke OnPrem, ikke NAV). Og fordi jeres data er intakt, kan I tage de funktioner i brug fra dag ét, uden først at skulle bygge en historik op.

Reimplementering kan være den rigtige vej i særlige tilfælde, hvis jeres NAV er så stærkt forkrøblet at den ikke længere afspejler hvordan I driver virksomheden, eller hvis I er ved at fusionere flere selskaber. Men det er undtagelsen, ikke reglen. I langt de fleste NAV-virksomheder vi taler med, er den tekniske opgradering den klart bedre vej. Hurtigere, billigere og sikrere.

Læs mere om vores NAV til Business Central Cloud-konvertering med fast pris →

Det rigtige valg er det enkleste

Microsoft har truffet beslutningen om NAV. I står tilbage med to spørgsmål: Hvornår og hvordan.

Vores anbefaling er enkel: Nu er bedre end om to år, og teknisk opgradering er bedre end reimplementering. Den vej er hurtigere og sikrere, og I behøver ikke selv kortlægge hver eneste tilpasning der er bygget oven på jeres NAV gennem årene. Det er vores opgave.