10 häufige Fehler bei der Migration von NAV zu Business Central (und wie man sie bis 2026 vermeidet)

Wenn Sie noch mit Dynamics NAV arbeiten, kennen Sie das wahrscheinlich: Jemand erwähnt die „Business Central Migration“, und sofort denken Sie an Ausfallzeiten, Datenprobleme und unerwartete Budgetüberraschungen.

Diese Reaktion ist… berechtigt.

Wir haben schon NAV-Migrationen erlebt, die hervorragend verlaufen sind. Wir haben aber auch schon erlebt, wie sie sich zu sechsmonatigen Umwegen entwickelten, weil eine vermeintlich „kleine“ Anpassung sich als Ursache für die Probleme des halben Lagers herausstellte.

Die gute Nachricht ist, dass die meisten NAV-zu-BC-Fehler nicht auf einen mysteriösen technischen Fluch zurückzuführen sind. Sie lassen sich in der Regel auf dieselben wenigen vermeidbaren Fehler zurückführen.

Dieser Leitfaden erklärt Ihnen die wichtigsten Punkte und zeigt Ihnen, was Sie stattdessen tun können.

Warum NAV-Migrationen im Jahr 2026 häufiger scheitern als je zuvor

Wenn Sie NAV nutzen und sich jetzt unter Druck gesetzt fühlen, bilden Sie sich das nicht ein.

Die Supportfristen zwingen immer mehr Teams zum Handeln. Und selbst wenn Ihr NAV-System „einwandfrei funktioniert“, besteht das eigentliche Risiko darin, was passiert, wenn Sie Sicherheitsupdates, Compliance-Änderungen oder neue Funktionen benötigen, die Microsoft in Business Central bereitstellt.

Der reguläre Support für NAV 2016 endet im April 2026. Der erweiterte Support für NAV 2018 endet im Januar 2028. Das klingt zunächst weit weg, bis man bedenkt, dass eine komplexe Migration leicht 6 bis 12 Monate dauern kann, wenn man Discovery, Bereinigung, AL-Arbeiten, Integrationen, Tests und Schulungen mit einbezieht.

Wer also noch nicht mit der Planung begonnen hat, ist nicht „zu spät“… aber die Zeit drängt.

Der entscheidende Punkt: Migrationen scheitern nicht, weil Business Central schlecht ist. Sie scheitern, weil die Teams den damit verbundenen Aufwand unterschätzen.

Lasst uns das ändern.

Die 10 häufigsten Fehler bei der Migration von NAV zu Business Central

Fehler 1: Es als einfaches Versions-Upgrade behandeln.

Das ist die Denkfalle.

Ja, Business Central stammt von NAV.Aber die Migration ist nicht mit einem Windows-Update vergleichbar. Die Architektur und das Entwicklungsmodell haben sich weiterentwickelt:

• NAV-Anpassungen wurden oft in C/AL erstellt.
• Business Central nutzt AL und Erweiterungen.
• Business Central SaaS hat andere Regeln (kein direkter SQL-Zugriff, strengere Sandbox-Umgebung).

Auch die Lizenzierung birgt Fallstricke. NAV verwendet üblicherweise die gleichzeitige Lizenzierung. Business Central hingegen basiert auf der benutzerbezogenen Lizenzierung; Finanzabteilungen bemerken diesen Unterschied oft sofort.

Wie Scope Creep in der Realität aussieht:
Ein Unternehmen glaubt, es habe „12 kleine Anpassungen“. Dann öffnet man die Objekte und stellt fest, dass drei davon die Hauptlast für Genehmigungen, Preislogik oder Lagerbewegungen tragen. Plötzlich muss man Prozesse neu gestalten, statt sie nur zu „migrieren“.

Wie man es vermeiden kann:
Gehen Sie bei der Planung wie bei der Einführung eines neuen ERP-Systems vor, selbst wenn Sie „im Microsoft-Universum bleiben“. So treffen Sie frühzeitig bessere Entscheidungen (und erleben später weniger böse Überraschungen).

Fehler 2: Auslassen der Datenbereinigung vor der Migration

Wenn wir eine Sache nennen müssten, die die größten Probleme beim Go-Live verursacht, dann wäre es Folgendes: unsaubere Daten, die in ein sauberes System gelangen.

Navigationsdatenbanken sammeln historische Daten. Sie sammeln aber auch unnötige Informationen:

• Doppelte Lieferanten/Kunden
• inaktive Elemente
• ungerade Maßeinheiten
• inkonsistente Kostenrechnungsmethoden
• Halb abgeschlossene Transaktionen, die niemand anfassen will.

Wenn Sie alles „so wie es ist“ migrieren, übernehmen Sie alle Probleme in Business Central und müssen diese nun beheben, während die Benutzer eine neue Benutzeroberfläche erlernen.

Was eine praktische Datenprüfung vor der Migration umfasst

Mindestens prüfen:

