Filip Jacobi, freiberuflicher Business Central Entwickler← Zur Startseite

Navision Migration komplexe Systeme

Navision Migration komplexe Systeme

NAV-Altanpassungen die niemand mehr anfassen will

NAV-Migration mit vielen Anpassungen? C/AL-Legacy-Code analysieren, bewerten was sich lohnt — und stark angepasste Systeme sicher nach BC migrieren.

Die NAV-Migration die kein Systemhaus anfassen will

Es gibt eine bestimmte Art von Navision-System, vor der viele Partner zurückschrecken: Zehn oder mehr Jahre im Einsatz. Hunderte von C/AL-Anpassungen. Der Entwickler, der das meiste davon gebaut hat, ist längst weg. Dokumentation existiert kaum oder gar nicht. Das System läuft — aber niemand mehr weiß genau wie.

Wenn solche Kunden einen Partner für die Migration nach Business Central suchen, bekommen sie oft ähnliche Antworten: zu komplex, zu aufwändig, oder ein Angebot für einen Komplettneubau der gesamten Lösung zu einem sechsstelligen Budget.

Dabei ist das selten nötig. Aber es braucht jemanden, der bereit ist, sich in unbekannten C/AL-Code hineinzudenken — und der die Unterschiede zwischen C/AL und AL gut genug kennt, um zu beurteilen was sich wie migrieren lässt.

Warum stark angepasste NAV-Systeme besondere Anforderungen haben

Eine Standard-Navision-Migration zu Business Central ist heute ein gut dokumentierter Prozess. Microsoft stellt Migrationswerkzeuge bereit, und für typische Grundimplementierungen ist der Weg klar.

Bei stark angepassten Systemen ändert sich das:

C/AL-Code enthält keine Trennung zwischen UI und Logik. In altem C/AL ist es üblich, Business-Logik direkt in Formular-Triggern zu implementieren. In modernem AL erwartet Microsoft eine saubere Trennung — was bedeutet, dass der Code nicht einfach 1:1 übertragen werden kann.

Direct-Table-Modifikationen. In C/AL war es normal, Basistabellen direkt zu modifizieren. Das ist in AL-Extensions nicht mehr möglich — es müssen Table Extensions und Event Subscriptions verwendet werden. Bei tief greifenden Anpassungen bedeutet das eine Neu-Architektur, keine simple Konvertierung.

Keine Compiler-Hilfe für fehlendes Wissen. Wenn niemand mehr weiß was ein altes Code-Modul macht, gibt es keinen automatischen Weg, das herauszufinden. Es braucht manuelle Analyse.

Datenmigration bei modifizierten Tabellenstrukturen. Wenn Basistabellen angepasst wurden — neue Felder, andere Schlüssel, veränderte Datentypen — ist die Datenmigration komplexer als eine Standard-Migration.

Was ich anbiete

Legacy-Code-Analyse

Bevor eine Entscheidung über den Migrationspfad getroffen wird, muss klar sein, was wirklich vorhanden ist. Ich analysiere den C/AL-Code systematisch:

Das Ergebnis ist eine klare Entscheidungsgrundlage: Migrationsstrategie, Aufwandsschätzung, Risikoübersicht.

Stufenweise Migration

Für stark angepasste Systeme ist eine Stufenmigration oft der sicherste Weg. Nicht alles auf einmal — sondern priorisiert nach Geschäftskritikalität.

Ich entwickle einen Migrationsplan, der die wichtigsten Prozesse zuerst stabilisiert, und der Go-live ermöglicht, bevor jede einzelne Altanpassung vollständig portiert ist. Was nach Go-live nicht mehr gebraucht wird, kommt gar nicht mit. Was mit niedrigerer Priorität migriert werden kann, folgt in einer zweiten Phase.

C/AL zu AL Extension-Entwicklung

Die eigentliche Migrationsarbeit: C/AL-Logik in moderne AL-Extensions überführen. Das bedeutet in der Praxis:

Datenmigration

