AX 2009 und AX 2012 weiterbetreiben
Was das wirklich bedeutet — und wann es Zeit ist zu handeln
Der aktuelle Stand
Was Microsoft noch liefert — und was nicht
Klar gesagt: Der Extended Support für AX 2009 SP1, AX 2012 und AX 2012 R2 endete April 2022. Für AX 2012 R3 lief er im Januar 2023 aus. Seither gibt es von Microsoft keine Security-Patches, keine Regulatory Updates, keine Hotfixes mehr — für keine einzige AX-Version.
Was das konkret bedeutet:
Sicherheit: Das System erhält keine Sicherheitsupdates mehr. Jede neu entdeckte Schwachstelle in der Plattform bleibt dauerhaft offen. Wer AX 2009 oder 2012 on-premises betreibt, trägt dieses Risiko selbst — ohne Netz.
Compliance: Regulatory Updates für AX 2009 SP1, AX 2012 und R2 hat Microsoft nur für gesetzliche Änderungen bis Oktober 2018 geliefert — danach nichts mehr. Österreichische und deutsche Gesetzesänderungen seither — neue Meldepflichten, UVA-Anpassungen, geänderte Buchungsvorschriften — müssen durch den Partner oder intern nachgepflegt werden. Das kostet jedes Jahr Geld, das in keiner ursprünglichen Kalkulation stand.
Integrationsfähigkeit: Neuere Microsoft-Lösungen wie Microsoft 365, Azure-Dienste oder Power BI lassen sich mit AX 2009 und 2012 oft nicht mehr nativ integrieren. Wer Teams, moderne BI-Dashboards oder externe APIs produktiv nutzen will, baut auf einer Plattform, die dafür nicht mehr gemacht wurde.
Das stille Problem
Die Infrastruktur darunter bricht weg
Hier liegt ein Risiko, das in vielen Unternehmen noch zu wenig Aufmerksamkeit bekommt. AX 2009 und AX 2012 laufen auf Windows Server- und SQL Server-Versionen, die selbst längst aus dem Support gefallen sind oder bald fallen. Wer seinen AX-Server aus Sicherheitsgründen auf einen neueren Betriebssystem-Stand hebt, riskiert Kompatibilitätsprobleme mit der AX-Installation selbst. Wer es nicht tut, betreibt eine unsichere Infrastruktur auf veralteter Basis.
Das Ergebnis in der Praxis: Systeme werden zunehmend instabil. Dienste starten nicht mehr sauber. Regelmäßige Neustarts werden zur Routine, um Performanceprobleme zu beherrschen. Kleine Abstürze häufen sich. Niemand greift aktiv ein, weil Eingriffe riskant sind — und Microsoft keine Patches mehr liefert, die man einspielen könnte.
Was als "läuft stabil" gilt, ist oft in Wahrheit ein System im dauerhaften Wartungsmodus, das mit zunehmendem Aufwand am Laufen gehalten wird. Diese Kosten — Zeit der IT, eingekaufte Partnerleistung, verlorene Produktivität durch Ausfälle — erscheinen nirgends auf einer Migrationskosten-Rechnung. Sie fallen einfach an, still und regelmäßig.
"Aber bei uns läuft es seit Jahren stabil..."
Das hören wir oft — und es stimmt meistens sogar, zumindest auf den ersten Blick. Stabilität ist aber kein Argument gegen den Wechsel, sondern ein Argument für einen geplanten Wechsel. Denn die tieferen Risiken sind unsichtbar:
Wissensträger werden rar. X++-Entwickler, die AX 2009 noch wirklich kennen, sind 2026 schwer zu finden. Wenn ein kritischer Bug auftaucht oder der langjährige AX-Betreuer das Unternehmen verlässt, wird es teuer und langsam.
Individualentwicklungen wachsen zur Last. In AX-Projekten wurden oft umfangreiche Eigenentwicklungen über Overlayering umgesetzt — direkte Eingriffe in Microsoft-Standardobjekte. Microsoft hat längst auf ein Extensions-Modell umgestellt, bei dem eigener Code nicht mehr in Standard-Objekte eingreift und dadurch keine Merge-Aufwände bei Updates erzeugt. In AX 2009/2012 existiert dieses Modell noch nicht. Jede Anpassung von damals ist technische Schuld, die bei einer Migration aufgearbeitet werden muss.
Der Punkt, den kaum jemand offen anspricht
Ihre Prozesse sind auch gealtert
AX 2009 wurde zwischen 2008 und 2012 eingeführt. Das ist 14 bis 18 Jahre her.
Die meisten Unternehmen, die noch auf AX laufen, haben in dieser Zeit ihr Geschäft verändert: neue Produkte, neue Märkte, neue Vertriebskanäle, veränderte Lieferketten, gewachsene Komplexität. Das System wurde dabei mitgeschleppt — mit Workarounds, Nebentools, Excel-Listen und manuellen Übergaben, die sich über die Jahre eingeschlichen haben.
Eine Migration ist deshalb keine reine IT-Übung. Sie ist der erste ehrliche Blick auf Ihre Prozesse seit vielen Jahren. Und dieser Blick lohnt sich — nicht trotz des Aufwands, sondern gerade wegen ihm.
Was sich in 15 Jahren typischerweise verändert hat:
Geschäftsprozesse, die damals als Standard galten, sind heute oft nicht mehr zeitgemäß. Einkaufsabläufe, die manuell funktioniert haben, weil man drei Lieferanten hatte, stoßen bei zwanzig Lieferanten an Grenzen. Lagerlogik, die für ein Zentrallager aufgebaut wurde, passt nicht mehr zu einer Multi-Standort-Struktur. Reporting, das damals über SSRS-Berichte lief, könnte heute durch Power BI in Echtzeit abgebildet werden — wenn die Datenstruktur stimmt.
Das bedeutet: Wer eine Migration startet, ohne vorher die Prozesse neu zu denken, migriert den Ballast von 2010 in ein System von 2026. Das ist möglich — aber es verschenkt den größten Teil des Potenzials.
Unsere Empfehlung ist deshalb: Prozessanalyse vor Systemauswahl. Was brauche ich wirklich? Was hat sich verändert? Welche Prozesse sollten vereinfacht werden, bevor sie digitalisiert werden? Diese Antworten bestimmen, was das neue System leisten muss — nicht umgekehrt.
Der Upgrade-Pfad
Was Sie technisch erwartet
Für AX 2009-Betreiber gibt es eine unbequeme Wahrheit: Von AX 2009 gibt es keinen direkten Weg zu D365 F&O. Der einzige unterstützte Migrationspfad führt zuerst auf AX 2012 R3, und von dort erst weiter zu D365 Finance & Supply Chain Management — ein Zwei-Stufen-Upgrade.
Von AX 2012 R2 oder R3 ist ein direkter Wechsel zu D365 F&O möglich — der Prozess umfasst Datenextraktion, Code-Konvertierung und Deployment einer neuen D365-Umgebung.
Was in beiden Fällen unterschätzt wird:
Datenmigration ist keine Copy-Paste-Übung. Jahrzehnte gewachsene Datenstrukturen, nicht mehr gebrauchte Entitäten, inaktive Artikel und historische Buchungen müssen bewertet und bereinigt werden — bevor sie migriert werden, nicht danach. Schlechte Datenqualität, die im AX-Betrieb nie aufgefallen ist, weil man sich damit arrangiert hat, wird in einer Migration schlagartig sichtbar.
Customizations müssen neu bewertet werden. Nicht alles, was in AX individuell entwickelt wurde, sollte 1:1 nach D365 übertragen werden. In vielen Fällen deckt der D365-Standard die Anforderung heute bereits ab — oft besser als die alte Eigenentwicklung. Die Frage lautet nicht "Wie bilde ich das in D365 genauso ab?", sondern "Wie löse ich das Geschäftsproblem heute am besten?"
Integrationen sind häufig das teuerste Element. Wer externe Systeme — Webshop, WMS, EDI, Zoll, Drittlager — an AX angebunden hat, muss diese Schnittstellen neu aufbauen. Bestehende AX-Schnittstellen lassen sich in der Regel nicht direkt wiederverwenden.
Projektzeitraum realistisch einplanen. Für eine Migration von AX nach D365 sollte man 6 bis 12 Monate Projektlaufzeit einkalkulieren — je nach Umfang der Eigenentwicklungen, Anzahl der Schnittstellen und Datenqualität auch mehr.
Signale erkennen
Wann ist der richtige Zeitpunkt?
Es gibt keinen perfekten Moment — aber es gibt klare Signale, dass es Zeit ist zu handeln:
- Regulatorische Anpassungen werden aufwändig und teuer manuell nachgepflegt
- Server-Neustarts und kleine Systemausfälle häufen sich
- Die IT-Infrastruktur darunter muss erneuert werden und zieht das AX-System in die Diskussion
- Externe Integrationen mit modernen Systemen funktionieren nur noch mit Workarounds
- Schlüsselpersonen, die das AX-System wirklich kennen, könnten das Unternehmen verlassen
- Neue Geschäftsprozesse lassen sich in AX nicht mehr sauber abbilden
- Eine Fusion, Übernahme oder Internationalisierung steht bevor
Wer noch keines dieser Signale sieht: Trotzdem ist jetzt ein guter Zeitpunkt für eine Standortanalyse. Wie viele Eigenentwicklungen gibt es? Wie viele Schnittstellen? Wie ist der Datenqualitätszustand? Und vor allem: Welche Prozesse haben sich seit der AX-Einführung so weit verändert, dass sie neu gedacht werden sollten? Diese Antworten brauchen Sie für jedes Migrationsprojekt — und je früher Sie sie haben, desto ruhiger können Sie planen.
Unser Ansatz
Was insideAx empfiehlt
Bevor ein Migrationsprojekt startet, empfehlen wir einen strukturierten Fit-Check: Prozessaufnahme, Analyse der bestehenden Eigenentwicklungen und Schnittstellen, Datenbewertung — damit das Projekt auf einem soliden Fundament steht und keine bösen Überraschungen im Projektverlauf entstehen.
Wir haben mehr als 200 ERP-Projekte im Microsoft Dynamics Umfeld umgesetzt — viele davon Migrationen aus AX 2009 und AX 2012. Wenn Sie wissen wollen, was ein Wechsel in Ihrem konkreten Fall bedeutet: Sprechen Sie mit uns.