Herausforderungen bei einem Upgrade von Dynamics NAV zu Business Central

Ein Upgrade von Microsoft Dynamics NAV zu Microsoft Dynamics 365 Business Central ist für viele Unternehmen weniger ein technisches 1:1-Upgrade als vielmehr ein komplexes Transformationsprojekt. Das gilt vor allem, weil seit April 2025 keine Perpetual-Lizenzen mehr erworben werden können. Dadurch wird das Upgrade zwangsläufig zu einem strategischen Schritt in Richtung Cloud und Standardisierung. Während NAV im Kern häufig stark individualisiert und klassisch auf lokalen Servern (On-Premises) betrieben wurde – auch wenn sich Lizenzen über erste Subscription-Modelle bereits gemietet in der Cloud nutzen ließen -, setzt Business Central konsequent auf Cloud-Technologie, kontinuierliche Updates und Erweiterbarkeit über Extensions. Trotz dieses klaren Fokus auf das Software-as-a-Service-Konzept bleibt Business Central flexibel und lässt sich weiterhin auch lokal installiert betreiben. Dabei entstehen einige Herausforderungen. In diesem Blogartikel gehen wir darauf ein und geben ebenso Tipps aus unserer Projekterfahrung, wie Sie diese umgehen können.

Cloud-spezifische Herausforderungen

Mit Business Central rückt die Cloud als Bereitstellungsmodell in den Fokus. Seit dem 1. April 2025 können Neukund/-innen keine Perpetual-Lizenzen für Business Central mehr erwerben. Für viele Unternehmen wirft dieser Schritt zunächst Fragen auf, etwa mit Blick auf Performance, Sicherheit und Compliance – Bereiche, in denen durchaus auch Bedenken entstehen können.

Um hier für Klarheit zu sorgen, stellen wir Ihnen die zentralen Unterschiede zwischen Dynamics NAV (On-Premises) und Dynamics 365 Business Central (Online/Cloud) im Überblick gegenüber:

Dadurch ergeben sich im Migrationskontext folgende Herausforderungen, auf die wir teils in den nachfolgenden Kapiteln näher eingehen:

• Die Zielarchitektur in AL muss bedacht werden: Beispielsweise ist die bestehende Architektur (z. B. Datenbank-nahe Logik) nicht übertragbar und Individualanpassungen müssen in Extensions übersetzt werden.
• Custom Code kann zum Upgradeblocker werden: Business Central basierend auf der Programmiersprache AL erzwingt das Extensions-Modell und C/AL-Code kann nicht eins zu eins übernommen werden. Stark angepasste NAV-Systeme machen ein Upgrade-Projekt komplexer.
• Andere technische Rahmenbedingungen: Im Vergleich zu einer On-Premises-Lösung erfolgt die Migration nach Business Central Online ohne direkten Zugriff auf die Ziel-Datenbank. Statt individueller Datenbankanpassungen kommen die von Microsoft vorgesehenen Migrations- und Integrationswerkzeuge zum Einsatz. Dadurch werden Sicherheit, Updatefähigkeit und Standardisierung der Cloud-Umgebung gewährleistet. Individuell entwickelte Tabellen und Erweiterungen stellen in der Regel kein Hindernis für die Migration dar. Sie werden im Rahmen des Migrationsprojekts analysiert, auf ihre zukünftige Relevanz geprüft und bei Bedarf in die Zielumgebung von Dynamics 365 Business Central übernommen.

C/AL vs. AL: Ein technologischer Paradigmenwechsel

NAV basiert auf C/AL und direkten Modifikationen am Standard, während Business Central auf AL und einem strikt getrennten Extensions-Modell aufsetzt. Im Detail gehen damit unter anderem folgende Unterschiede einher (für die gesamte Gegenüberstellung lesen Sie gerne den dazugehörigen Glossareintrag):

Diese Umstellung erfordert von Entwicklerteams und Unternehmen, die eigene Anpassungen vornehmen, ein Umdenken: Anpassungen können in Dynamics 365 Business Central nicht mehr direkt im Systemkern erfolgen, sondern müssen sauber gekapselt als Extensions umgesetzt werden. Der Wechsel von C/AL auf AL ist dabei weniger eine Frage des Schwierigkeitsgrads als vielmehr eine neue Herausforderung, auf die man sich einstellt. Entwickler/-innen lernen dabei nicht nur eine neue Programmiersprache kennen, sondern machen sich auch mit neuen Tools und Prozessen vertraut – von Visual Studio Code statt C/Side bis hin zu modernen Deployment- und Debugging-Methoden. Es ist also nicht schwerer als zuvor, sondern schlicht anders.