• Kunden & Lieferanten: Duplikate, fehlende Felder, inaktive Datensätze
• Artikel & Lagerbestand: Kostenkonsistenz, veraltete Artikelnummern, Mengeneinheiten-Inkonsistenzen
• Offene Transaktionen: nicht gebuchte Journale, überfällige Bestellungen/Lieferaufträge, veraltete Dokumente
• Kontenplan: ungenutzte Konten, Dimensionen, alte Kostenstellen
• Anforderungen an Audit/Historie: Was muss aus Compliance-Gründen migriert werden und was kann archiviert werden?

Wie man es vermeiden kann:
Behandeln Sie die Aufräumarbeiten als eigenen Arbeitsablauf. Führen Sie sie frühzeitig durch. Und testen Sie sie.

Fehler 3: Migration aller Anpassungen ohne vorherige Prüfung

Navigationssysteme neigen dazu, mit der Zeit „Seepocken“ anzusetzen.

Manche Anpassungen sind unerlässlich. Andere existieren, weil NAV etwas damals nicht unterstützte. Und manche sind einfach Überbleibsel eines Prozesses, den Sie vor Jahren eingestellt haben.

Wenn man alles unhinterfragt migriert, schafft man unnötige Komplexität.

Beibehalten / Ersetzen / Außer Betrieb nehmen: Eine einfache Methode zur Überprüfung bestehender NAV-Systeme

Für jede individuelle Anpassung fragen Sie bitte:

1. Benötigen wir diesen Geschäftsprozess noch?
2. Kann Business Central das jetzt nativ?
3. Wird es einfacher oder schlimmer, wenn wir es entfernen?

Schauen Sie auch in AppSource nach; oft gibt es dort eine unterstützte Erweiterung, die eine benutzerdefinierte Version ersetzt.

Fehler 4: Unterschätzung von Zeitaufwand und Kosten

NAV-zu-BC-Migrationen sind nicht umsonst für Kostenüberschreitungen berüchtigt: Die wahre Komplexität erkennt man erst bei genauerer Betrachtung:

• benutzerdefinierte Objekte
• Integrationen
• Datenqualität
• Berichtspflichten
• wie Benutzer Genau Genau genommen Arbeit (nicht wie Prozesse auf dem Papier aussehen)

Eine Entscheidung, die alles beeinflusst, ist die Art und Weise der Umstellung.

Stufenweise Migration vs. abrupte Umstellung

Wie man es vermeiden kann:
Wählen Sie Ihre Vorgehensweise basierend auf Risiko und Komplexität. Nicht Optimismus. Für viele KMU ist eine schrittweise Einführung einfach sicherer.

Fehler 5: Integrationskompatibilität ignorieren

Dieses Problem tritt meist spät auf, genau dann, wenn niemand Zeit hat.

Business Central setzt auf API-basierte Architektur. NAV-Integrationen basierten häufig auf älteren Webdiensten, Dateiübertragungen oder Datenbankzugriffen. Diese Ansätze lassen sich nicht nahtlos integrieren.

Die Integration Ihres Shopify/CRM/WMS/Gehaltsabrechnungssystems ist möglicherweise weiterhin möglich, erfordert aber unter Umständen einen neuen Konnektor oder eine Neugestaltung.

Wie Sie Integrationen vor dem Start prüfen

• Listen Sie alle mit NAV verbundenen Systeme auf (einschließlich einmaliger Skripte).
• Ermitteln Sie, ob direkter Datenbankzugriff, Webdienste oder eine API verwendet werden.
• Prüfen Sie den API-Ansatz von BC, um zu erfahren, welche Änderungen vorgenommen wurden.
• Flaggenverkäufer, die nicht bestätigte BC-Kompatibilität haben.
• Planen Sie Integrationen als separate Arbeitsabläufe, nicht als „Aufgaben der Go-Live-Woche“.

Fehler 6: Die Wahl zwischen SaaS und On-Premise aus den falschen Gründen

„SaaS ist modern“ und „On-Premise fühlt sich sicherer an“ sind beide emotionale Entscheidungen. Diese hier sollte jedoch pragmatisch sein.

Business Central SaaS eignet sich hervorragend für viele KMUs:

• automatische Updates
• von Microsoft verwaltete Infrastruktur
• Zugriff auf die Copilot/KI-Roadmap

Es bedeutet aber auch:

• kein direkter SQL-Zugriff
• strengere Verlängerungsregeln
• andere Steuerungen und Einschränkungen als bei On-Premise-Lösungen

Fehler 7: Auslassen von Benutzerschulungen und Änderungsmanagement

Man kann die Technologie perfekt umsetzen und das Projekt trotzdem scheitern lassen, wenn die Nutzer sie nicht annehmen.

Business Central sieht anders aus. Die Navigation ändert sich. Die Rollenzentren ändern sich. Und die in NAV aufgebaute „Muskelroutine“ wird nicht automatisch übernommen.

