Von Microsoft Dynamics NAV auf Dynamics 365 Business Central wechseln

Microsoft Dynamics NAV (intern auch „Navision" genannt) war jahrzehntelang der Mittelstands-Standard im Microsoft-Stack. Mit der Cloud-Strategie von Microsoft wurde NAV in Dynamics 365 Business Central (BC) überführt. Mainstream-Support für klassische NAV-Versionen läuft schrittweise aus — die Migration auf BC ist für die meisten NAV-Anwender nicht mehr „ob", sondern „wann". Dieser Guide gibt einen praxisnahen Leitfaden.

Migration von Microsoft Dynamics NAV auf Business Central mit den drei offiziellen Migrations-Pfaden und typischen Projekt-Aufwänden — NAV → Business Central — drei Migrations-Pfade im Vergleich · Quelle: erp-software.org Redaktion

Auslöser: Warum jetzt von NAV auf BC migrieren?

Mainstream-Support-Endes. Microsoft hat die Lifecycle-Termine für NAV-Versionen definiert. NAV 2018 war die letzte Hauptversion vor BC. Mainstream-Support für NAV 2018 lief Anfang 2023 aus, Extended-Support endet 2028. Wer auf älteren NAV-Versionen läuft (NAV 2016, 2017 oder früher), ist häufig schon out-of-support.

Kein Cloud-Pfad in NAV. NAV ist On-Prem-Architektur. Wenn dein Unternehmen Cloud-Modernisierung will, gibt es in NAV keinen Pfad — nur den Wechsel zu BC.

Fehlende moderne Funktionen. Power BI-Embedding, Power Automate-Workflows, AI-Insights, AppSource-Marketplace — alles BC-Features, die in NAV nicht verfügbar sind. Wer moderne Anwender-Erwartungen erfüllen will, braucht BC.

Stagnation der NAV-Customizing-Welt. ABAP-artige C/AL-Programmierung in NAV ist nicht mehr modern. BC's neue Programmiersprache AL plus Visual Studio Code, Git-Integration und moderne DevOps-Tools sind dramatisch besser.

Recruiting-Vorteil. Junge Microsoft-Entwickler kennen BC und AL — NAV-C/AL-Spezialisten werden seltener und teurer am Personalmarkt.

Wichtige Unterscheidung: Welche NAV-Version habt ihr?

Der Migrations-Pfad hängt stark von eurer aktuellen NAV-Version ab.

NAV 2013 oder älter. Der größte Sprung. Direkter Upgrade-Pfad zu BC ist nicht möglich — entweder mehrstufiger Upgrade über NAV 2017/2018 zu BC, oder direkte Re-Implementation als BC-Greenfield.

NAV 2015–2017. Direkter In-Place-Upgrade über offizielle Microsoft-Tools möglich, aber komplex. Custom-Code wird automatisch migriert, manueller Nacharbeit-Aufwand erheblich.

NAV 2018. Beste Ausgangslage. Direkter Upgrade-Pfad zu BC ist gut dokumentiert, viele Custom-Objekte werden automatisch in BC-Erweiterungen (AL) konvertiert.

Cloud-Versionen NAV 2018 / BC On-Prem. Bereits sehr nah an Cloud-BC. Wechsel auf BC SaaS ist eher technische Migration als Architektur-Umbau.

Drei Migrations-Strategien

1. Technical Upgrade (In-Place)

NAV-Datenbank wird mit Microsoft-Tools schrittweise auf BC migriert. C/AL-Code wird in AL-Erweiterungen konvertiert. Datenmodell wird angepasst. Anwender bekommen neue UI, aber funktional läuft alles ähnlich weiter.

Vorteil: schnellster Pfad, geringster Schulungs-Aufwand. Nachteil: technische Schulden werden mitgeschleppt, Custom-Code-Modernisierung wird verschoben.

2. Re-Implementation (Greenfield)

Neue BC-Cloud-Instanz aufsetzen, Stammdaten neu importieren, Konfiguration nach BC-Best-Practices machen, Custom-Logik nur dort als AL-Erweiterung re-implementieren wo zwingend nötig.

Vorteil: saubere BC-Cloud-Architektur, keine Altlasten, Modernisierungs-Hebel groß. Nachteil: längerer Projektzeitraum, höherer Schulungs-Aufwand, Datenmigrations-Aufwand.

3. Hybrid

NAV-Datenbank wird teilweise migriert (Stammdaten, kritische Custom-Objekte), Standard-Konfiguration nach BC-Best-Practices neu gemacht. Mischform.

Vorteil: balanced — saubere Modernisierung mit Datenkontinuität. Nachteil: aufwendigste Projekt-Steuerung.

Migrations-Phasen — typischer Ablauf

Phase 1 — Discover (3–6 Wochen). NAV-Bestandsaufnahme: Version, Datenbank-Größe, Custom-Code-Volumen (Anzahl C/AL-Objekte), Add-ons (NAV-Branchen-Lösungen wie LS Retail, To-Increase, NAV4Construction etc.). BC-Demo. Strategie-Entscheidung Technical Upgrade / Greenfield / Hybrid.

Phase 2 — Prepare (4–8 Wochen). BC-Tenant einrichten. Lizenz-Modell festlegen (Essentials/Premium, User-Anzahl). Implementierungs-Partner aussuchen (zertifizierter Microsoft-BC-Partner mit NAV-Migrations-Erfahrung). Custom-Code-Inventur (Code-Analyse mit Tools wie Code Analyzer for AL).

Phase 3 — Migrate Code (8–24 Wochen, hoch-variable). Bei Technical Upgrade: C/AL-Objekte automatisiert in AL-Erweiterungen konvertieren. Manuelle Nacharbeit: Code-Modernisierung, BC-spezifische API-Calls, Performance-Optimierungen. Bei Greenfield: keine Code-Migration, Custom-Logik wird in AL neu implementiert wo nötig.

Phase 4 — Migrate Data (4–10 Wochen). Stammdaten extrahieren, bereinigen, in BC importieren. Bewegungsdaten-Strategie: vollständig (bei Technical Upgrade) oder offene Posten + 2–3 Jahre Historie (Greenfield).

Phase 5 — Test (4–8 Wochen). UAT, Integration-Tests mit Schnittstellen-Systemen (DATEV, Bank, Lager etc.), Performance-Tests, Schulungs-Vorbereitung.

Phase 6 — Cutover & Stabilize (2–6 Wochen). Final-Cutover am Wochenende. NAV wird Read-Only. BC produktiv. Hypercare-Phase.

Insgesamt: 6–12 Monate für typische NAV-Upgrades, 9–18 Monate bei größeren Re-Implementations.

Custom-Code: Der Knackpunkt jeder NAV-Migration

Der Custom-Code-Anteil ist der größte Risiko-Faktor. NAV-Anwender haben über die Jahre oft Hunderte oder Tausende C/AL-Objekte angesammelt: Custom-Tabellen, Formulare, Reports, Codeunits. Bei der BC-Migration müssen diese in AL-Erweiterungen konvertiert werden.

Tooling. Microsoft bietet automatische Konvertierung (txt2al-Tool). Die Konvertierung ist meist 70–85% automatisch erfolgreich — der Rest ist manuelle Nacharbeit. Ältere C/AL-Patterns (z.B. Form-basierte Logik) müssen in BC-Standard-Patterns überführt werden.

Tiefe der Anpassung. Bei sehr customized NAV-Setups (>500 Custom-Objekte) ist Greenfield-Re-Implementation oft schneller als Technical Upgrade — weil man nicht 100% Custom-Code retten muss.

Branchen-Add-ons. Wenn NAV-Branchen-Add-ons (z.B. LS Retail) im Einsatz sind: prüfen, ob Hersteller eine BC-Version anbietet. LS Retail, KUMAVISION und To-Increase haben BC-Pendants — andere kleinere Branchen-Add-on-Hersteller manchmal nicht.

Custom-Reports. NAV-Reports (RDLC, Word-Layouts) funktionieren mit Anpassungen in BC. Übernahme ist möglich, aber Nacharbeit erforderlich.

Datenmigration

Stammdaten. Item, Customer, Vendor, G/L Account, Cost Center sind im Datenmodell weitgehend kompatibel zwischen NAV und BC — Standard-Tools migrieren das robust.

Bewegungsdaten. Bei Technical Upgrade vollständig übernommen. Bei Greenfield: empfohlene Strategie ist „offene Posten zum Stichtag + 2 Jahre Historie für Reporting-Vergleichbarkeit". Ältere Historie kann in BC-Archive-Tabellen oder als separate Read-Only-NAV-Instanz weiter zugänglich gehalten werden.

Custom-Daten. Wenn NAV Custom-Tabellen mit unternehmenskritischen Daten hat (z.B. Anlagenakte, Wartungs-Historie), müssen diese in entsprechende BC-AL-Erweiterungs-Tabellen übernommen werden. Mapping-Aufwand kann erheblich sein.

Aufwand & Kosten

Größe	Custom-Tiefe	Zeitrahmen	Gesamtkosten-Range
Klein (10–50 MA)	Standard-NAV	4–7 Monate	100.000 – 280.000 EUR
Mittel (50–150 MA)	Mittlere Customizing	6–12 Monate	250.000 – 700.000 EUR
Mittel-Groß (150–500 MA)	Tiefe Customizing	9–18 Monate	600.000 – 1.800.000 EUR
Komplex (Multi-Country, viele Add-ons)	Hohe Customizing	12–24 Monate	1.500.000 – 4.000.000 EUR

BC-Lizenz-Kosten: Essentials ca. 70 EUR/User/Monat, Premium ca. 100 EUR/User/Monat. Bei 100 Usern Premium: 120.000 EUR/Jahr Lizenz.

Stolperfallen

C/AL-Code-Konvertierung unterschätzt. Viele NAV-Anwender denken „Tool macht alles automatisch". Realität: 15–30% der Code-Konvertierung ist manuelle Nacharbeit. Plan: Code-Analyse VOR dem Projekt-Kick-off.

Branchen-Add-ons ohne BC-Pendant. Wenn ein NAV-Branchen-Add-on im Einsatz ist, das BC nicht unterstützt, kann die Migration scheitern. Prüfe Add-on-Hersteller-Roadmap frühzeitig.

Custom-Reports vergessen. Reports sind oft business-kritisch. Eine vollständige Report-Inventur in Phase 1 ist Pflicht.

Stammdaten-Qualität nicht bereinigt. Wer schlechte NAV-Daten direkt nach BC migriert, hat schlechte BC-Daten. Bereinigung ist nicht „nice to have", sondern Voraussetzung.

Schnittstellen-Inventar unvollständig. NAV ist oft tief in Drittsysteme eingebunden. DATEV, Bank, Lager, Versand, BI — alle müssen für BC neu eingerichtet werden.

Performance-Thema in Cloud-BC. BC SaaS hat begrenzte Customizing-Optionen (kein direkter Datenbank-Zugriff). Performance-Bottlenecks im NAV-Custom-Code, die durch direkte SQL-Queries gelöst wurden, müssen in BC anders angegangen werden (oft via Power BI oder Azure Data Lake).

Hypercare-Aufwand vergessen. Anwender haben Jahre mit NAV-UI gearbeitet. BC ist anders. Hypercare-Phase 4–8 Wochen mit erhöhter Beratungs-Verfügbarkeit.

Erfolgsfaktoren

Microsoft-Partner mit dokumentierter NAV-zu-BC-Migrations-Erfahrung. Frage nach abgeschlossenen Migrationen in deiner Größe und Branche.

Frühe Code-Analyse. Lass den Custom-Code mit Tools auswerten BEVOR du das Projekt freigibst. Erkennt unerwartete Komplexität.

Phased Cutover bei großen Setups. Bei Multi-Country: nicht alle Töchter gleichzeitig migrieren. Pilot-Tochter zuerst, Lessons Learned, dann Roll-out.

Power Platform früh nutzen. BC's Power-Automate- und Power-Apps-Integration ist mächtig. Wer früh in dieser Richtung denkt, modernisiert nicht nur das ERP, sondern den ganzen Workflow-Stack.

Anwender-Ambassadoren. Pro Fachbereich 1–2 erfahrene NAV-Anwender als BC-Pioniere ausbilden. Sie helfen Kollegen während Hypercare.

Wann sich der Wechsel NICHT lohnt

Geplante Veräußerung kurzfristig. Käufer wird ohnehin auf seine ERP-Plattform migrieren wollen.

Sehr starkes proprietäres NAV-Branchen-Add-on ohne BC-Pendant. Selten, aber kommt vor. Dann oft entweder beim NAV-Anbieter bleiben (Extended Support nutzen) oder strategischer Re-Plattform-Wechsel zu einer Branchen-spezifischen Alternative.

Sehr kleine NAV-Setups (5–10 User) mit minimaler Nutzung. Ggf. ist der Wechsel zu einer KMU-Lösung wie Sage 50 oder Lexware wirtschaftlicher als BC.

In allen anderen Fällen ist BC der natürliche Nachfolger — und je früher der Wechsel passiert, desto weniger NAV-Custom-Schulden müssen mitgenommen werden.

Können wir auf BC On-Prem (statt Cloud) migrieren? Ja, BC ist auch On-Prem verfügbar. Aber Microsoft investiert primär in Cloud-Versionen — neue Funktionen kommen zuerst Cloud-only. Empfehlung: Cloud, sofern keine spezifische Compliance-Anforderung dagegen spricht.

Wie lang dauert die durchschnittliche NAV-zu-BC-Migration? 6–12 Monate für Mittelstand-Setups mit moderater Customizing-Tiefe. Bei umfangreicher Customizing oder Multi-Country: 12–24 Monate.

Welche Microsoft-Tools helfen bei der Migration? txt2al für Code-Konvertierung, BC Cloud Migration Tool für Daten-Migration, Visual Studio Code mit AL-Extension für Entwicklung, Code Analyzer für AL für Code-Qualitäts-Analyse.

Können wir während der Migration weiter mit NAV produktiv arbeiten? Ja, das Projekt läuft parallel. Aber: NAV-Code-Änderungen während der Migrations-Phase müssen synchronisiert werden — Empfehlung: Code-Freeze in NAV während der finalen Phasen.

Was passiert mit unseren NAV-Reports? RDLC-Reports laufen in BC mit Anpassungen. Word-Layouts ebenfalls. Klassische Form-basierte Reports müssen neu gebaut werden — meist mit Word-Layouts oder Power BI.

Werden unsere Drittanbieter-Add-ons unterstützt? Hängt vom Hersteller ab. LS Retail, KUMAVISION, To-Increase, prodware: ja. Kleinere/lokale Add-ons: prüfen.

Stand: Mai 2026. Praxisnaher Überblick — keine individuelle Beratung. Konkrete Aufwände variieren je nach Setup.

Häufig gestellte Fragen

Wann läuft der Support für Dynamics NAV aus?

Für NAV 2018, die letzte Hauptversion vor Business Central, endete der Mainstream-Support am 10. Januar 2023; der Extended-Support mit reinen Sicherheits- und kritischen Fixes läuft noch bis zum 11. Januar 2028. Die unmittelbar vorangehenden Versionen sind gestaffelt ausgelaufen: NAV 2013 (Januar 2023) und NAV 2015 (Januar 2025) erhalten keine Updates mehr, NAV 2016 ist seit April 2026 aus dem Extended-Support, während NAV 2017 noch bis zum 11. Januar 2027 Sicherheitsupdates bekommt. Nach dem jeweiligen Extended-Support-Ende gibt es weder Patches noch Microsoft-Unterstützung, sodass die Dringlichkeit der Migration auf Business Central stark von eurer konkreten NAV-Version, den Compliance-Anforderungen und der eigenen IT-Roadmap abhängt.

Wie lange dauert eine NAV-zu-Business-Central-Migration im Durchschnitt?

Für Mittelstands-Setups mit moderater Customizing-Tiefe liegt der typische Projektzeitraum bei 6 bis 12 Monaten von der Bestandsaufnahme bis zur stabilisierten Produktion. Bei umfangreichem Custom-Code, vielen Branchen-Add-ons oder Multi-Country-Strukturen sind 12 bis 24 Monate realistisch, da Code-Konvertierung und Tests dann den größten Anteil ausmachen. Ein reines technisches Upgrade über die Versionskette ist meist schneller als eine Greenfield-Re-Implementation, schleppt dafür aber technische Schulden mit. Die Dauer wird vor allem durch die Tiefe der C/AL-Anpassungen, die Datenqualität und die Zahl der Drittsystem-Schnittstellen bestimmt.

Welche NAV-Versionen unterstützt das Cloud Migration Tool von Microsoft?

Eine direkte Cloud-Migration aus NAV gibt es nicht: Microsoft sieht vor, die On-Premise-Lösung zunächst auf Business Central on-premises (Version 14) und anschließend auf mindestens Version 25 zu heben, bevor das Cloud Migration Tool die Daten über Azure Data Factory in die Online-Umgebung repliziert. NAV 2015 bis 2018 folgen diesem Standardpfad direkt über Version 14, während ältere Stände wie NAV 2013 oder 2009 zusätzliche Zwischen-Upgrades (etwa über NAV 2018) benötigen. Technische Voraussetzung ist mindestens SQL Server 2016 sowie eine Datenbank-Kompatibilitätsstufe von 130 oder höher. Für die Code-Seite wird der txt2al-Konverter (verknüpft mit der Version-14-Plattform) genutzt, um C/AL-Objekte in AL-Erweiterungen zu überführen.

Was kostet eine Business-Central-Lizenz pro Anwender?

Business Central wird im Cloud-Abo pro Named User abgerechnet, wobei Microsoft die Listenpreise zum 1. November 2025 angehoben hat: Essentials liegt seither bei rund 80 USD pro Nutzer und Monat, Premium bei etwa 110 USD. Die Team-Member-Lizenz für reine Lese- und Leichtnutzer blieb bei rund 8 USD pro Nutzer und Monat unverändert. Premium ergänzt gegenüber Essentials vor allem Fertigung und Service-Management, weshalb produzierende Betriebe in der Regel Premium benötigen. Die in Euro abgerechneten Listenpreise weichen je nach Wechselkurs und regionaler Preisliste ab, und Implementierungs- sowie Add-on-Kosten kommen separat hinzu.

Was passiert bei der Migration mit unserem C/AL-Custom-Code?

C/AL-Code wird mit dem txt2al-Tool weitgehend automatisiert in moderne AL-Erweiterungen konvertiert, wobei in der Praxis erfahrungsgemäß ein erheblicher Teil automatisch durchläuft und der Rest manuelle Nacharbeit erfordert. Alte Muster wie formularbasierte Logik lassen sich nicht eins zu eins übertragen und müssen in Business-Central-Standard-Patterns oder Page-Erweiterungen neu gebaut werden. Bei sehr stark angepassten Setups mit mehreren Hundert Custom-Objekten ist eine Greenfield-Re-Implementation oft wirtschaftlicher als der Versuch, den gesamten Altcode zu retten. Eine Code-Analyse vor dem Projektstart deckt unerwartete Komplexität auf und sollte daher als Pflichtschritt eingeplant werden.

Können wir während des Migrationsprojekts weiter produktiv mit NAV arbeiten?

Ja, das Migrationsprojekt läuft parallel zum laufenden NAV-Betrieb, sodass das Tagesgeschäft bis zum finalen Cutover unverändert weiterläuft. Allerdings müssen Änderungen am NAV-Custom-Code während der Migrationsphase mit dem entstehenden AL-Stand synchronisiert werden, weshalb für die finalen Phasen meist ein Code-Freeze empfohlen wird. Der eigentliche Umstieg erfolgt typischerweise an einem Wochenende, danach wird die NAV-Datenbank in der Regel read-only gesetzt und Business Central produktiv geschaltet. An den Go-Live schließt sich eine Hypercare-Phase von etwa vier bis acht Wochen mit erhöhter Beratungsverfügbarkeit an, da sich die Business-Central-Oberfläche spürbar von der gewohnten NAV-UI unterscheidet.

Können wir auf Business Central On-Premises statt in die Cloud migrieren?

Ja, Business Central ist weiterhin auch als On-Premises-Variante verfügbar, sodass ein Verbleib im eigenen Rechenzentrum technisch möglich bleibt. Microsoft investiert seine Weiterentwicklung jedoch primär in die Cloud-Version, und neue Funktionen erscheinen häufig zuerst oder ausschließlich in der SaaS-Variante. On-Premises bietet mehr Spielraum bei tiefem Customizing und direktem Datenbankzugriff, verlangt dafür aber eigene Infrastruktur, Updates und Betrieb. Für die meisten Mittelständler ist die Cloud-Variante die strategisch empfohlene Wahl, sofern keine konkrete Compliance- oder Datenhaltungsanforderung dagegen spricht.