Migration och uppgradering från Dynamics NAV
Av Thomas Laine · Redaktör och affärsrådgivare
Granskad av redaktionen på businesscentral.se · Senast uppdaterad
Att uppgradera Navision eller Dynamics NAV till Business Central är mer än en vanlig versionsuppgradering. Tekniken, anpassningsmodellen och driftsättet har förändrats, samtidigt som många NAV-miljöer har vuxit under lång tid. Guiden följer köparens frågor – från nuläge och inventering till kostnad, kravbild och partnerval.
Kort svar
Det viktigaste är inte att flytta allt som finns i NAV idag. Börja istället med att avgöra vilka processer, data, anpassningar och integrationer som fortfarande behövs och hur de bäst löses i Business Central.
Inte redo att byta än? Läs om nuläge, risker och support för befintlig NAV. Navision i dag
Förvaltning, utredning och migration är alla giltiga nästa steg. Ert val sparas anonymt i ert Business Central-underlag.
Spår 1
Det är helt legitimt att ligga kvar på NAV så länge verksamheten kräver det. Då behöver ni en partner som kan förvalta äldre versioner, C/AL-kod, serverdrift och lokala integrationer – och som är öppen med vad Microsofts supportdatum innebär för er.
Frågor att ställa till en partner:
Spår 2
Ni behöver inte ha bestämt er för ett byte för att börja utreda. Ta reda på vad anpassningarna kostar att behålla, vad som i dag finns i standard och vilken tidpunkt som är rimlig för er.
Börja med att undersöka:
Spår 3
Uppgradering eller nyimplementation går inte att avgöra på en webbsida – det kräver en genomgång av er kod och data. Utifrån ert val bör ni undersöka:
Bör undersökas före vägvalet:
Partnerlistan filtreras på bransch, storlek och geografi. Vi har inte verifierade uppgifter om partners NAV-erfarenhet och filtrerar därför inte på det – ställ frågorna ovan i dialogen.
Huvudpoängen: flytta inte bara den gamla NAV-lösningen rakt över. Använd projektet för att förenkla och modernisera det som behöver moderniseras.
Dynamics NAV
Er nuvarande lösning
Kartlägg nuläget
Anpassningar, integrationer, rapporter och data
Rensa data och processer
Ta bort det som inte längre används
Bedöm varje behov
Vad behövs faktiskt i den nya lösningen?
Standard
App
Integration
Utveckling
Ta bort
Migrera och testa
Flytta det som ska med, verifiera i drift
Business Central
En enklare lösning än den ni lämnade
Huvudpoängen: flytta inte hela den gamla NAV-lösningen rakt över. Använd projektet till att förenkla och modernisera.
Guiden följer frågorna i den ordning de brukar dyka upp. Hoppa gärna direkt till det steg ni står inför.
Supportläge, versionsnivå och vad som skiljer Business Central från NAV.
Anpassningar, integrationer och en checklista för förstudien.
Historik, arkiv och vilken data som är värd att flytta.
Processer som formats av gamla begränsningar och vanliga misstag.
Faktorerna som driver insatsen – utan schablonpriser.
Beräkna en preliminär investeringMicrosofts väg, full migration eller reimplementation, online eller on-premises.
Frågorna som visar om en partner klarar just er NAV-miljö.
Jämför Business Central-partnersVälj steg efter hur långt ni har kommit.
Steg 1 av 9
Kort svar: den sista NAV-versionen, NAV 2018, har förlängd support till och med 11 januari 2028. NAV 2017 har förlängd support till 11 januari 2027. NAV 2016 och äldre har inte längre någon support från Microsoft.
| Version | Ordinarie support slutade | Förlängd support slutar |
|---|---|---|
| Dynamics NAV 2018 | 10 januari 2023 | 11 januari 2028 |
| Dynamics NAV 2017 | 11 januari 2022 | 11 januari 2027 |
| Dynamics NAV 2016 | 13 april 2021 | 14 april 2026 (har upphört) |
| Dynamics NAV 2015 | 14 januari 2020 | 14 januari 2025 (har upphört) |
Källa: Microsoft Lifecycle (datum enligt amerikansk tid). Senast kontrollerad 13 oktober 2026. Efter supportens slut kommer inga säkerhetsuppdateringar.
Business Central bygger vidare på Dynamics NAV:s funktionella arv. Grundläggande begrepp inom ekonomi, försäljning, inköp, lager och projekt känns därför ofta igen. Det betyder däremot inte att en befintlig NAV-lösning kan flyttas oförändrad till Business Central online.
Plattformen runt affärssystemet har förändrats. Molndrift är idag det huvudsakliga spåret, utveckling görs med AL och extensions och uppdateringsmodellen är annorlunda. Äldre C/AL-anpassningar kan inte bara flyttas över oförändrade. Integrationer behöver granskas på nytt, samtidigt som standardfunktionaliteten och Microsoftplattformen har utvecklats.
Viktig skillnad
Frågan är därför inte bara ”hur flyttar vi NAV till Business Central?” utan också ”hur mycket av vår gamla NAV-lösning ska vi faktiskt ta med oss?”.
Utgångsläget avgör hur mycket arbete som ligger framför er. Det handlar inte bara om versionsnumret, utan om hur mycket som byggts ovanpå standardsystemet under åren.
Den nyaste generationen NAV. Här finns en etablerad väg vidare via Business Central on-premises, och anpassningar är ofta dokumenterade. Frågan blir främst vad som ska följa med.
Miljöer i det här spannet behöver normalt fler mellanliggande uppgraderingssteg innan Business Central online är möjligt. Klassisk klient och äldre rapportteknik gör att mer behöver byggas om.
Här är reimplementation ofta det som faktiskt utvärderas, snarare än uppgradering. Data kan flyttas selektivt, men lösningen byggs i praktiken om.
Exakta stödda uppgraderingsvägar förändras över tid. Kontrollera alltid Microsofts aktuella dokumentation, och låt partnern bekräfta vägen för just er version innan projektet planeras.
Steg 2 av 9
Många NAV-installationer har utvecklats under tio år eller mer. Under tiden kan specialutvecklad kod, egna tabeller och fält, specialrapporter, integrationer, äldre add-ons, lokala lösningar och manuella specialprocesser ha blivit en del av vardagen.
Gamla C/AL-anpassningar ska inte antas kunna flyttas direkt. Varje behov bör i stället jämföras med dagens Business Central, tillgängliga appar och verksamhetens nuvarande arbetssätt.
Funktionaliteten är fortfarande verksamhetskritisk och saknas i standard. Den behöver lösas på ett långsiktigt hållbart sätt.
Business Central har idag motsvarande eller tillräcklig funktionalitet som kan konfigureras utan egen kod.
Ett etablerat ISV-tillägg kan lösa behovet bättre och mer förvaltningsbart än egen utveckling.
Behovet finns inte längre, används sällan eller bygger på en process som bör förändras.
Tydligt råd
Migrera inte en NAV-anpassning bara för att den finns. Varje anpassning bör motiveras på nytt.
NAV är ofta en central del av ett större systemlandskap. Vanliga kopplingar går till lön, CRM, e-handel, bank, EDI, WMS, produktionssystem, PIM, rapportering och andra egenutvecklade system.
Varje integration behöver bedömas som ett verksamhetsbehov, inte bara som befintlig teknik. Även om mottagande system är oförändrat kan gränssnitt, säkerhet, datamodell och övervakning behöva byggas om.
Att bygga om varje gammal NAV-integration riskerar att återskapa gårdagens systemlandskap på en ny plattform.
Gå igenom punkterna internt innan ni börjar prata tidplan och pris med en leverantör. Svaren gör dialogen betydligt mer träffsäker.
Steg 3 av 9
Historisk data blir ofta en av projektets största avvägningar. Mer historik i Business Central kan underlätta uppslag och jämförelser, men ökar också arbetet med mappning, datarensning, migrering och test.
Flytta exempelvis masterdata, öppna poster, aktuella saldon, pågående order och relevant jämförelsedata. Avgränsningen ska utgå från redovisningskrav och verkliga användarbehov.
Låt äldre historik finnas kvar i en läsbar miljö eller ett särskilt arkiv för uppslag. Säkerställ åtkomst, behörighet, lagringstid och ansvar för förvaltningen.
Mer historik i det nya systemet är inte automatiskt bättre. Frågan är vilken historik verksamheten faktiskt behöver för att arbeta framåt.
Äldre ERP-system innehåller ofta dubbletter, gamla kunder, inaktiva leverantörer, felaktiga eller oanvända artiklar, gamla prislistor, inkonsekventa dimensioner och historik som ingen längre använder.
En migrering är ett dåligt tillfälle att flytta dålig data snabbt – men ett bra tillfälle att förbättra datakvaliteten. Datarensning behöver få egna ansvariga, kriterier och tid i projektplanen.
Steg 4 av 9
Många NAV-processer har formats av gamla systembegränsningar, en tidigare organisation, historiska kundkrav, äldre rapportbehov eller manuella workarounds. När förutsättningarna förändras är det inte säkert att processen fortfarande är ändamålsenlig.
Införandet av Business Central bör därför innehålla en processgenomgång, inte bara en teknisk migreringsplan. Målet är inte att förändra allt, utan att medvetet avgöra vad som ska bevaras och vad som kan förenklas.
All data och alla anpassningar förs vidare utan att behovet ifrågasätts.
Problem upptäcks först under test eller go-live, när tiden att rätta dem är knapp.
Nya Business Central-funktioner och etablerade appar utvärderas inte.
Verksamhetens processer och framtida behov får för liten plats i projektet.
Användarna kommer in först nära go-live och viktiga processfrågor upptäcks sent.
NAV-systemets beroenden och dataflöden kartläggs inte tidigt.
Steg 5 av 9
Vi anger medvetet inga veckor eller belopp – de skiljer sig för mycket mellan bolag. Det som däremot går att bedöma är vilka faktorer som drar insatsen uppåt i just er miljö.
Varje anpassning behöver bedömas, och de som ska bevaras behöver byggas som extensions.
Äldre versioner kräver fler mellanliggande steg innan Business Central online är möjligt.
Mer historik betyder mer mappning, migrering och test – och fler tillfällen att upptäcka dataproblem.
Varje koppling till lön, bank, EDI, e-handel, WMS eller produktion behöver granskas och ofta byggas om.
Dubbletter, gamla artiklar och inkonsekventa dimensioner kostar tid, oavsett vilken strategi ni väljer.
Ska arbetssätten göras om behövs processarbete och förändringsledning, inte bara migrering.
Flera juridiska enheter innebär fler uppsättningar, fler tester och fler driftsättningar.
Nyckelpersoner behöver tid i projektet. Det är den vanligaste orsaken till att tidplaner glider.
Vill ni sätta siffror på det här är kalkylatorn en bättre utgångspunkt än en schablon: den räknar på era egna antaganden om användare, konsultdagar och förvaltning.
Omfattningen blir känd först när utvecklingen ska planeras, och då är tidplanen redan satt.
Problemen visar sig i testmigreringen, när tiden att rätta dem har krympt.
Utan beslut om vad som ska följa med växer migreringsarbetet under projektet.
Kopplingar som byggdes av en tidigare leverantör saknar dokumentation och ansvarig.
Nyckelpersoner får inte avsatt tid, och besluten fastnar.
Uppgraderingen blir ett IT-projekt, och processfrågorna hamnar efter go-live.
Steg 6 av 9
Dynamics NAV kan inte migreras direkt till Business Central online. Microsofts stödda väg innebär att NAV först uppgraderas till Business Central on-premises och därefter migreras vidare till Business Central online. Exakta steg beror på vilken NAV-version ni använder.
För NAV 2015–2018 går den aktuella standardvägen via Business Central version 14 on-premises och därefter en senare stödd Business Central on-premises-version före Business Central online. Äldre NAV-versioner kräver ytterligare mellanliggande uppgraderingssteg.
Vid full migration behöver anpassningar med kod hanteras som AL-extensions för att deras data ska kunna följa med. Sidan återger avsiktligt inte hela versionsmatrisen eftersom stödda vägar förändras över tid.
Microsofts aktuella princip
Microsofts aktuella dokumentation säger att NAV först måste uppgraderas till Business Central on-premises innan övergång till Business Central online.
Migrationsvägar och stödda versioner förändras. Kontrollera alltid Microsofts aktuella dokumentation innan projektet planeras.
Efter att NAV har tagits till Business Central version 14 on-premises beskriver Microsoft två möjliga spår. De har olika syfte och tekniska förutsättningar och ska inte betraktas som utbytbara standardval.
Målet är att föra vidare så mycket som möjligt av den befintliga lösningen och dess data till den nya plattformen.
Äldre C/AL-anpassningar behöver analyseras och hanteras i den moderna extension-modellen. Det kan innebära att de byggs om, ersätts eller tas bort.
En ny Business Central-lösning byggs upp och endast den data som verkligen behövs förs vidare.
Historisk data kan lämnas i ett arkiv eller i den äldre NAV-miljön för uppslag i stället för att flyttas till det nya produktionssystemet.
Ingen strategi är generellt rätt. Valet beror på värdet av historiken, mängden anpassningar, datakvaliteten och hur mycket verksamheten har förändrats sedan NAV-lösningen byggdes.
Observera
Microsoft har introducerat ett reimplementation-verktyg för Business Central version 14 som kan flytta utvald affärsdata till Business Central online utan att hela den gamla lösningen följer med. Funktionen är i Microsofts dokumentation fortfarande markerad som preview och bör därför utvärderas tillsammans med en kompetent partner innan den används i ett projekt.
Business Central kan fortfarande köras on-premises, men Microsofts produktutveckling och tjänstemodell är i hög grad orienterad kring Business Central online. Valet påverkar ansvar, uppdateringar, integrationer och framtida förvaltning.
För nya Business Central-projekt är online normalt ett naturligt förstahandsalternativ att utvärdera, men särskilda krav kan motivera on-premises.
Kartlägg version, anpassningar, appar, integrationer, data och processer.
Bestäm vilka behov den nya lösningen ska stödja.
Avgör vad som löses med standard, konfiguration, app, integration eller specialutveckling.
Välj full migration, reimplementation eller en kombination.
Genomför dataflytt, konfiguration, integrationer och användartest.
Planera driftsättning, utbildning, support och fortsatt förbättring.
Bra utgångspunkt
Börja inte med frågan ”hur uppgraderar vi NAV?”. Börja med ”vilken Business Central-lösning behöver verksamheten nu och framåt?”.
Steg 7 av 9
Inventeringen beskriver vad NAV gör i dag. Kravbilden ska beskriva vad verksamheten behöver framåt – och det är den som partners ska svara på. Annars jämför ni förslag som löser olika problem.
Kravbilden sparas i ert Business Central-underlag och följer med när ni skickar en förfrågan till valda partners.
Bygg vår kravbildSteg 8 av 9
Ett NAV-byte kräver en partner som kan både er gamla miljö och modern Business Central. Be om konkreta belägg, inte bara försäkringar.
Vi har inte verifierade uppgifter om varje partners NAV-erfarenhet och rangordnar inte partners. Ställ frågorna i dialogen och jämför svaren.
Steg 9 av 9
Ni behöver inte gå igenom alla steg. Vet ni redan att migrationen ska genomföras kan ni gå direkt till kalkyl, kravbild eller partnerjämförelse. Allt ni gör sparas i samma Business Central-underlag.
Tidigt
Konkret
Konkret
Köpnära
Ett byte från NAV är ett bra tillfälle att pröva alternativen. Jämförelserna visar när Business Central passar och när ett annat system kan vara rimligare.
Läs också: har ni vuxit ur Fortnox eller Visma? · så går en implementation till · så väljer ni partner
Nästa steg
Om ni hellre vill förvalta NAV ett tag till: risker, supportläge och vägval.
Gå vidare KostnadLicenser, införande och förvaltning över fem år.
Gå vidare Efter driftstartNär ni väl kör Business Central: förvaltning, second opinion eller partnerbyte.
Gå vidare