Ich begleite die Datenmigration mit besonderem Fokus auf angepasste Tabellenstrukturen: Felder die in der alten Datenbank existierten und in BC anders abgebildet werden müssen. Transformationslogik für Daten die sich im Datenmodell verändert haben. Prüfläufe vor dem Go-live.

Für wen ist das relevant?

Diese Unterstützung ist für euch, wenn:

Praxisbeispiel

Ein Produktionsbetrieb läuft seit 14 Jahren auf Navision 2013 mit über 60 C/AL-Anpassungen — Fertigungssteuerung, Lohnmandant-Auswertungen, proprietäres Berichtssystem. Zwei Partner haben die Migration nach BC abgelehnt: zu viele Anpassungen, kein Durchblick.

Die Legacy-Code-Analyse zeigt: Von 60 Anpassungen sind 18 geschäftskritisch und müssen vollständig migriert werden. 22 sind veraltet und nicht mehr in aktiver Nutzung — die können weg. 20 lassen sich durch BC-Standardfunktionen ersetzen, die 2013 noch nicht existiert haben.

Effektiver Migrationsaufwand: deutlich kleiner als ursprünglich befürchtet. Alle wesentlichen Altanpassungen wurden erfolgreich in AL-Extensions überführt. Keine verlorenen Prozesse. Produktiver Go-live vier Monate nach Projektstart.

Häufige Fragen

Gibt es einen direkten Upgrade-Pfad von Navision 2013 auf aktuelle BC-Versionen?

Seit BC 2025 Wave 1 ist kein Direktupgrade mehr von BC Version 14 (das entspricht NAV 2018 / BC 2019) auf die aktuelle Version möglich — Zwischenschritte sind erzwungen. Bei älteren Versionen wie NAV 2013 braucht es mehrere Stufen. Das erhöht den Aufwand, ist aber planbar. Ich zeige euch den konkreten Pfad für euer System.

Was passiert mit Daten die in angepassten Feldern stecken?

Das hängt davon ab, wie die Felder in der Zielstruktur abgebildet werden. Bei Table Extensions in BC können Felder identisch weitergeführt werden. Bei Felder, die in BC anders strukturiert werden müssen, schreibe ich Transformationslogik für die Datenmigration. Keine Daten gehen verloren — sie kommen in der neuen Struktur an.

Wie viel von unserem alten C/AL-Code ist in BC noch brauchbar?

Meistens weniger als man hofft — aber mehr als neue Systeme suggerieren. C/AL-Code kann mit Microsoft-Werkzeugen nach AL konvertiert werden. Das Ergebnis ist aber kein sauberer AL-Code, sondern ein Ausgangspunkt für Refactoring. Ich bewerte für jede Anpassung, ob konvertierter Code als Basis taugt oder ob ein Neuschrieb schneller und sauberer ist.

Könnt ihr während der Migration produktiv weiterarbeiten?

Ja — das ist eines der Ziele der stufenweisen Migration. Solange das NAV-System läuft, laufen Produktionsprozesse darauf weiter. BC wird parallel aufgebaut und getestet, bis es produktionsreif ist. Den Go-live planen wir gemeinsam so, dass er kein unnötiges Risiko darstellt.

Wie läuft das Erstgespräch ab?

30 Minuten. Du schilderst mir das Problem, ich sage dir ob und wie ich helfen kann — direkt, ohne Präsentation. Danach bekommst du eine schriftliche Einschätzung mit Aufwand und Vorgehen. Erst dann entscheidest du ob wir starten.


Erstgespräch kostenlos — ich schaue mir euer Setup an.

Jetzt anfragen

Kein Jahresvertrag. Kein Mindestvolumen. Du zahlst für das gelöste Problem.

Weitere Themen: Navision Migration Business Central · Navision Upgrade 2025 · Business Central Extension Update Fehler

Verwandte Seiten

Über mich

Filip JacobiBusiness Central Solution Architect

Freiberuflicher BC-Entwickler und Consultant aus Bochum. Ich arbeite direkt mit eurem Fachbereich — ohne Agentur-Overhead, ohne Account-Staffelung. Remote und vor Ort in NRW verfügbar.

Mehr über mich und meine Leistungen