Anpassungen und Individualentwicklungen: Das Extensions-Konzept

Viele NAV-Systeme sind über Jahre hinweg gewachsen und stark individualisiert worden. Diese Anpassungen sind oft rudimentär oder gar nicht dokumentiert und greifen oft direkt in den Standard ein. Künftig müssen solche Entwicklungen jedoch technisch anders angekoppelt werden: als Extensions, also als isolierte, modulare Apps, ohne den Kerncode zu verändern.

Besonders in Business Central Online (SaaS) ist es wichtig, da hier unter Umständen monatlich Updates durchgeführt werden und die Extensions entsprechend updatefähig gehalten werden müssen. Über den Zeitpunkt dieser Updates haben Unternehmen bei Business Central Online volle Kontrolle.

Im Rahmen des Upgrades auf Business Central müssen bestehende Anpassungen daher sorgfältig analysiert, bewertet und oft komplett neu gedacht werden. Entscheidend ist dabei, nicht jede gewachsene Individualisierung eins zu eins zu übernehmen, sondern zunächst zu prüfen, welche Anforderungen sich bereits im Standard abbilden lassen. So werden nur die Anpassungen als Extension umgesetzt, die tatsächlich einen echten Mehrwert bieten.

So aufwändig die Umstellung auch sein mag: Sie bietet zugleich die Chance, Prozesse zu bereinigen, zu standardisieren und das System langfristig zu verschlanken.

Schnittstellen und Integrationen

Viele bestehende NAV-Systeme sind über Jahre tief in die Unternehmenslandschaft integriert worden, beispielsweise mit CRM-, E-Commerce-, Logistik-, Finanz- oder Reporting-Systemen. Dabei wurden häufig direkte Datenbankzugriffe, individuelle Schnittstellen, Dateiimporte/-exporte oder spezifische Anpassungen genutzt.

Mit Business Central verändert sich dieser Ansatz deutlich. Statt direkter Datenbankzugriffe stehen standardisierte Schnittstellen, Webservices, APIs, Events und moderne Integrationsmechanismen im Vordergrund. Dadurch werden Integrationen zwar langfristig wartbarer, sicherer und cloudfähiger, kurzfristig entsteht jedoch ein erheblicher Analyse- und Anpassungsbedarf.

Problematisch kann dies insbesondere sein, weil:

• bestehende Integrationen nicht 1:1 übernommen werden können,
• direkte Datenbankzugriffe in der Cloud nicht mehr vorgesehen oder stark eingeschränkt sind,
• alte Schnittstellen technisch neu gebaut oder modernisiert werden müssen,
• im Team möglicherweise Know-how zu APIs, OAuth, Zertifikaten oder modernen Authentifizierungsverfahren fehlt,
• Sicherheits- und Berechtigungskonzepte komplexer werden,
• Drittanbieterlösungen und ISV-Erweiterungen auf Kompatibilität mit Business Central geprüft werden müssen.

Der Integrationsbereich muss im Rahmen der Migration aktiv neu bewertet werden. Es reicht nicht aus, bestehende Schnittstellen technisch „mitzunehmen“. Vielmehr sollte geprüft werden, welche Integrationen weiterhin benötigt werden, welche durch Standardfunktionen oder Apps ersetzt werden können und welche neu über APIs oder Middleware aufgebaut werden sollten.

Projektumfang: Abhängigkeit von NAV-Version und Individualisierungsgrad

Ein häufig unterschätzter Faktor bei dem Upgrade von Microsoft Dynamics NAV zu Microsoft Dynamics 365 Business Central ist außerdem der tatsächliche Projektumfang. Dieser hängt maßgeblich von zwei Aspekten ab: der eingesetzten NAV-Version und dem Grad der Individualisierung.

Gerade die NAV-Version spielt eine entscheidende Rolle, da ein direkter Umstieg auf Business Central häufig nicht möglich ist. Stattdessen müssen mehrere technische Upgrade-Schritte durchlaufen werden, die von der Ausgangsversion abhängen. Je älter das System, desto komplexer und aufwändiger wird dieser Prozess. Hinzu kommt der Individualisierungsgrad: Stark angepasste Systeme erhöhen nicht nur den Analyse- und Entwicklungsaufwand, sondern beeinflussen auch die Wahl der Migrationsstrategie.

