Die Wurzeln reichen weit zurück. Das Produkt entstand ursprünglich beim dänischen Softwarehaus Navision (später Navision Software A/S), das sich in den 1980er- und 1990er-Jahren mit einer schlanken, gut anpassbaren Buchhaltungs- und Warenwirtschaftslösung einen Namen machte. Microsoft übernahm das Unternehmen Anfang der 2000er-Jahre und führte das Produkt zunächst unter der Marke Microsoft Business Solutions und später als Microsoft Dynamics NAV weiter. Der umgangssprachliche Name „Navision“ hat sich in vielen Betrieben gehalten, obwohl er offiziell längst durch „Dynamics NAV“ und dann durch „Business Central“ abgelöst wurde.
Charakteristisch für NAV war von Anfang an die Kombination aus breiter Funktionsabdeckung und hoher Anpassbarkeit. Über die hauseigene Entwicklungsumgebung und die Sprache C/AL ließ sich das System tief an die Prozesse eines Betriebs anpassen — ein Grund, warum viele NAV-Installationen im Laufe der Jahre zu individuell zugeschnittenen Lösungen wurden. Genau diese Anpassungstiefe ist heute Segen und Fluch zugleich: Sie hat das System unverzichtbar gemacht, erschwert aber die Ablösung.
Kaum ein ERP-Produkt hat so viele Namen durchlaufen, und die Verwirrung ist im Alltag entsprechend groß. Vereinfacht gilt: Navision ist der historische Ursprung, Dynamics NAV die von Microsoft weitergeführte On-Premise-Produktlinie, und Dynamics 365 Business Central der aktuelle Nachfolger, der dieselbe Produkt-DNA in eine moderne, überwiegend cloudbasierte Form bringt. Wer heute „wir haben Navision“ sagt, meint fast immer eine NAV-Version — und steht damit vor der Frage, wie es mit diesem Bestandssystem weitergeht.
Der Erfolg von NAV im Mittelstand hat handfeste Gründe. Das System war vergleichsweise erschwinglich, ließ sich von einem breiten Netz spezialisierter Partner einführen und an Branchen anpassen, und es lief robust im eigenen Rechenzentrum — passend zu Betrieben, die ihre Daten im Haus behalten wollten. Über die Jahre entstand ein großes Ökosystem aus Branchenlösungen, Add-ons und erfahrenen Beratern. Für viele mittelständische Fertiger, Händler und Dienstleister wurde NAV so zum digitalen Rückgrat des Tagesgeschäfts.
Genau diese Verwurzelung erklärt, warum die Ablösung heute ein sensibles Thema ist. Ein System, das seit fünf, zehn oder fünfzehn Jahren zuverlässig läuft und in dem das gesamte Prozesswissen eines Betriebs steckt, gibt man nicht leichtfertig auf. Gleichzeitig lässt sich der Lebenszyklus nicht beliebig verlängern. Dieser Beitrag ordnet beide Seiten ein: den Wert des Bestands und die Notwendigkeit, den Übergang bewusst zu planen.
Der Beitrag betrachtet NAV herstellerneutral aus der Perspektive eines Betriebs, der heute ein Bestandssystem hat: die Versionslinie und der Legacy-Status (Kapitel 02), Funktionsumfang und Kernmodule (Kapitel 03), Anpassung über C/AL und Add-ons (Kapitel 04), Integrationen und Ökosystem (Kapitel 05), das Verhältnis zum Nachfolger Business Central (Kapitel 06), der sichere Betrieb von Bestandssystemen (Kapitel 07), die Migration zu Business Central (Kapitel 08), Kosten, Datenhoheit und Risiken (Kapitel 09) sowie häufige Fragen (Kapitel 10). Ziel ist eine nüchterne Entscheidungsgrundlage, keine Werbung für ein bestimmtes Produkt.
Über die Jahre hat das Produkt zahlreiche Versionssprünge erlebt. Auf die frühen Navision-Stände folgten die von Microsoft geführten NAV-Versionen mit aufsteigenden Nummern, ergänzt um Rollup-Updates und Feature-Packs. Die zuletzt erschienenen Ausgaben wurden jahresbasiert benannt und bildeten faktisch den Endpunkt der eigenständigen NAV-Linie, bevor Microsoft die Produktstrategie auf Dynamics 365 Business Central umstellte. Für die Praxis ist weniger die exakte Nummer entscheidend als die grobe Einordnung: Handelt es sich um eine sehr alte, eine mittlere oder eine der letzten NAV-Generationen?
Diese Einordnung hat unmittelbare Folgen. Ältere NAV-Stände basieren auf der klassischen Architektur mit der Entwicklungsumgebung C/SIDE und der Sprache C/AL, teils noch mit der ursprünglichen Zwei-Schicht-Struktur. Neuere Stände brachten eine dreischichtige Architektur, den rollenbasierten Client (RoleTailored Client), einen Webclient sowie erweiterte Integrationsmöglichkeiten mit. Je jünger die Version, desto näher liegt sie technisch am Nachfolger Business Central — und desto einfacher ist tendenziell der Übergang.
Der Begriff Legacy-System klingt abwertend, ist aber zunächst neutral: Er bezeichnet ein etabliertes, produktiv genutztes System, das nicht mehr aktiv weiterentwickelt wird. NAV erfüllt genau diese Definition. Microsoft investiert die Produktentwicklung in Business Central; NAV erhält keine neuen Funktionen mehr, und der Support ist zeitlich begrenzt. Ein Legacy-System ist deshalb nicht automatisch schlecht — es kann jahrelang zuverlässig laufen. Aber es steht unter einem Ablaufdatum, und dieses Datum muss man kennen und einplanen.
Bevor über Betrieb oder Migration entschieden wird, gehört die eigene Ausgangslage sauber erfasst: Welche NAV-Version ist im Einsatz, auf welchem Update- und Patch-Stand, und wie ist sie technisch aufgebaut? Diese scheinbar simple Frage ist in gewachsenen Umgebungen oft schwerer zu beantworten als gedacht, weil Dokumentation fehlt oder veraltet ist. Eine belastbare Bestandsaufnahme ist die Grundlage jeder weiteren Entscheidung — sie bestimmt, wie viel Support noch verfügbar ist, welche Sicherheitslage besteht und wie aufwendig ein späterer Umstieg wird.
Diese grobe Einteilung ersetzt keine individuelle Analyse, hilft aber bei der ersten Selbsteinschätzung. Grundsätzlich gilt: Je älter der Stand, desto dringender ist die Auseinandersetzung mit Support-Ende und Sicherheitslage — und desto größer ist in aller Regel der Abstand zum modernen Nachfolger, der bei einer späteren Migration überbrückt werden muss.
Das Finanzmodul bildet den Kern von NAV, was die Navision-Herkunft als Buchhaltungslösung widerspiegelt. Hauptbuch, Debitoren- und Kreditorenbuchhaltung, Anlagenbuchhaltung, Bank- und Zahlungsverkehr, Kostenrechnung und das Berichtswesen sind eng verzahnt. Weil sämtliche Geschäftsvorfälle aus Einkauf, Verkauf und Lager unmittelbar in die Buchhaltung durchschlagen, entsteht ein durchgängiges Bild der Finanzlage. Für den DACH-Raum wichtig: NAV wurde über Lokalisierungen an die hiesigen Anforderungen an Buchführung und Berichtswesen angepasst, was seine Verbreitung im Mittelstand zusätzlich gefördert hat.
Ein zweiter großer Funktionsblock ist die Warenwirtschaft mit Einkauf, Verkauf, Auftragsabwicklung und Lagerverwaltung. Artikel, Lagerbestände, Preise, Rabatte und Lieferantendaten werden zentral geführt; Bestell-, Liefer- und Rechnungsprozesse laufen durchgängig durch das System. Die Lagerverwaltung reicht von einfacher Bestandsführung bis zu differenzierteren Konzepten mit mehreren Lagerorten, Chargen- und Seriennummernverfolgung. Für Handelsbetriebe ist dieser Bereich häufig der wichtigste Grund für den Einsatz von NAV.
Über Handel und Finanzen hinaus deckt NAV auch Produktion (Stücklisten, Arbeitspläne, Fertigungsaufträge, Kapazitätsplanung), Projektabwicklung (Projekte, Ressourcen, Zeiterfassung, Abrechnung) und Service-Prozesse ab. Der Funktionsumfang ist damit breit genug, um viele mittelständische Geschäftsmodelle in einem System abzubilden — von der reinen Handelsfirma bis zum fertigenden Betrieb mit Projektgeschäft. In der Praxis wird selten der gesamte Umfang genutzt; typisch ist ein Kern aus Finanzen und Warenwirtschaft, ergänzt um die für die Branche relevanten Module.
Das Herz der NAV-Anpassung bildet die integrierte Entwicklungsumgebung C/SIDE (Client/Server Integrated Development Environment) mit der proprietären Sprache C/AL (Client/Server Application Language). Über C/AL ließen sich Objekte wie Tabellen, Formulare beziehungsweise Seiten, Reports und Codeunits direkt bearbeiten — und zwar tief im Standard selbst. Diese Freiheit machte NAV extrem flexibel: Fast jede Anforderung eines Betriebs ließ sich abbilden. Der Preis dafür war jedoch hoch: Änderungen wurden häufig direkt in den Objekten des Standards vorgenommen, was Updates aufwendig machte und über die Jahre erhebliche technische Schulden aufbaute.
Genau hier liegt eine der zentralen Herausforderungen von NAV-Bestandssystemen. Weil viele Anpassungen in den Standard hineinprogrammiert wurden, ist es oft schwer nachzuvollziehen, was am System individuell verändert wurde und warum. Eine gewachsene Installation kann so zu einer Blackbox werden, deren Verhalten nur noch wenige Personen wirklich durchschauen. Für Betrieb, Wartung und spätere Migration ist das ein erheblicher Risikofaktor.
Mit den späten NAV-Versionen und endgültig mit Business Central hat Microsoft dieses Modell grundlegend geändert. An die Stelle von C/AL trat die Sprache AL mit einer modernen Entwicklungsumgebung (auf Basis von Visual Studio Code) und einem Extension-Modell: Anpassungen werden nicht mehr in den Standard hineingeschrieben, sondern als getrennte Erweiterungen „neben“ dem Standard entwickelt. Der Vorteil ist derselbe wie bei anderen modernen ERP-Konzepten: Der Kern bleibt sauber und update-fähig, Erweiterungen lassen sich unabhängig pflegen. Für die Migration bedeutet das allerdings, dass alte C/AL-Anpassungen nicht einfach weiterlaufen, sondern nach AL überführt oder neu gedacht werden müssen.
Neben individuellen Anpassungen lebt NAV von einem großen Ökosystem an Add-ons und Branchenlösungen. Spezialisierte Partner haben über die Jahre fertige Erweiterungen für bestimmte Branchen und Anforderungen entwickelt — von Fertigungs- und Logistiklösungen bis zu speziellen Buchhaltungs- und Compliance-Funktionen. Für Anwenderbetriebe war das attraktiv, weil sie nicht alles selbst entwickeln mussten. Bei der Migration wird dieses Add-on-Geflecht jedoch zum eigenen Thema: Für jede eingesetzte Erweiterung ist zu klären, ob es eine Business-Central-fähige Nachfolgeversion gibt, ob sie ersetzt oder ob sie ganz aufgegeben werden kann.
Als Microsoft-Produkt ist NAV traditionell eng mit dem Microsoft-Ökosystem verzahnt. Die Anbindung an Office-Anwendungen — insbesondere der Export nach und die Auswertung über Excel — gehört zum Alltag vieler NAV-Anwender. Technisch setzt NAV in aller Regel auf den Microsoft SQL Server als Datenbank auf, was Betrieb und Datenzugriff für Microsoft-affine IT-Abteilungen vertraut macht. Diese Nähe zur Microsoft-Welt war stets ein Argument für das System und ist es beim Nachfolger Business Central, der noch enger mit Microsoft 365 und der Power Platform verbunden ist, erst recht.
In der Praxis ist NAV fast immer mit weiteren Systemen verbunden: Webshops und E-Commerce-Plattformen, Versand- und Logistikdienstleister, Zahlungs- und Bankensysteme, CRM-Lösungen, Dokumentenmanagement, Datenaustausch per EDI mit Lieferanten und Kunden. Diese Schnittstellen wurden über die Jahre teils per Standardmechanismen, teils über individuelle Programmierung oder Middleware realisiert. Sie sind ein wesentlicher Teil des Werts der Installation — und zugleich ein sensibler Punkt: Bei einer Migration muss jede relevante Schnittstelle geprüft, nachgebaut oder abgelöst werden.
Ein oft übersehener, aber praktisch entscheidender Teil des NAV-Ökosystems ist das Netz aus Partnern und Beratern. NAV wurde und wird fast ausschließlich über spezialisierte Microsoft-Partner eingeführt, angepasst und betreut. Für Bestandssysteme ist die Verfügbarkeit erfahrener NAV-Fachkräfte ein zunehmend kritischer Faktor: Da die Produktentwicklung auf Business Central verlagert ist, orientiert sich auch das Beratergeschäft dorthin. Wer ein NAV-System langfristig betreibt, sollte deshalb die Frage stellen, wie lange es noch ausreichend Know-how für Wartung, Fehlerbehebung und kleinere Anpassungen am Markt geben wird.
Diese Verschiebung des Know-hows ist ein leiser, aber realer Migrationstreiber, unabhängig vom offiziellen Support-Ende. Selbst ein technisch stabiles System wird zum Risiko, wenn im Störungsfall niemand mehr verfügbar ist, der die individuell gewachsene Installation versteht. Die Bindung an einen verlässlichen Partner — und dessen eigene Perspektive auf NAV — gehört deshalb in jede ehrliche Bestandsbewertung.
Business Central teilt mit NAV die grundlegende Anwendungslogik und einen großen Teil des Funktionsumfangs. Wer NAV kennt, findet in Business Central viele vertraute Konzepte wieder — Buchungslogik, Belegflüsse, Kernmodule. Der Unterschied liegt in der Form: Business Central setzt auf die moderne Sprache AL mit dem Extension-Modell, eine web- und cloudtaugliche Oberfläche, regelmäßige Release-Zyklen und eine enge Verbindung zu Microsoft 365, der Power Platform und Azure. Vereinfacht lässt sich sagen: Business Central ist das, was aus NAV geworden ist, als Microsoft die Produktlinie in die Cloud-Ära überführt hat.
Business Central wird primär als Cloud-Dienst (SaaS) angeboten, existiert aber auch in einer On-Premise-Variante für Betriebe, die weiterhin im eigenen Rechenzentrum bleiben wollen oder müssen. Die strategische Stoßrichtung des Herstellers zeigt jedoch klar in Richtung Cloud: Dort erscheinen neue Funktionen zuerst, dort liegt der Investitionsschwerpunkt. Für NAV-Bestandskunden ist das eine wichtige Information, weil die Migration zu Business Central damit oft auch eine Entscheidung über das künftige Betriebsmodell ist — Cloud oder weiterhin On-Premise.
Für einen NAV-Betrieb ist Business Central nicht irgendeine Alternative am Markt, sondern der vom Hersteller vorgezeichnete Fortsetzungspfad. Das hat einen praktischen Vorteil: Ein großer Teil des vorhandenen Prozess- und Fachwissens bleibt nutzbar, und Microsoft sowie die Partner stellen Werkzeuge und Vorgehensmodelle für den Übergang bereit. Gleichzeitig bedeutet der Wechsel echte Arbeit — bei Anpassungen, Add-ons, Schnittstellen und Bedienung. Business Central ist damit die naheliegende, aber nicht automatisch alternativlose Option: Eine ERP-Neubewertung darf auch andere Systeme prüfen, gerade wenn der Bestand ohnehin stark umgebaut werden müsste.
Mit dem Auslaufen des regulären Supports endet die Belieferung mit regelmäßigen Sicherheits- und Fehlerkorrekturen für die betroffene Version. Das System läuft weiter, aber neu entdeckte Sicherheitslücken werden herstellerseitig nicht mehr geschlossen, und bei Problemen gibt es keinen offiziellen Herstellersupport mehr. Für ein geschäftskritisches ERP, in dem Finanz-, Kunden- und Lieferantendaten liegen, ist das ein ernstzunehmendes Risiko. Die naheliegende Konsequenz ist nicht Panik, aber ein bewusster Umgang: Man betreibt ein solches System nur noch mit zusätzlichen Schutzmaßnahmen und einem klaren Zeithorizont für die Ablösung.
Wird ein NAV-System über das Support-Ende hinaus betrieben, rücken kompensierende Sicherheitsmaßnahmen in den Vordergrund. Dazu gehören unter anderem:
Diese Maßnahmen verringern das Risiko, beseitigen es aber nicht. Sie sind als Überbrückung gedacht, nicht als Dauerlösung — je länger ein nicht mehr unterstütztes System läuft, desto größer wird die Angriffsfläche.
Neben der Sicherheit ist die Verfügbarkeit von Know-how die zweite Betriebsfrage. Kleinere Anpassungen, Fehlerbehebungen und der laufende Betrieb erfordern Fachwissen, das mit der Verlagerung des Markts zu Business Central knapper und teurer wird. Ein realistischer Betriebsplan für ein NAV-Bestandssystem beantwortet deshalb drei Fragen zugleich: Wie sichern wir das System technisch ab, wie stellen wir Wartungs-Know-how sicher, und bis wann wollen wir spätestens migriert haben? Der Betrieb eines Altsystems ist am gesündesten, wenn er von vornherein als befristeter Zustand mit definiertem Ende geplant wird.
Analog zu anderen ERP-Umstiegen lassen sich zwei Grundhaltungen unterscheiden. Bei einem Neuaufbau (Greenfield) wird Business Central frisch aufgesetzt, Prozesse werden am Standard neu ausgerichtet, und nur ausgewählte Stammdaten und Salden werden übernommen. Der Charme liegt im sauberen Schnitt: Altlasten und historisch gewachsene C/AL-Anpassungen bleiben zurück, das neue System startet standardnah und update-fähig. Der Preis ist mehr Aufwand im Prozess-Redesign und im Change Management.
Bei einer technischen Übernahme (Konvertierung) wird versucht, möglichst viel des bestehenden Systems mitzunehmen — Prozesse, Anpassungen, historische Daten. Der Vorteil ist die größere Kontinuität; der Nachteil ist, dass alte C/AL-Anpassungen nach AL überführt werden müssen und man Ballast mitnimmt, der die Update-Fähigkeit gefährdet. In der Praxis sind Mischformen üblich: Bewährtes wird übernommen, Überflüssiges bereinigt. Je jünger die NAV-Version und je sauberer der Anpassungsstand, desto leichter fällt eine kontinuierliche Übernahme; sehr alte, stark modifizierte Systeme sprechen eher für einen Neuaufbau.
Der Migrationsaufwand hängt weit weniger vom Wechsel des Kernsystems ab als von der individuellen Ausgangslage. Die entscheidenden Treiber sind:
Beim Bestand entstehen laufende Kosten für Infrastruktur, Betrieb, Wartung und — je nach Situation — für kostenpflichtige erweiterte Unterstützung oder Partnerleistungen. Diese Kosten wirken auf den ersten Blick niedrig, weil die große Anfangsinvestition längst getätigt ist. Sie steigen jedoch verdeckt, wenn Sicherheitsmaßnahmen, knapper werdendes Know-how und wachsendes Ausfallrisiko einbezogen werden. Auf der anderen Seite steht die Migration als einmalige Investition: Beratung, Überführung der Anpassungen, Datenmigration, Schulung und Stabilisierung — plus, im Cloud-Fall, laufende Abogebühren für Business Central. Belastbare Zahlen lassen sich seriös erst nach einer Bestandsaufnahme nennen; Aufwand und Konditionen gehören konkret beim Anbieter beziehungsweise Partner geprüft.
Ein häufig genanntes Argument für den Verbleib bei NAV ist die Datenhoheit. Als klassisches On-Premise-System liegen bei NAV alle Daten im eigenen oder einem dedizierten Rechenzentrum, unter voller eigener Kontrolle. Für Betriebe mit hohen Anforderungen an Datensouveränität kann das ein Wert an sich sein. Wichtig ist jedoch die ehrliche Kehrseite: On-Premise bedeutet nicht automatisch mehr Sicherheit. Ein nicht mehr unterstütztes System mit ungeschlossenen Sicherheitslücken kann im eigenen Rechenzentrum unsicherer sein als eine professionell betriebene, aktuell gehaltene Cloud-Lösung. Datenhoheit und Datensicherheit sind zwei verschiedene Dinge, die nicht verwechselt werden dürfen.
Beim Wechsel zu Business Central in der Cloud verschiebt sich die Frage: Die Daten liegen dann beim Anbieter, was Datenstandort, Auftragsverarbeitung und Zugriffsregelungen zu prüfenden Punkten macht. Business Central existiert allerdings auch als On-Premise-Variante, sodass Betriebe mit strengen Souveränitätsanforderungen nicht zwingend in die Cloud müssen. Welche Variante passt, ist eine Abwägung aus Sicherheitslage, regulatorischen Anforderungen und Betriebsfähigkeit — und gehört mit den eigenen Datenschutz- und IT-Sicherheitsverantwortlichen abgestimmt.
