Ratgeber · KI
Dynamics AX ablösen: Upgrade oder Neuaufbau, die ehrliche Entscheidung
Ihr AX läuft. Seit fast vier Jahren gibt es dafür keinen Herstellersupport mehr. Funktionale Hotfixes und regulatorische Updates sind sogar schon länger entfallen, bei AX 2012 R3 seit 2021. Im Tagesgeschäft fällt das selten auf, bei Prüfungen und gesetzlichen Änderungen sofort. Die offene Frage ist deshalb nicht mehr, ob abgelöst wird, sondern ob Sie den Bestand mitnehmen oder neu aufsetzen. Dieser Ratgeber gibt sechs Kriterien für die Entscheidung und zeigt, wo KI die Vorarbeit verkürzt.
Der Ausgangspunkt: kein Support, keine Updates
Dynamics AX 2009 SP1, AX 2012, AX 2012 R2
Ende Mainstream-Support: 09.10.2018
Ende Extended-Support: 12.04.2022
Dynamics AX 2012 R3
Ende Mainstream-Support: 12.10.2021
Ende Extended-Support: 10.01.2023
Seitdem gibt es keine unterstützte AX-Version mehr. Schon in der Extended-Phase hat Microsoft für AX weder funktionale Hotfixes noch regulatorische Updates geliefert. Wer auf eine steuerliche Anpassung im Standard gewartet hat, hat auf etwas gewartet, das nicht kommt. Als Ziel nennt Microsoft die Finance-and-Operations-Apps, also Dynamics 365 Finance, Supply Chain Management, Commerce und Project Operations. Das Upgrade wird aus AX 2012 R2 und AX 2012 R3 unterstützt, aus AX 2012 RTM derzeit nicht.
Die Entscheidung ist keine technische Frage
Upgrade oder Neuaufbau wird oft 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 gewachsenes Customizing, das niemand mehr begründen kann?
Der Test dafür ist einfach 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? Kann Ihr Team das für die Mehrheit, haben Sie ein gestaltetes System und einen realistischen Upgrade-Kandidaten. Lautet die Antwort überwiegend „das wurde damals so gemacht“, nehmen Sie beim Upgrade Altlasten mit, die später jede Änderung verteuern.
Sechs Kriterien, die die Richtung bestimmen
Keines entscheidet allein. Als Faustregel entscheiden zwei oder drei klare Befunde auf derselben Seite die Frage.
Anpassungen
Spricht für Upgrade: Wenige, dokumentierte Erweiterungen mit benennbarem Zweck
Spricht für Neuaufbau: Breites Customizing ohne Beschreibung, Eingriffe im Standardcode
Datenqualität
Spricht für Upgrade: Stammdaten gepflegt, Dubletten bereinigt, Historie konsistent
Spricht für Neuaufbau: Uneindeutige Artikel- und Partnerstämme, Historie nur mit Zusatzwissen lesbar
Prozessreife
Spricht für Upgrade: Prozesse sind beschrieben und werden gelebt
Spricht für Neuaufbau: Prozesse folgen dem System, Workarounds in Excel und auf Papier
Fachkapazität
Spricht für Upgrade: Kein Freiraum für Prozessarbeit, Kernteam gebunden
Spricht für Neuaufbau: Fachbereiche können Zielprozesse entscheiden und abnehmen
Dokumentation
Spricht für Upgrade: Änderungen nachvollziehbar, Testfälle vorhanden
Spricht für Neuaufbau: Lückenhafte Nachweise, unklarer Zweck einzelner Funktionen
Zeitdruck
Spricht für Upgrade: Harte externe Frist, etwa Rechenzentrumsvertrag oder Konzernvorgabe
Spricht für Neuaufbau: Planbarer Horizont von zwölf Monaten und mehr
Warum Lift and Shift oft teurer ist als gedacht
Beim Upgrade wird der Bestand mitgenommen: Code, Konfiguration, Daten. Was Sie mitnehmen, müssen Sie aber auch testen und künftig pflegen. Jede übernommene Anpassung landet im Testumfang, und ihr Zweck muss dafür bekannt sein. Genau das lässt sich bei gewachsenem Customizing häufig nicht mehr beantworten. Dann rekonstruiert das Team den Zweck aus dem Code, schreibt Anforderungen nachträglich und testet eine Funktion, die im Zielprozess niemand mehr braucht.
Microsoft formuliert die Erwartung an das Upgrade-Werkzeug nüchtern: Werkzeuge und Code seien als Rahmen zu verstehen, nicht als fertige Lösung, ohne Bereinigung und Anpassung laufe der Prozess nicht durch. Dazu kommt eine harte Grenze: AX-2012-Installationen, die bestimmte abgekündigte Funktionen nutzen, etwa virtuelle Unternehmen oder Datenpartitionen, lassen sich derzeit nicht upgraden. Ob Ihr Stand betroffen ist, klärt der Upgrade-Analyzer vorab.
Der Gegentest: Schätzen Sie den Aufwand für Test und Pflege einmal für den mitgenommenen Bestand und einmal für einen Zielprozess nahe am Standard. Ist die erste Zahl größer, haben Sie Ihre Antwort.
Das Altsystem bis zum Wechsel absichern
Ein AX ohne Support zu betreiben ist nicht verboten. Es ist ein Risiko, das begründet werden sollte, gegenüber IT-Sicherheit, Wirtschaftsprüfer und Geschäftsführung. „Das System läuft seit Jahren stabil“ ist keine Begründung, weil Stabilität nichts über das Verhalten bei Änderungen aussagt. Eine dokumentierte Risikobewertung mit Schutzmaßnahmen und einem terminierten Ablösepfad ist dagegen eine tragfähige Antwort. Sie gilt unabhängig davon, welchen Weg Sie wählen.
Wann das Upgrade die richtige Entscheidung ist
• Das System ist nah am Standard, die Erweiterungen sind beschrieben und getestet. Beim Neuaufbau würden Sie bezahlte Arbeit verlieren.
• Die vollständige Transaktionshistorie muss im führenden System bleiben, etwa wegen einer Konzernvorgabe.
• Eine harte Frist lässt keine Prozessarbeit zu, und die Fachbereiche sind gebunden.
• Die Prozesse wurden vor Kurzem überarbeitet und das System bildet das ab.
Trifft keiner dieser Punkte zu, ist der Neuaufbau in der Regel der kürzere Weg zu einem sauberen Zielsystem.
Was in beiden Varianten gleich bleibt
Die Datenfrage. Welche Daten müssen ins neue System, welche in ein Archiv, und für welche gilt eine Aufbewahrungspflicht? Die steuer- und handelsrechtlichen Anforderungen an Lesbarkeit und Auswertbarkeit gelten für die Daten, nicht für ein bestimmtes System. Entscheiden Sie das je Datenklasse, nicht pauschal.
Der Nachweis. Beide Wege enden in einem getesteten System. Bei einem Zielprozess nahe am Standard begründen Sie den Testumfang aus dem Prozessmodell, beim Upgrade aus dem Bestand, den Sie zuerst verstehen müssen.
Wo KI-Agenten hier helfen
Der Zwanzig-Anpassungen-Test ist genau die Art Arbeit, die KI gut vorbereitet.
• Zweck je Anpassung vorschlagen: Ein Agent liest X++-Code, Objektbeschreibungen und vorhandene Dokumentation und schreibt zu jeder Anpassung einen Vorschlag für die zwei Sätze. Ihr Team prüft und korrigiert, statt bei null anzufangen.
• Stammdaten bereinigen: Dubletten, unvollständige Datensätze und widersprüchliche Einträge in Artikel-, Kunden- und Lieferantenstämmen werden automatisch gefunden und zur Entscheidung vorgelegt.
• Datenabgleich nach der Migration: Ein Ablauf vergleicht Mengen und Summen je Tabelle zwischen Alt- und Zielsystem und erstellt den Abgleichbericht.
So wird die Vorphase, die über Termin und Budget entscheidet, kürzer und belastbarer.
Wo aenuma hilft
aenuma begleitet AX-Ablösungen von der Bestandsaufnahme über das Lösungsdesign bis zur Steuerung des Implementierungspartners und setzt KI dort ein, wo sie die Vorarbeit verkürzt. Mehr dazu auf der Seite Leistungen. Verwandte Ratgeber: Business Central oder Finance & Supply Chain? und Release Wave 2 2026.
Häufige Fragen
Wie lange dauert eine Ablösung von Dynamics AX?
Das hängt am Umfang, nicht am Werkzeug. Planen Sie die Vorphase ernsthaft ein: Bestandsaufnahme der Anpassungen, Datenanalyse und Entscheidung über die Zielprozesse passieren vor dem Projektstart, nicht darin. Wer diese Phase überspringt, verlagert sie in die Umsetzung, wo sie teurer ist.
Können wir Dynamics AX einfach weiterbetreiben?
Technisch ja, es gibt keine Abschaltung. Sie übernehmen damit aber die volle Verantwortung für Sicherheit, gesetzliche Anpassungen und Fehlerbehebung und sollten diesen Zustand dokumentiert begründen.
Nehmen wir die Transaktionshistorie mit oder archivieren wir?
Für operative Daten 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.
Ist Finance und Supply Chain Management automatisch das Ziel?
Nein. Für einen Teil der Unternehmen ist Business Central der passendere Zuschnitt. Die Entscheidung folgt aus Fertigungstiefe, Standortstruktur und Prozesskomplexität, nicht aus der Herkunft des Altsystems.
Quellen
End of mainstream support for Microsoft Dynamics AX 2009, AX 2012, AX 2012 R2 and AX 2012 R3 (Microsoft Learn)
Lifecycle FAQ, Dynamics (Microsoft Learn)
Upgrade from AX 2012 to finance and operations (Microsoft Learn)
Removed or deprecated features in previous releases (Microsoft Learn)
Von Joshua Schütt, Gründer von aenuma. Stand: November 2026.
Steht Ihre AX-Ablösung an?
Erzählen Sie uns, welchen AX-Stand Sie betreiben und wie viel Customizing drinsteckt. Wir sagen Ihnen, welche Kriterien bei Ihnen den Ausschlag geben und wo KI die Bestandsaufnahme verkürzt.
Anwendungsfall besprechen