Migration
Der technische Weg von Dynamics NAV nach Business Central ist dokumentiert und planbar. Die eigentliche Frage lautet: Welche regulatorisch relevanten Datenbestände und Prozesse müssen den Systemwechsel überleben, in welcher Form und mit welchem Nachweis? Wer diese Frage erst am Cutover-Wochenende stellt, hat sie schon falsch beantwortet.
Ablösung von Dynamics NAV und AX bei AENUMA · Supportende der NAV-Versionen · Business Central für Medizintechnik
Der Zeitdruck ist real. Der Extended Support für Dynamics NAV 2017 endet am 11. Januar 2027, für NAV 2018 am 11. Januar 2028. NAV 2016 ist seit dem 14. April 2026 aus dem Support, NAV 2015 seit dem 14. Januar 2025. Wer heute noch auf einer dieser Versionen produziert, hat für ein sauber geführtes Projekt genau noch ein Zeitfenster.
Microsoft beschreibt den Pfad eindeutig: Von NAV führt kein direkter Weg in die Cloud. Zuerst Business Central on-premises Version 14, dann Version 25 oder höher, erst danach die Online-Umgebung. Alle C/AL-Anpassungen müssen zu AL-Extensions werden, sonst lassen sich die Daten der betroffenen Tabellen nicht übernehmen. Die Alternative, das Reimplementierungswerkzeug für Version 14, überträgt Stammdaten, offene Vorgänge, Eröffnungssalden, die Einrichtung und eine definierte Teilmenge gebuchter historischer Posten, nicht aber die vollständige Buchungshistorie. Microsoft führt dieses Werkzeug derzeit als Vorschaufunktion und nicht für den Produktiveinsatz. Für einen Hersteller mit Rückverfolgbarkeitspflicht ist das eine Entscheidung, die man nicht nebenbei trifft.
Artikel 10 Absatz 8 der MDR verlangt, dass Hersteller die technische Dokumentation und die EU-Konformitätserklärung noch mindestens zehn Jahre nach dem Inverkehrbringen des letzten erfassten Produkts für die Behörden bereithalten. Bei implantierbaren Produkten sind es mindestens 15 Jahre. Die IVDR enthält eine entsprechende Aufbewahrungsvorschrift für In-vitro-Diagnostika.
Artikel 25 Absatz 2 der MDR, Identifizierung innerhalb der Lieferkette, verlangt für den in Artikel 10 Absatz 8 genannten Zeitraum, dass ein Wirtschaftsakteur jeden Wirtschaftsakteur benennen kann, an den er ein Produkt abgegeben hat, jeden Wirtschaftsakteur, der ihm eines geliefert hat, sowie jede Gesundheitseinrichtung und jeden Angehörigen der Gesundheitsberufe, an die er unmittelbar abgegeben hat. Das ist keine Dokumentationspflicht im Aktenschrank, sondern eine Auskunftsfähigkeit. Sie muss auch dann noch funktionieren, wenn das System, in dem die Bewegung ursprünglich gebucht wurde, seit Jahren abgeschaltet ist. ISO 13485:2016 verlangt in Abschnitt 4.2.5 zusätzlich eine definierte Aufbewahrungsdauer für Aufzeichnungen, die an die Lebensdauer des Produkts gekoppelt ist.
Keine dieser Vorgaben schreibt ein bestimmtes System vor. Verlangt wird die Verfügbarkeit gegenüber den Behörden. Daraus folgt nach unserer Auslegung, dass die Daten belastbar, vollständig und in vertretbarer Zeit auffindbar sein müssen, nicht aber, dass sie im produktiven ERP liegen. Diese Unterscheidung ist der ganze Hebel des Projekts.
Aus dieser Unterscheidung folgen drei Optionen pro Datenbestand: übernehmen, neu aufbauen oder kontrolliert archivieren. Der Reflex „wir nehmen alles mit“ ist die teuerste und regulatorisch schwächste Variante. Teuer, weil jede übernommene Tabelle getestet, gemappt und nach dem Umzug verifiziert werden muss. Schwach, weil eine Datenbank voller historisch gewachsener Inkonsistenzen im Audit keine Aussage stützt, sondern Fragen erzeugt.
| Datenbestand | Regulatorischer Grund | Empfohlener Weg |
|---|---|---|
| Chargen- und Seriennummernhistorie aktiver Produkte | Rückruffähigkeit und Auskunft entlang der Lieferkette | Übernehmen |
| Historie abgekündigter Produkte innerhalb der Frist | Aufbewahrungspflicht nach MDR Artikel 10 Absatz 8 | Kontrolliert archivieren |
| Qualitätsstatus und Sperrkennzeichen | Freigabesteuerung, keine stillschweigende Freigabe | Übernehmen, mit Abgleich Zeile für Zeile |
| Lieferantenfreigaben und aktuelle Bewertungsstände | Beschaffungslenkung nach ISO 13485, Abschnitt 7.4 | Übernehmen |
| Historische Bewertungszyklen und alte Erstmusterprüfberichte | Nachweis der Lieferantenlenkung über die Zeit | Kontrolliert archivieren |
| Artikel-, UDI- und Verpackungsstammdaten | UDI-Zuordnung und Datenqualität gegenüber EUDAMED | Neu aufbauen |
| C/AL-Anpassungen ohne Prozessbezug | Kein regulatorischer oder betriebswirtschaftlicher Zweck nachweisbar | Streichen |
Ein Hersteller muss auch drei Jahre nach dem Systemwechsel eine Behördenanfrage zu Altbeständen beantworten und einen Rückruf über Altbestände abwickeln können. Business Central bietet dafür Item Tracing und Find Entries, beides setzt konsistente Artikelposten und Item-Tracking-Einträge voraus. Die praktische Trennlinie verläuft entlang des Produktlebenszyklus: Chargen von Produkten, die noch im Markt sind oder deren Verwendungsdauer noch läuft, gehören in die produktive Datenbank. Chargen von Produkten, die seit Jahren abgekündigt sind und deren Aufbewahrungsfrist trotzdem läuft, gehören in ein definiertes Archiv mit dokumentiertem Zugriffsweg. Wie diese Trennung technisch sauber gelingt, behandeln wir vertieft unter Chargenrückverfolgbarkeit im ERP.
Nach unserer Erfahrung wird dieser Bereich regelmäßig unterschätzt, weil er in NAV oft halb im System und halb in Excel lebt. Zu klären sind vier Dinge: Welche Lieferanten sind aktuell freigegeben, für welche Artikel und Prozesse, seit wann? Welche sind gesperrt und aus welchem Grund? Welcher Bewertungsstand ist der aktuell gültige, und welche sind Historie? Wo liegen Erstmusterprüfberichte und wie sind sie mit Artikel und Lieferant verknüpft? Business Central kennt eine Kreditorensperre mit den Stufen Zahlung und Alle. Sie ersetzt keine Qualifizierungslogik, sie setzt sie nur durch. Der Status selbst muss modelliert werden, und der Systemwechsel ist der Moment, ihn aus der Excel-Schattenwelt zurückzuholen.
Der teuerste Fehler dieser Projekte ist leise, und er trifft vor allem Reimplementierungen und manuelle Datenübernahmen: Eine gesperrte Charge entsteht im Zielsystem ohne Sperrkennzeichen und ist damit ab Tag eins verkaufsfähig. Business Central kennt Sperren auf mehreren Ebenen, auf dem Artikel über Verkauf, Einkauf, Produktion und Service, und auf der Charge über das Feld Blocked auf der Chargennummerninformationskarte. Diese Ebenen sind fachlich nicht austauschbar. Wer eine NAV-Sperrlogik migriert, braucht deshalb eine explizite Abbildungsregel je Sperrgrund und eine Prüfung nach dem Umzug, die die Anzahl gesperrter Chargen und Artikel im Quell- und Zielsystem gegenüberstellt. Nicht stichprobenhaft, sondern vollständig.
Der Systemwechsel ist der beste und zugleich der letzte billige Zeitpunkt, das Artikelstammdatenmodell zu bereinigen. Danach kostet jede Änderung Änderungskontrolle. MDCG 2021-19 beschreibt, was das QMS dafür leisten muss: geregelte UDI-Zuteilung, definierte Verfahren für Änderungen an UDI-relevanten Attributen und die Pflicht, die Liste der zugeteilten UDI aktuell zu halten. Praktisch heißt das: Basis-UDI-DI, UDI-DI je Verpackungsebene, GTIN, Produktvariante und Nummernkreise gehören in ein sauber definiertes Modell aus Artikel, Varianten, Artikelreferenzen und Attributen, nicht in freie Textfelder. Microsoft verlangt vor der Migration ohnehin eine Datenbereinigung: Unzulässige Zeichen in Code-Feldern müssen vorher entfernt werden, sonst schlagen spätere Lese-, Schreib- und Löschvorgänge auf diesen Feldern in der Cloud fehl. Was dabei an Struktur entsteht, zahlt direkt auf die UDI-Daten und EUDAMED-Meldungen ein.
Jede C/AL-Anpassung muss zu einer AL-Extension werden. Das erzwingt eine Frage, die zehn Jahre lang niemand stellen musste: Welcher Teil davon war je ein Geschäftsprozess und welcher nur Gewohnheit? Nach unserer Projekterfahrung bildet ein Teil der Anpassungen Anforderungen ab, die der Standard heute abdeckt, oder Sonderwege aus einer längst gelösten Einschränkung. Der Prüfmaßstab ist eng: Für jede Anpassung muss benannt werden, welche Prozessanforderung sie erfüllt und welche regulatorische oder betriebswirtschaftliche Folge ihr Wegfall hätte. Was diesen Maßstab nicht erfüllt, wird nicht portiert.
Die Migration selbst ist eine kontrollierte Änderung. Sie braucht einen Plan, Akzeptanzkriterien und einen dokumentierten Nachweis, dass die Daten nach dem Umzug vollständig und korrekt sind. Microsoft empfiehlt mindestens einen vollständigen Probelauf in einer Sandbox vor dem produktiven Cutover, mit gemessenen Laufzeiten und fachlicher Abnahme. Für einen Medizinproduktehersteller ist das Minimum: Mengenabgleich je kritischer Tabelle, Stichprobenprüfung entlang vollständiger Rückverfolgungsketten vom Wareneingang bis zum Kunden, Vollprüfung aller Sperrzustände sowie ein Migrationsbericht, der Quelle, Ziel, Abweichung und Entscheidung dokumentiert. Wie dieser Nachweis aufgebaut wird, beschreiben wir unter Nachweisführung bei der Datenmigration. Den Rahmen dazu liefert die Validierung von Dynamics 365.
Müssen wir die komplette Chargenhistorie aus NAV übernehmen?
Nein. Sie müssen sie aufbewahren und auskunftsfähig halten, das ist nicht dasselbe wie produktiv vorhalten. Historie zu Produkten, die noch im Markt sind, gehört ins System. Historie innerhalb der Aufbewahrungsfrist zu abgekündigten Produkten kann kontrolliert archiviert werden, sofern der Zugriffsweg dokumentiert und erprobt ist.
Was passiert mit gesperrten Chargen beim Übergang?
Beim replizierenden Standardpfad kommen die Kennzeichen mit. Bei einer Reimplementierung oder einer manuellen Übernahme passiert ohne explizite Abbildungsregel das Falsche: Die Chargen kommen ohne Sperrkennzeichen an und sind sofort verwendbar. Sperrzustände brauchen eine eigene Abbildungsregel je Sperrgrund und eine vollständige Gegenprüfung nach der Migration, keine Stichprobe.
Was wird aus unseren C/AL-Anpassungen?
Sie müssen als AL-Extensions vorliegen, sonst lassen sich die Daten der betroffenen Tabellen nicht übernehmen. Nutzen Sie den Zwang zur Portierung als Prüfung: Jede Anpassung, für die sich keine Prozessanforderung benennen lässt, wird gestrichen statt übersetzt. Anders liegt der Fall nur beim Reimplementierungspfad, der Anpassungen und die volle Buchungshistorie bewusst zurückließe.
Wie weisen wir nach, dass die Daten korrekt angekommen sind?
Über einen vorab definierten Prüfplan mit Akzeptanzkriterien, einen Probelauf in der Sandbox und einen Migrationsbericht mit Mengenabgleich, geprüften Rückverfolgungsketten und dokumentierten Abweichungen. Der Nachweis entsteht vor dem Cutover, nicht danach.
Wenn Sie auf NAV 2016 oder älter produzieren, ist die Frist bereits verstrichen. Bei NAV 2017 bleibt bis Januar 2027 noch Zeit für ein geordnetes Projekt, nicht für ein zweites. Der sinnvolle Einstieg ist keine Systemauswahl, sondern eine Inventur: Welche Datenbestände sind regulatorisch gebunden, welche Prozesse hängen an Anpassungen, und welcher der drei Wege gilt je Bestand? Aus dieser Liste ergibt sich der Aufwand belastbar.
Nächster Schritt: Digitalisierungs-Standortbestimmung oder Migrationspfad für Dynamics NAV.
Weiterlesen: Business Central oder Finance & Supply Chain?
Alle Fachbeiträge im Überblick
Verordnung (EU) 2017/745 über Medizinprodukte (MDR), konsolidierte Fassung, EUR-Lex
Verordnung (EU) 2017/746 über In-vitro-Diagnostika (IVDR), EUR-Lex
MDCG 2021-19: Guidance note integration of the UDI within an organisation’s quality management system
ISO 13485:2016, Medical devices, Quality management systems, Requirements for regulatory purposes
Microsoft Learn: Migrate Dynamics NAV to Business Central online
Microsoft Learn: Prepare and plan for cloud migration
Microsoft Learn: Clean data before cloud migration
Microsoft Learn: Trace item-tracked items
Microsoft Learn: Block items or item variants
Microsoft Learn: Clean up data with retention policies
Dieser Beitrag gibt den Rechts- und Produktstand vom 21. August 2026 wieder. Er ersetzt keine Rechtsberatung und keine Prüfung des Einzelfalls. Maßgeblich ist der Wortlaut der jeweils geltenden Fassung der zitierten Rechtsakte und Normen.
AENUMA Redaktion · Stand: 21. August 2026 · Wie diese Beiträge entstehen
