En opgradering fra Dynamics NAV til Business Central handler sjældent kun om at komme på en nyere version. I 2026 er det ofte et skifte i arbejdsform: fra tungere, versionsbundne tilpasninger og sporadiske “store hop” til en platform, der skal kunne opdateres løbende, udvikles kontrolleret og blive brugt rigtigt i hverdagen.
Det gode er, at mange NAV-organisationer allerede har en stærk proces- og datadisciplin. Det svære er, at alt det, der gennem årene har gjort NAV “jeres”, kan være flettet ind i kernen via C/AL, gamle rapporter, integrationer og særflows. Derfor bør planlægningen i 2026 starte med et ærligt blik på, hvad der er standard, hvad der er nødvendigt, og hvad der bare er vaner.
Hvorfor 2026 kræver mere plan end “bare en opgradering”
Hvis I sidder på en ældre NAV- eller tidlig Business Central on-prem løsning, vil I typisk mærke flere samtidige pres i 2026: sikkerhed, compliance, forventninger til integrationer, og et behov for hurtigere forretningsændringer uden at alt bliver et mini-projekt.
Samtidig betyder Business Centrals udvidelsesmodel (AL extensions), at tilpasninger helst skal ligge som apps, ikke som ændringer i standardkoden. Det giver bedre opgraderbarhed, men kræver, at man tager stilling til, hvordan man vil styre ændringer, add-ons og videreudvikling fremadrettet.
Og så er der den klassiske misforståelse: at man kan planlægge opgraderingen som et rent IT-spor og “træne lidt til sidst”. De fleste udfordringer opstår i krydsfeltet mellem proces, data, brugeradfærd og integrationer.
Første beslutning: Cloud, on-prem eller en kontrolleret mellemvej
Valget mellem Business Central Online og on-prem er ikke et ideologisk valg. Det bør tage udgangspunkt i krav til drift, dataplacering, integrationer og den interne kapacitet til at holde platformen opdateret.
Mange danske virksomheder vælger SaaS af tre grunde: mindre drift, hyppige opdateringer og nemmere adgang fra flere lokationer. On-prem kan stadig give mening, hvis der er særlige regulatoriske krav, kompleks lokal infrastruktur eller tung afhængighed af lokale komponenter.
Efter en indlednings afklaring kan det være nyttigt at beskrive beslutningen i helt konkrete konsekvenser:
- Webklient og standardiserede opdateringer
- Lokale integrationer og netværksafhængighed
- Release-rytme og testbehov
- Drift, overvågning og backup-ansvar
Pointen er ikke, at den ene vej er “rigtig”, men at beslutningen påvirker hele projektets metode: miljøer, test, cutover, add-ons og governance.
Kend jeres udgangspunkt: version, tilpasninger, add-ons og integrationer
Planlægningen bliver markant bedre, når I kan svare præcist på fire spørgsmål:
- Hvilken version kører vi på, og hvilken opgraderingsvej kræver det?
- Hvor meget er ændret i standard (C/AL, objekter, rapporter, forms)?
- Hvilke add-ons er kritiske, og findes de i en opgraderingsvenlig udgave?
- Hvilke integrationer er i drift, og hvad er deres tekniske kobling (fil, SOAP, API, database, middleware)?
I 2026 er det også vigtigt at få identificeret “skjulte integrationer”: Excel-ark med import/eksport, planlagte SQL-jobs, små scripts, manuelle bogføringsrutiner og specialrapporter, som kun én person kender.
En praktisk måde at få overblik på er at kategorisere tilpasningerne, så de kan prioriteres:
- Must-have: krav til drift, bogføring, compliance, kerneproces
- Nice-to-have: bekvemmelighed, rapportlayout, små felter
- Stop/replace: gammel logik, som standard eller add-on kan dække bedre
Når man gør det tidligt, undgår man at konvertere historiske “fixes”, som reelt bare er teknisk gæld.
Faserne, der typisk virker i praksis
Et opgraderingsprojekt kan køres på flere modeller, men de samme milepæle går igen: analyse, forberedelse, implementering, test og udrulning.
Nedenfor er et eksempel på en enkel struktur, der passer til mange NAV-til-BC projekter.
| Fase | Hvad I afklarer | Typiske leverancer | Hvem skal være med |
|---|---|---|---|
| Analyse og scope | Processer, tilpasninger, integrationer, datakvalitet | Scope, risikoliste, plan for miljøer og test | Forretning, superbrugere, IT, partner |
| Forberedelse | Migrationsspor, miljøopsætning, add-ons, licenser | Sandbox/testmiljø, backlog, plan for konvertering | IT, udvikling, nøglebrugere |
| Implementering | AL-extensions, dataopgradering, integrationer | Konverteret løsning, første migrationskørsel | Udvikling, integrationsteam |
| Test og godkendelse | Regression, UAT, performance, rapporter | Testcases, fejllog, sign-off | Superbrugere, økonomi, lager, salg |
| Cutover og stabilisering | Nedetid, sidste data, rollback, support | Cutover-plan, go-live tjekliste, hypercare | IT, partner, superbrugere |
En række danske konsulenthuse, herunder Naviteam, arbejder typisk med netop den type struktur: klar scope-styring, faste milepæle og fokus på forankring hos brugerne, så det ikke ender som en “teknisk succes” men en forretningsmæssig frustration.
Data: det I flytter, og det I bør lade blive
Dataopgradering bliver ofte beskrevet som en teknisk disciplin, men beslutningen om hvilke data der skal med, er forretningskritisk.
Nogle virksomheder vil flytte alt historik. Andre vælger at flytte balance, åbne poster og stamdata, og så lave et let tilgængeligt arkiv af resten. Der er ikke ét rigtigt svar, men der er en klar tommelfingerregel: jo mere data og jo flere specialtabeller, desto mere test, afstemning og tid.
Hvis I har mange år med “lokale” tabeller og felter, så lav en konkret plan for, hvordan de data enten migreres via extensions, erstattes af standard, eller arkiveres.
Her er typiske datadiscipliner, der betaler sig, før første migrationskørsel:
- Oprydning i dubletter og inaktive stamdata
- Validering af dimensioner, bogføringsopsætning og momsregler
- Afstemning af lager, værdi, åbne poster og bank
- Gennemgang af tegnsæt og specialtegn, især hvis der har været gamle importkilder
Det lyder banalt. Det er det ikke, når man står i UAT og brugerne finder fejl, der viser sig at være gamle datafejl, som bare er blevet usynlige i NAV.
Tilpasninger: fra C/AL til AL uden at miste kontrollen
En central del af 2026-planen bør være en styringsmodel for tilpasninger. Business Central belønner standardisering og “app-tankegang”, men I skal stadig kunne udvikle. Spørgsmålet er bare hvordan, og hvor meget.
En nyttig tilgang er at kræve, at alle nye ønsker bliver behandlet som en backlog med prioritet, business case og acceptkriterier. Det er også her governance kommer ind: Hvem må bestille ændringer? Hvordan testes de? Hvornår går de i produktion? Hvilke add-ons er “låst”, og hvilke kan udskiftes?
Det hjælper at lave en fælles rettesnor for ændringer:
- Standard først: vælg standardfunktion før specialkode
- Extension før ændring: byg udvidelser, så opgraderinger bliver realistiske
- Dokumentation og test: ingen ændring uden sporbarhed og UAT-kriterier
- Release-rytme: aftal faste vinduer for ændringer og opdateringer
Når I gør det, planlægger I ikke kun go-live, men også tiden efter, hvor værdien typisk realiseres.
Integrationer: den skjulte tidsplan
NAV-løsninger har ofte integrationer, som blev lavet “engang” og siden bare har kørt. I Business Central er integrationsmønstre typisk mere API-baserede, og særligt ved SaaS kan gamle teknologier ikke tages med.
Derfor bør I tidligt beslutte, om integrationer skal:
- bygges om til API/OData,
- flyttes til en mere robust integrationsplatform,
- erstattes af en AppSource-løsning,
- eller helt udfases.
Særligt e-handel, EDI, betalingsformidling, løn, logistik og dokumenthåndtering bør have egne mini-workshops, hvor I gennemgår både den tekniske løsning og den proces, integrationen understøtter. Ellers får I en opgradering, hvor økonomi kan bogføre, men ordreflowet ikke kan køre.
Test, cutover og rollback: planlæg for ro, ikke heroiske weekender
Ambitionen er ofte “minimal nedetid”, men vejen dertil er ikke at presse alt ind i en weekend. Vejen er gentagne testmigreringer, stabil datavalidering og en cutover-plan, der er øvet.
Cutover-planen bør være konkret ned til rækkefølge og ansvar. Ikke bare “migrer data”, men præcist: hvem lukker NAV, hvem tager backup, hvem kører dataopgradering, hvem validerer de tre vigtigste afstemninger, og hvornår beslutter man at fortsætte eller rulle tilbage.
En kort tjekliste kan være overraskende effektiv, hvis den er realistisk og bliver brugt:
- Beslutningspunkt: hvornår er “go/no-go”, og hvem siger det?
- Backup: hvilken backup er “den gyldne”, og hvor ligger den?
- Afstemninger: hvilke tal skal matche, før I åbner for brugerne?
- Kommunikation: hvem informerer brugere, kunder og leverandører ved forsinkelse?
Det vigtigste er, at rollback ikke kun findes i et dokument, men er tænkt igennem som en reel mulighed.
Brugeradoption: planlagt træning og små leverancer
Business Central føles genkendelig for NAV-brugere, men brugerfladen og arbejdsformen ændrer sig. Der er flere søgemuligheder, andre genveje, og en anden forventning til, at man arbejder i lister, filtrerer og bruger rollecenteret.
Træning virker bedst, når den tager udgangspunkt i opgaver, ikke menupunkter. En superbruger i økonomi skal kunne gennemføre periodens vigtigste rutiner: bogføring, afstemning, moms, rapportering. En lagermedarbejder skal kunne modtage, plukke, håndtere retur og fejl.
I praksis giver det ro, hvis man accepterer, at de første uger efter go-live handler om stabilisering. Mange organisationer planlægger derfor en “hypercare”-periode med hurtig support, korte daglige statusmøder og en klar prioritering af fejl kontra forbedringsønsker.
Økonomi og licenser: byg en model, der kan forklares
I 2026 bliver licens- og driftsøkonomi ofte et tema på ledelsesniveau, især hvis man går fra NAV-perpetual til Business Central abonnement. Derfor bør I tidligt lave en simpel model, der viser:
- hvad der ændrer sig i drift (servere, backup, opdateringer),
- hvad der ændrer sig i licenser (typer og antal),
- hvilke interne timer der bruges på projekt og efterfølgende drift,
- hvilke gevinster der forventes, og hvornår de kan ses.
Hvis modellen kun kan forklares af en tekniker, får I svært ved at holde retning, når scope eller tidsplan bliver udfordret.
Governance efter go-live: det, der gør næste opdatering lettere
Det er fristende at betragte go-live som “målstregen”. I Business Central er det mere hjælpsomt at se go-live som starten på en ny rytme: opdateringer, små forbedringer, kontrolleret udvikling og løbende forankring.
En enkel governance-pakke kan bestå af et ændringsråd (forretning + IT), en backlog, faste releasevinduer og en testmetode, der passer til jeres tempo. Flere vælger også at standardisere på velkendte add-ons og holde egenudvikling skarp og begrundet, så opgraderinger ikke bliver et tilbagevendende maraton.
Hvis I planlægger opgraderingen i 2026 med både teknik, proces og mennesker på samme tid, bliver Business Central ikke bare en ny platform, men et mere stabilt fundament for det, der skal bygges de næste år.
Har I brug for sparring om Navision/Dynamics NAV og Business Central, eller ønsker I en konkret plan for jeres næste skridt, er I velkomne til at række ud. Kontakt | Naviteam