Systemwechsel

Dynamics AX ablösen: Migration oder Neuimplementierung, die ehrliche Entscheidung

Ihr AX läuft. Seit über drei Jahren gibt es dafür keinen Herstellersupport mehr. Regulatorische Updates und funktionale Hotfixes sind sogar schon seit 2018 entfallen, bei AX 2012 R3 seit 2021. Im Tagesgeschäft fällt das selten auf, im Audit und in der Lieferantenbewertung fällt es sofort auf. Die offene Frage ist deshalb nicht mehr, ob abgelöst wird, sondern ob Sie den Bestand mitnehmen oder neu aufsetzen.

Ablösung von Dynamics NAV und AX bei AENUMA · Supportende der Dynamics-Altversionen

Der Ausgangspunkt: kein Support, keine regulatorischen Updates

Die Lebenszyklusdaten sind eindeutig.

Seitdem gibt es keine unterstützte AX-Version mehr. Entscheidend für regulierte Hersteller ist ein Detail der Extended-Phase: Bereits dort wurden für die AX-Produkte weder nicht sicherheitsrelevante Hotfixes noch regulatorische Updates bereitgestellt. Microsoft hat ausdrücklich erklärt, solche Hotfixes für diese Produkte nicht mit wirtschaftlich vertretbarem Aufwand liefern zu können. Wer also seit 2018 und bei AX 2012 R3 seit 2021 auf eine steuerliche oder regulatorische Anpassung im Standard gewartet hat, hat auf etwas gewartet, das nicht kommt. Microsoft verweist als Zielplattform auf die finance and operations apps, also Dynamics 365 Finance, Supply Chain Management, Commerce und Project Operations. Der Upgrade wird aus AX 2012 R2 und AX 2012 R3 unterstützt; aus AX 2012 RTM ist er derzeit nicht möglich.

Die Entscheidung ist keine technische Frage

Upgrade oder Reimplementation wird in vielen Häusern als Architekturfrage diskutiert. Das ist der falsche Ort. Die belastbare Frage lautet: Wie viel von dem, was Ihr AX heute tut, ist ein bewusst gestalteter Geschäftsprozess, und wie viel ist historisch gewachsenes Customizing, das niemand mehr begründen kann?

Der Test dafür ist banal und trotzdem selten bestanden. Nehmen Sie die zwanzig größten Anpassungen Ihres Systems und lassen Sie zu jeder zwei Sätze schreiben: Welchen fachlichen Zweck erfüllt sie, und welche Entscheidung hat zu ihr geführt? Wenn Ihr Team das für die Mehrheit dieser Anpassungen kann, haben Sie ein gestaltetes System und einen realistischen Upgrade-Kandidaten. Wenn die Antwort überwiegend lautet, das sei damals so gemacht worden, dann verwalten Sie kein Prozessmodell, sondern eine Ablagerung. Diese Ablagerung mitzunehmen kostet in einem regulierten Betrieb erfahrungsgemäß mehr, als sie neu zu bauen.

Sechs Kriterien, die die Richtung bestimmen

Die Entscheidung lässt sich an sechs Kriterien festmachen. Keines davon entscheidet allein, als Faustregel entscheiden zwei oder drei klare Befunde auf derselben Seite die Frage.

Warum Lift and Shift beim regulierten Hersteller häufig teurer ist

Beim Upgrade wird der Bestand mitgenommen: Code, Konfiguration, Daten. In einem nicht regulierten Betrieb ist das oft der günstigere Weg. Bei einem Medizinprodukte- oder IVD-Hersteller kippt die Rechnung, und zwar aus einem Grund: Was Sie mitnehmen, müssen Sie auch nachweisen.

Jede übernommene Anpassung, die eine qualitätsrelevante Funktion berührt, gehört in den Validierungsumfang. Der Nachweis beginnt beim Intended Use, also bei der Frage, wofür die Funktion bestimmt ist. Genau diese Frage lässt sich bei gewachsenem Customizing häufig nicht mehr beantworten. Dann passiert im Projekt regelmäßig Folgendes: Das Team rekonstruiert den Zweck aus dem Code, schreibt eine Spezifikation nachträglich, leitet daraus Testfälle ab und validiert eine Funktion, die im Zielprozess niemand mehr braucht. In unseren Projekten ist der Aufwand für diese Rekonstruktion der größere Kostenblock, nicht die technische Migration.