Unternehmen müssen daher frühzeitig eine grundlegende Entscheidung treffen:
Soll ein technisches Upgrade erfolgen oder wird Business Central im Rahmen einer Neuimplementierung eingeführt?

• Beim technischen Upgrade wird versucht, bestehende Strukturen und Prozesse möglichst weitgehend zu übernehmen.
• Bei der Neuimplementierung (Re-Implementation) liegt der Fokus auf Standardisierung, Prozessoptimierung und einem „Neustart“ auf Basis von Best Practices.

Beide Ansätze haben Vor- und Nachteile. Entscheidend ist, dass die Wahl bewusst und auf Basis der Systemlandschaft getroffen wird.

Entsprechend ergibt sich ggf. ein deutlich höherer Aufwand bei älteren Systemen.

Weitere Herausforderungen im Rahmen von ERP-Migrationen

Datenmigration und Datenqualität

Die Datenmigration ist ein kritischer Erfolgsfaktor. NAV-Datenbanken enthalten oft Inkonsistenzen, Altlasten oder historisch gewachsene Strukturen, die nicht ohne Weiteres in Business Central übernommen werden können.

Typische Probleme sind dementsprechend:

• Schlechte Datenqualität führt zu Fehlern bei der Migration
• Die Zentralisierung mehrerer Datenquellen ist herausfordernd
• Das Mapping ist komplexer als erwartet
• Bei historisch gewachsenen Sonderlösungen muss geprüft werden, ob sich die Anforderung im Standard abbilden lässt oder ob tatsächlich eine Eigenentwicklung nötig ist

An dieser Stelle lohnt sich eine begriffliche Unterscheidung: Bei einer Datenübernahme werden gezielt die geschäftsrelevanten Daten in das neu aufgesetzte System überführt – typischerweise Stammdaten und offene Posten als Eröffnungsbestände. Die Datenmigration meint dagegen den umfassenderen, technischen Transfer der Datenbank inklusive Bewegungs- und Historiendaten. In der Praxis reicht das Spektrum daher von „keine Altdaten mitnehmen“ über eine selektive Übernahme der wirklich benötigten Daten bis hin zur vollständigen Migration des gesamten Datenbestands.

Microsoft gibt für den Weg von NAV in die Cloud einen klaren Standard-Migrationspfad vor: Bestehende NAV-Systeme werden zunächst auf Business Central On-Premises gehoben, bevor der Wechsel zu Business Central Online erfolgt. Für den eigentlichen Datentransfer stellt Microsoft das Cloud-Migration-Tool bereit. Es installiert einen Replikationsdienst auf dem On-Premises-Server und überträgt die Standardtabellen über eine Azure-Data-Factory-Pipeline nach Business Central Online. Gleiches gilt für Individualtabellen, sofern diese auch in der Zieltabelle vorhanden sind. Über eine inkrementelle Synchronisierung bleiben die Daten während der Testphase aktuell, bis final auf das neue System umgestellt wird. Voraussetzung ist, dass alle Anpassungen als Extensions vorliegen.

Um dieses Thema kommen Sie nicht drumherum: Denn auch die Datenbereinigung ist Pflicht, kein Nice-to-have. Wir empfehlen außerdem mehrere Testläufe, bevor Sie sich im neuen Live-System auf Ihre Datenbasis verlassen.

Changemanagement und User Adoption

Eine ERP-Umstellung wirkt immer auf drei Ebenen zugleich: auf die Technik, auf die Organisation und auf den Menschen. Dieses Veränderungsdreieck (Mensch – Technik – Organisation) macht deutlich, dass mit Business Central weit mehr in Bewegung kommt als nur die technische Basis. Denn erfolgreich wird die Umstellung nur, wenn alle drei Ecken gleichermaßen mitbedacht werden – und genau hier setzt gezieltes Changemanagement an.

Auf der technischen Ebene bringt Business Central vor allem das browserbasierte Arbeiten mit sich. Die grundlegende Bedienlogik mit Rollencentern und Kacheln kennen NAV-Nutzer/-innen zwar bereits seit NAV 2009 R2, doch der Zugriff ist nun von überall und geräteunabhängig möglich, ein lokaler Client muss nicht mehr installiert werden, und die enge Integration in Microsoft 365 sowie Tools wie Sharepoint und Outlook macht viele Abläufe durchgängiger.

