Navision Migration NRW komplexe Systeme
Klarer Zeitplan trotz Legacy-Code
Navision Migration NRW: Realistischer Zeitplan für stark angepasste NAV-Systeme. Logistik, Stahl, Industrie — ich kenne diese Systeme. Kein Systemhaus.
Nordrhein-Westfalen — insbesondere das Ruhrgebiet — hat die höchste Dichte an Navision-Altinstallationen in Deutschland. Der Grund ist historisch: In den 2000er Jahren war das Ruhrgebiet eines der aktivsten Navision-Einführungsgebiete Deutschlands. Produzierendes Gewerbe, Stahlindustrie, Logistik, Großhandel — Branchen, die früh auf ERP gesetzt haben und Navision damals als robuste, anpassungsfähige Lösung eingeführt haben.
Zwanzig Jahre später laufen viele dieser Systeme immer noch. Oft auf NAV 2009, NAV 2013 oder NAV 2015 — tief angepasst, mit hunderten von C/AL-Modifikationen, mit Schnittstellen zu Produktionssteuerungen, Lagerverwaltungssystemen oder branchenspezifischen Tools die es heute oft gar nicht mehr gibt. Und mit einer Dokumentation die bestenfalls lückenhaft und schlechtestenfalls gar nicht vorhanden ist.
Diese Systeme zu migrieren ist keine Standardaufgabe. Es ist eine technische Herausforderung, die Erfahrung mit Legacy-Code und ein realistisches Verständnis von Migrationskomplexität erfordert — bevor man überhaupt einen Zeitplan ansetzt.
Die typischen NRW-Branchen — Stahl und Metall, Logistik, produzierendes Gewerbe, technischer Großhandel — haben spezifische Anforderungen die tief in ihre Navision-Systeme eingebaut sind.
Stahlhandel und Metallverarbeitung: Chargen- und Seriennummernverwaltung, Längen- und Flächeneinheiten, Zertifikatsverwaltung, Schnittstellen zu Coil-Managementsystemen oder Lagerautomaten — oft als direkte C/AL-Tabellenmodifikationen implementiert, nicht als saubere Extensions.
Logistik und Spedition: Touren- und Frachtplanung, Frachtkostenberechnung, Schnittstellen zu Telematiksystemen, Paketdienstleister-Integrationen. Viele dieser Schnittstellen wurden in den 2000er Jahren als proprietäre C/AL-Module gebaut, deren ursprüngliche Entwickler längst nicht mehr verfügbar sind.
Produzierendes Gewerbe allgemein: Fertigungsaufträge mit branchenspezifischen Workflows, Kapazitätsplanung, Stücklisten-Strukturen die tief in die Basis-Tabellen eingreifen.
All diese Systeme teilen ein Problem: Sie wurden so stark modifiziert, dass eine Standard-Migration nicht funktioniert. Der Zeitplan muss diesen Aufwand realistisch abbilden.
Bevor jemand anfängt zu migrieren, muss klar sein was wirklich im System steckt. Ich analysiere euer NAV-System systematisch:
Das Ergebnis ist ein realistischer Zeitplan — mit Puffern, klaren Abhängigkeiten und einem ehrlichen Bild der Komplexität.
Ich begleite die Migration technisch — als Ansprechpartner für AL-Code, Datenstruktur und Schnittstellenarchitektur. Kein theoretisches Projektmanagement, sondern direkte technische Verantwortung für die kritischen Stellen.
Die Konvertierung von C/AL-Modifikationen nach AL ist technisch anspruchsvoll — besonders wenn direkte Tabellenmodifikationen in Table Extensions umgebaut werden müssen und dabei die Geschäftslogik korrekt erhalten bleiben muss. Ich mache das mit Verständnis für die ursprüngliche Funktion, nicht nur mechanisch.
Wenn alte Schnittstellen auf veralteten Protokollen laufen die BC nicht mehr unterstützt, baue ich sie neu — als saubere REST-API-Integration oder über Microsoft Power Automate, mit klarer Dokumentation für den laufenden Betrieb.
Ich plane die Testphase strukturiert: welche Geschäftsprozesse müssen abgedeckt sein, wie läuft die Parallelintegration, wie wird der Cut-over organisiert, damit der Betrieb nicht unterbrochen wird.
Diese Unterstützung ist sinnvoll, wenn:
Migrationsdauer: klar kalkuliert statt endlos verlängert
Ein metallverarbeitender Betrieb aus dem Ruhrgebiet mit 80 Mitarbeitern betreibt NAV 2013 mit umfangreichen Anpassungen: Chargenverwaltung, eine eigene Zertifikatsverwaltung, direkte Modifikationen an Fertigungsauftrags-Tabellen und eine Schnittstelle zu einem älteren Lagerverwaltungssystem über COM-Schnittstelle.
Das erste Migrationsangebot eines Systemhauses: 6 Monate, Festpreis. Tatsächlich klingt das sportlich — die COM-Schnittstelle allein ist ein Risikofaktor ohne belastbare Schätzung.
Eine vorgelagerte Migrationsanalyse (10 Arbeitstage) liefert: 47 direkte C/AL-Tabellenmodifikationen, davon 12 in der Fertigungsmodul-Basis die neu gebaut werden müssen, nicht nur portiert. Die COM-Schnittstelle ist nicht migrierbar — der Zielzustand muss über eine REST-API neu gebaut werden, was 3 Wochen zusätzlich bedeutet. Datenqualitätsprobleme in der Chargenverwaltung erfordern ein Bereinigungsprojekt vor der Migration.
Realistischer Zeitplan auf Basis der Analyse: 9 bis 11 Monate, aufgeteilt in drei klar getrennte Phasen mit Meilensteinen. Kein Blindflug mehr — ein Zeitplan der hält.
Wir sind im Ruhrgebiet und haben NAV seit 15 Jahren — kann das wirklich auf BC migriert werden?
Ja, aber der Aufwand hängt stark von den Modifikationen ab. Es gibt keine pauschale Antwort. Was ich sagen kann: Systeme die noch tiefer in die Basis eingreifen als standard — also direkte C/AL-Modifikationen statt sauberer Extensions — sind migrierbar, aber der Portierungsaufwand ist real. Eine ehrliche Analyse ist immer der erste Schritt.
Warum einen Freelancer statt ein Systemhaus für eine komplexe Migration beauftragen?
Ein Freelancer ist keine Alternative zu einem Systemhaus für die gesamte Migration — aber ein unabhängiger Spezialist für die technisch kritischen Teile. Ich mache Migrationsanalysen, technische Leitungsaufgaben und komplexe AL-Portierungen, die ein Systemhaus intern an Junioren übergibt. Du weißt immer genau, wer die Arbeit macht.
Was ist der Unterschied zwischen einer Migration und einer Neuimplementierung?
Eine Migration überträgt Geschäftslogik und Daten aus dem alten System. Eine Neuimplementierung startet mit den aktuellen Anforderungen und ignoriert das alte System weitgehend. Für stark angepasste NAV-Systeme ist manchmal eine Mischform sinnvoll: bestimmte Module neu implementieren, andere portieren. Das kläre ich in der Migrationsanalyse.
Können wir während der Migration normal weiterarbeiten?
Ja — mit der richtigen Planung. Das Ziel ist eine Parallelintegration mit klar definiertem Cut-over-Datum. Das Unternehmen arbeitet bis zum Stichtag im alten System weiter, dann wird umgestellt. Die Planung dafür ist Teil meiner Migrationsbegleitung.
Migration geplant oder steckt fest? Schreib mir — ich schaue es mir an.
Weitere Themen: Navision Migration komplexe Systeme · Navision Berater NRW
Über mich
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 LeistungenSchreib mir eine Nachricht oder ruf direkt an.