Microsoft selbst formuliert die Erwartung an das Upgrade-Werkzeug nüchtern: Tools und Code für das Upgrade seien als Rahmen zu verstehen, nicht als fertige Lösung, und es sei nicht anzunehmen, dass der Prozess ohne Bereinigung, Tuning und Anpassung durchläuft. Hinzu kommt eine harte Grenze: AX-2012-Installationen, die bestimmte abgekündigte Funktionen nutzen, etwa virtuelle Unternehmen oder Datenpartitionen, lassen sich derzeit nicht upgraden. Ob der eigene Stand betroffen ist, klärt der Upgrade-Analyzer. Das ist eine Vorabprüfung, keine Detailfrage der Umsetzung.

Der Gegentest ist einfach: Schätzen Sie den Validierungsaufwand einmal für den mitgenommenen Bestand und einmal für einen Zielprozess auf Standard. Wenn die erste Zahl größer ist, haben Sie Ihre Antwort. Wie wir den Umfang und die Nachweisführung aufsetzen, beschreibt die Validierung von Dynamics 365.

Der regulatorische Winkel: das Altsystem als offener Punkt

Aus MDR, IVDR und ISO 13485:2016 folgt kein ausdrückliches Verbot, ein Altsystem ohne Herstellersupport zu betreiben. Es ist ein Punkt, der begründet werden muss, und zwar an zwei Stellen.

• Softwarevalidierung. ISO 13485:2016 verlangt in Abschnitt 4.1.6 die Validierung von Software, die im Qualitätsmanagementsystem eingesetzt wird, vor der Erstnutzung und nach Änderungen, mit einem Vorgehen, das dem Risiko angemessen ist. Ein Produkt, für das keine Hotfixes und keine regulatorischen Updates mehr erscheinen, verändert dieses Risiko. Das gehört bewertet und dokumentiert.
• Lieferantenbewertung. Die MDR verlangt in Artikel 10 Absatz 9 ein Qualitätsmanagementsystem, das unter anderem das Ressourcenmanagement einschließlich der Auswahl und Kontrolle von Zulieferern und Unterauftragnehmern abdeckt. Artikel 10 Absatz 8 der IVDR stellt dieselbe Anforderung. In der Lieferantenbewertung führt der Supportwegfall damit zu der Frage, wie er kompensiert wird. Wir empfehlen, diese Antwort dokumentiert vorzuhalten.

Für einen Auditor ist „das System läuft seit Jahren stabil“ keine Begründung, weil Stabilität keine Aussage über Wirksamkeit unter Änderung trifft. Eine dokumentierte Risikobewertung mit benannten kompensierenden Maßnahmen und einem terminierten Ablösepfad ist dagegen eine tragfähige Antwort. Diese Bewertung sollten Sie unabhängig davon erstellen, welchen Weg Sie wählen, denn sie gilt für die gesamte Übergangszeit.

Wann der Upgrade-Pfad die richtige Entscheidung ist

Es gibt Konstellationen, in denen das Upgrade sachlich überlegen ist. Sie sind seltener, als Projektpläne suggerieren, aber sie existieren.

1. Das System ist nah am Standard, die Erweiterungen sind spezifiziert, und die Validierungsakte ist gepflegt. Dann verlieren Sie beim Neuaufbau bezahlte Arbeit.
2. Es besteht ein echter Zwang zur vollständigen Transaktionshistorie im führenden System, etwa aus einer Konzernvorgabe. Der Upgrade-Prozess bringt die Datenbank mitsamt Historie mit.
3. Eine harte externe Frist lässt keine Prozessarbeit zu, und die Fachbereiche sind operativ gebunden. Ein Neuaufbau ohne Entscheidungsfähigkeit der Fachbereiche endet in einer Kopie des Alten, nur teurer.
4. Die Prozesse wurden bereits vor Kurzem überarbeitet und das System bildet diese Überarbeitung ab. Dann ist die inhaltliche Arbeit erledigt und es bleibt eine Plattformfrage.

Trifft keiner dieser Punkte zu, ist der Neuaufbau in der Regel der kürzere Weg zum validierten Zielzustand. Welche Fragen vor dieser Weichenstellung geklärt sein müssen, behandelt der Beitrag dazu, wie eine ERP-Auswahl im regulierten Umfeld aufgesetzt wird.

Was in beiden Varianten gleich bleibt