Damit verändern sich zugleich Prozesse und Zuständigkeiten – die organisatorische Ebene – und die gewohnte tägliche Arbeit der Anwender/-innen – die menschliche Ebene. Werden Mitarbeitende dabei nicht mitgenommen, sinkt die Nutzerakzeptanz, und das System läuft zwar technisch einwandfrei, wird im Alltag aber nicht voll genutzt. Die größten Hürden einer ERP-Einführung sind erfahrungsgemäß nicht technischer, sondern menschlicher Natur.

Damit der Wandel gelingt, sollte Changemanagement nicht erst zum Go-Live, sondern bereits in der Planungsphase beginnen. Wir empfehlen, die Ziele des Projekts von Anfang an offen und überzeugend zu kommunizieren, sodass für alle transparent wird, warum die Umstellung erfolgt und welchen Nutzen sie bringt. Ebenso wichtig sind die frühzeitige Einbindung von Key Usern, regelmäßiges Feedback aus dem Team und praxisnahe Schulungen, die Sicherheit im Umgang mit dem neuen System schaffen. Wird die Veränderung schließlich dauerhaft in der Unternehmenskultur verankert – etwa durch eine offene Fehlerkultur und fortlaufende Unterstützung –, entsteht statt Widerstand ein echtes Wir-Gefühl. So erleben Ihre Mitarbeitenden die Umstellung als das, was sie sein soll: einfacher, nicht schwieriger.

Ausführliche Unterstützung dazu bietet unser Changemanagement im ERP-Projekt.

Testing und Go-Live

Testing ist bei Upgrade-Projekten komplex, da sowohl technische als auch fachliche Aspekte geprüft werden müssen. Besonders kritisch sind Regressionstests in Bezug auf bestehende Standardfunktionen. Beziehen Sie dabei Ihre Mitarbeitenden aktiv ein: Wer die neuen Abläufe später täglich nutzt, erkennt beim Testen praxisnah, ob Funktionen und Prozesse wie gewünscht laufen. Das erhöht nicht nur die Testqualität, sondern stärkt zugleich die Akzeptanz und das Vertrauen in das neue System. Ihre Aufwände im Testing zahlen sich aus, schaffen Sicherheit und tragen zu einem positiven Gefühl beim Go-Live für alle Beteiligten bei.

Da der Go-Live der kritischste Moment im Projekt ist, kann es selbst bei guter Vorbereitung und ausgiebigen Testläufen zu unerwarteten Herausforderungen kommen. Daher sind ein strukturierter Projektplan, klare Verantwortungen und transparente Abläufe entscheidend – ebenso wie ein Team, das den Prozess von Anfang an aktiv mitträgt.

Fazit

Das Upgrade von Microsoft Dynamics NAV zu Dynamics 365 Business Central ist weit mehr als ein technisches Upgrade – es ist ein strategischer Schritt in Richtung Cloud, Standardisierung und zukunftsfähiger Prozesse. Spätestens seit dem Wegfall der Perpetual-Lizenzen führt an diesem Weg kein Weg mehr vorbei.

Wie dieser Beitrag zeigt, bringt die Umstellung dabei Herausforderungen auf mehreren Ebenen mit sich: den Paradigmenwechsel von C/AL zu AL, die Überführung individueller Entwicklungen in updatefähige Extensions, die Neubewertung von Schnittstellen und Integrationen, die Abhängigkeit von NAV-Version und Individualisierungsgrad sowie eine saubere Datenmigration. Ebenso entscheidend sind die weichen Faktoren – ein aktives Change Management und ein durchdachtes Testing bis zum Go-Live.

Der Schlüssel liegt darin, diese Punkte frühzeitig zu betrachten, den Projektumfang realistisch einzuschätzen und bewusst zu entscheiden: technisches Upgrade oder Neuimplementierung. Wer so vorgeht, setzt die Migration nicht nur erfolgreich um, sondern nutzt sie zugleich, um Prozesse zu bereinigen, die Systemlandschaft zu modernisieren und langfristig vom vollen Potenzial der Cloud zu profitieren. Kurz gesagt: Mit der richtigen Strategie wird aus einer Pflichtaufgabe ein echter Modernisierungsschub für Ihr Unternehmen.

Sie haben Fragen zum Ablauf der Migration oder möchten Ihr Migrationsprojekt gemeinsam mit uns umsetzen? Sprechen Sie uns gerne an!