Wie man es vermeiden kann (ohne das Training schmerzhaft zu gestalten):

• Wählen Sie 2–3 interne Champions (Finanzen, Betrieb/Lager, Vertrieb)
• Führen Sie rollenbasierte Schulungen durch (nicht eine allgemeine Schulung für alle).
• Gewähren Sie mindestens 3 Wochen vor dem Go-Live Zugriff auf die Sandbox.
• Richten Sie ein einfaches internes FAQ- und Ticketsystem ein.

Fehler 8: Übereilte UAT- und Sandbox-Tests

Bei der Benutzerakzeptanzprüfung (UAT) wird aus „sieht gut aus“ „funktioniert im realen Leben“.

Wenn die Benutzerakzeptanztests komprimiert werden, treten die Fehler erst nach der Produktivsetzung auf, wenn sie teurer und stressiger sind.

Häufige Probleme, die bei überhasteten Benutzerakzeptanztests auftreten:

• Die Lagerkosten/Herstellungskosten verhalten sich anders
• Die Abmessungen werden nicht korrekt zugeordnet.
• Genehmigungen/Workflows brechen
• Berichte stimmen nicht mit dem Navigationsverlauf überein
• Berechtigungen, die echte Benutzer blockieren

Praktische UAT-Checkliste (einfach, aber realistisch)

• Finanzen: Bankabstimmung, Umsatzsteuerbuchung und Periodenabschluss
• Lager/Betrieb: Wareneingang, Kommissionierung, Versand, Korrekturen
• Vertrieb: Auftragserfassung, Preisgestaltung, Kreditlimits
• Integrationen: End-to-End-Transaktionen über alle verbundenen Systeme hinweg.
• Berichte: Validierung der Kernberichte anhand der NAV-Baseline
• Berechtigungen: Test pro Rolle (nicht nur Administrator)

Fehler 9: Kein Hypercare- oder Rollback-Plan

Der Go-Live ist nicht das Ziel. Er ist der Beginn der Phase im „realen Alltag“.

Ohne Hypercare muss Ihr Team am Ende zwei Aufgaben gleichzeitig erledigen:

1. Das Unternehmen führen
2. Behebung der Migrationsfolgen

Und wenn in den ersten 48 Stunden etwas Kritisches schiefgeht, brauchen Sie einen Entscheidungsrahmen, keine Panik.

Wie man es vermeiden kann:

• Planen Sie ein 1- bis 4-wöchiges Hypercare-Fenster (mit klarer Kostendeckung).
• Definieren Sie Rollback-Trigger, Entscheidungsträger und Rollback-Schritte.
• Wählen Sie einen geeigneten Starttermin.

Fehler 10: Allein unterwegs sein (oder den falschen Partner wählen)

Dies ist es, was im Stillen alles bestimmt.

Ein Partner, der bereits „Business Central-Implementierungen“ durchgeführt hat, ist nicht automatisch der richtige Ansprechpartner für eine NAV-zu-BC-Migration, insbesondere wenn Ihre Lösung kundenspezifisch, integrationsintensiv oder branchenspezifisch ist.

Was ein echter NAV-zu-BC-Spezialist anders macht

• Fragt frühzeitig nach Ihrer NAV-Version
• verfügt über interne KI-Entwickler
• zeigt branchenrelevante Fallstudien
• prüft Anpassungen vor der Angebotserstellung
• beinhaltet Hypercare als Standard

Wie erfolgreiche NAV-Migrationen aussehen

Ein britischer Hersteller, der NAV 2015 einsetzte, hatte 23 Anpassungen vorgenommen. Anstatt alles neu zu implementieren, prüfte er 14 Anpassungen, die Business Central nativ verarbeiten konnte, und entfernte sie. Die verbleibenden 9 wurden als AL-Erweiterungen neu implementiert.

Ergebnis: Die Inbetriebnahme dauerte 18 Wochen (statt sich in die Länge zu ziehen), und der Periodenabschluss erfolgte nach der Migration merklich schneller.

Abschluss

Keiner dieser Fehler ist unvermeidbar. Sie kommen nur häufig vor, insbesondere wenn Teams unter Zeitdruck stehen.

Wenn Sie den einfachsten „Erledigen Sie dies zuerst“-Plan wünschen:

• Beginnen Sie mit einer Systemanalyse
• Führen Sie eine Anpassungsprüfung durch (bevor Sie sich auf Zeitpläne festlegen).
• Behandeln Sie die Datenbereinigung als einen echten Arbeitsablauf.
• Die Entscheidung zwischen schrittweiser und radikaler Umstellung sollte auf dem Risiko und nicht auf der Hoffnung basieren.

Wenn die Fristen bis 2026 dies dringlich machen, ist das verständlich. Dringlichkeit muss aber nicht Hektik bedeuten. Die schnellsten Migrationen sind in der Regel die am besten geplanten.