Zwei Themen entscheiden über Termin und Budget, unabhängig vom gewählten Weg.

Die Datenfrage. Welche Daten müssen in das neue System, welche gehören in ein Archiv, und für welche gilt eine gesetzliche oder normative Aufbewahrungspflicht? Chargen, Seriennummern, UDI-Bezüge, Lieferantenqualifikationen und Rückverfolgbarkeitsketten sind keine Frage der Stammdatenpflege, sondern Nachweisdaten. Die Migration dieser Daten braucht eigene Akzeptanzkriterien und einen eigenen Nachweis, wie er unter Datenmigration und ihre Nachweisführung beschrieben ist.

Der Validierungsnachweis. Beide Wege enden in einem validierten System. Der Unterschied liegt nur im Umfang und darin, wie leicht sich der Umfang begründen lässt. Bei einem Zielprozess auf Standard begründen Sie ihn aus dem Prozessmodell. Beim Upgrade begründen Sie ihn aus dem Bestand, den Sie zuerst verstehen müssen. Wie sich Prozessdesign, Konfiguration und Nachweis in Phasen verzahnen, zeigt unser Vorgehen im Projekt.

FAQ zur Ablösung von Dynamics AX

Wie lange dauert eine Ablösung von Dynamics AX realistisch?
Der belastbare Teil der Antwort hängt am Scope, nicht am Werkzeug. Planen Sie die Vorphase ernsthaft ein: Bestandsaufnahme der Anpassungen, Datenanalyse und Zielprozessentscheidung passieren vor dem Projektstart, nicht darin. Wer diese Phase überspringt, verlagert sie in die Realisierung, wo sie teurer ist.

Können wir Dynamics AX einfach weiterbetreiben?
Technisch ja, es gibt keine Abschaltung. Sie übernehmen damit aber die vollständige Verantwortung für Sicherheit, regulatorische Anpassungen und Fehlerbehebung, und Sie müssen diesen Zustand in Risikobewertung und Lieferantenbewertung begründen. Das ist eine bewusste Entscheidung, keine Nichtentscheidung.

Nehmen wir die Transaktionshistorie mit oder archivieren wir?
Die Aufbewahrungspflicht gilt für die Daten, nicht für ein bestimmtes System. Die steuer- und handelsrechtlichen Anforderungen an Lesbarmachung und maschinelle Auswertbarkeit sind dabei mit zu betrachten. Für Nachweisdaten mit Produktbezug ist der Zugriff aus dem führenden System oft praktischer, für reine Finanzhistorie kann ein revisionssicheres Archiv genügen. Entscheiden Sie das je Datenklasse, nicht pauschal.

Ist Dynamics 365 Finance und Supply Chain Management automatisch das Ziel?
Nicht automatisch. Für einen Teil der Hersteller mit 50 bis 250 Mitarbeitenden ist Business Central der passendere Zuschnitt, für andere Finance und Supply Chain Management. Die Entscheidung folgt aus Fertigungstiefe, Standortstruktur und Prozesskomplexität, nicht aus der Herkunft des Altsystems.

Der richtige nächste Schritt

Bevor Sie über Plattformen sprechen, brauchen Sie zwei Ergebnisse: eine Liste Ihrer Anpassungen mit benanntem Zweck und eine Aussage zur Qualität Ihrer Nachweisdaten. Beides ist je nach Systemumfang typischerweise in wenigen Wochen erarbeitbar und entscheidet die Frage Upgrade oder Reimplementation belastbarer als jede Architekturdiskussion.

Nächster Schritt: Digitalisierungs-Standortbestimmung oder Zielbild und Migrationspfad.

Weiterlesen: Business Central oder Finance & Supply Chain?
Alle Fachbeiträge im Überblick

Quellen

Microsoft Learn: End of mainstream support for Microsoft Dynamics AX 2009, Dynamics AX 2012, Dynamics AX 2012 R2, and Dynamics AX 2012 R3
Microsoft Lifecycle: FAQ zu Dynamics
Microsoft Learn: Upgrade from AX 2012 to finance and operations
Microsoft Learn: Removed or deprecated features in previous releases
Verordnung (EU) 2017/745 über Medizinprodukte (MDR)
Verordnung (EU) 2017/746 über In-vitro-Diagnostika (IVDR)
ISO 13485:2016, Medical devices, Quality management systems, Requirements for regulatory purposes

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