Dynamics NAV auf Business Central: technisches Upgrade oder ehrlicher Umbau?

Bei schlankem, standardnahem NAV kann der Weg ein echter Upgrade-Pfad sein. Bei stark angepasstem NAV ist es kein reines technisches Upgrade: Jahre an C/AL-Anpassungen laufen in Business Central nicht automatisch weiter. NAV und BC teilen zwar dieselbe Wurzel, der Bruch liegt aber im Anpassungsmodell. C/AL griff direkt ins Objekt ein, AL-Extensions fassen den Standard nicht mehr an. Jede Alt-Anpassung braucht deshalb eine bewusste Entscheidung: sauber als Extension nachbauen, auf den Standard zurückführen, was oft der bessere Weg ist, oder als Ballast weglassen. Meist ist der wirklich differenzierende Anteil kleiner als gedacht. Der zweite große Block ist die Datenbereinigung: NAV-Datenbanken tragen über Jahre Dubletten, verwaiste Einträge und zweckentfremdete Felder. Diese eins zu eins zu übernehmen zementiert alte Probleme in einer Oberfläche, die jeden Fehler unbarmherzig zeigt.

Warum liegt der Bruch im Anpassungsmodell?

NAV und BC teilen dieselbe Wurzel, das verführt zur Annahme eines glatten Upgrades. Der eigentliche Bruch liegt aber im Anpassungsmodell: C/AL-Eingriffe direkt im Objekt weichen dem Extension-Modell (AL), das den Standard nicht mehr anfasst.

Quelle: Microsoft Learn: Development in AL

• Jede Alt-Anpassung braucht eine bewusste Entscheidung: als AL-Extension sauber nachbauen, auf BC-Standard zurückführen (oft der bessere Weg) oder als Ballast weglassen. Meist ist der wirklich differenzierende Anteil kleiner als gedacht.
• Datenbereinigung ist der zweite große Block. NAV-Datenbanken tragen über Jahre Dubletten, verwaiste Einträge und zweckentfremdete Felder. Diese 1:1 zu übernehmen, zementiert alte Probleme in einer Oberfläche, die jeden Fehler unbarmherzig zeigt. Der Umstieg ist der günstigste Moment, diesen Ballast loszuwerden, weil er ohnehin einen Datenschnitt bedeutet.

Wie hoch ist der Aufwand ehrlich betrachtet?

Ein stark angepasstes NAV zu heben ist näher an einem Neuaufbau mit Datenübernahme als an einem Klick-Upgrade. Wer ein reines Upgrade in wenigen Wochen verspricht, hat den tatsächlichen Anpassungsstand nicht angesehen.

Die belastbare Aussage kommt erst nach einem Blick auf Code und Datenbasis, nicht davor. Praktisch heißt das: Objektliste mit allen Eingriffen, Bewertung je Eingriff, und daraus eine belastbare Spanne mit offengelegten Annahmen. Diese Vorarbeit dauert Tage und nicht Wochen, und sie entscheidet über die Verlässlichkeit jeder späteren Terminzusage.

Der häufigste Irrtum ist dabei, den Aufwand an der Datenmenge zu messen. Entscheidend ist die Zahl der Kerneingriffe und der Dokumentationsstand, denn beides bestimmt, wie viel fachlich neu entschieden werden muss. Eine kleine Datenbank mit sechzig Kerneingriffen kostet mehr Aufwand als eine große mit fünf.

Was kommt mit, und wer entscheidet das?

Am Ende ist die Frage nicht technisch, sondern strategisch: Welche gewachsene Logik ist echter Wettbewerbsvorteil, welche nur historischer Ballast? Diese Entscheidung gehört zu Ihnen, denn sie betrifft Ihr Geschäft und nicht die Plattform.

Ein brauchbares Verfahren dafür ist einfach: Für jede Anpassung wird benannt, welchen Zweck sie erfüllt und wer diesen Zweck heute noch bestätigt. Was niemand bestätigen kann, ist Ballast, und das sind in der Praxis überraschend viele Objekte. Diese Übung kostet wenige Tage und entscheidet über Monate Projektaufwand, weil jeder mitgenommene Sonderweg einmal getestet, einmal dokumentiert und dann jahrelang gepflegt werden muss.

Die Steuerung bleibt auf Ihrer Seite, mit Business Central als Heimat. Bevor jemand ein technisches Upgrade verspricht: Lassen Sie uns Ihren NAV-Anpassungsstand und Ihre Datenbasis ansehen und den ehrlichen Weg zeigen.

Welche Frage beginnt nach dem Upgrade?

Ein Upgrade bringt Sie auf den aktuellen Versionsstand. Das ist notwendig, aber es ist noch nicht das eigentliche Ziel. Denn ein frisch migriertes Business Central kann technisch tagesaktuell sein und trotzdem abbilden, was Ihr Geschäft vor sieben Jahren getan hat.

Wer den Umstieg schon macht, sollte ihn deshalb gleich richtig nutzen: als Moment, in dem Datenbasis, Prozesse und Verantwortlichkeiten so aufgestellt werden, dass neue Anforderungen künftig Wochen dauern und nicht mehr Quartale. Das meinen wir mit Evergreen ERP.

Der Unterschied ist messbar, und zwar an einer einzigen Größe: der Zeit von der Geschäftsanforderung bis zu ihrer Umsetzung im System. Wer diese Zahl vor und nach dem Umstieg kennt, weiß, ob das Projekt mehr gebracht hat als einen neuen Versionsstand. Ohne diese Messung bleibt der Projekterfolg eine Behauptung, die niemand nachprüfen kann.