Migrer de Dynamics AX vers Dynamics 365 : Le Guide

Migration Dynamics AX vers Dynamics 365 : ce qu’il faut décider

Si votre entreprise tourne encore sur Microsoft Dynamics AX, la question n’est plus de savoir s’il faut migrer vers Dynamics 365, mais quand et comment. AX 2012 R3, la dernière version, n’est plus supportée par Microsoft depuis janvier 2023, et les versions antérieures le sont depuis plus longtemps encore.

Concrètement, cela signifie : plus de mises à jour de sécurité, un risque de conformité qui grandit et un système qui s’éloigne un peu plus chaque mois des besoins de l’entreprise.

Cet article explique pourquoi la migration devient incontournable, vers quoi migrer et surtout comment trancher le choix structurant entre mise à niveau et réimplémentation sans répéter les erreurs classiques.

Dynamics AX en fin de support : pourquoi c’est urgent

Le premier moteur de la décision n’est pas l’envie de nouveauté, c’est le risque. Microsoft a mis fin au support de Dynamics AX 2012 R3 le 10 janvier 2023 et les versions plus anciennes (AX 2009, AX 2012 RTM et R2) ont quitté le support encore avant.

Un ERP sans support, c’est d’abord un problème de sécurité : aucune mise à jour ne vient plus corriger les vulnérabilités, ce qui expose l’entreprise et complique les audits, les certifications et parfois la couverture d’assurance. C’est ensuite un problème d’obsolescence : AX a été retiré du catalogue, il n’évolue plus et l’écart se creuse avec les attentes métier, les obligations réglementaires nouvelles et les standards techniques actuels.

Tant que « tout fonctionne » l’inertie domine, mais le coût d’un système figé est silencieux et croissant : contournements, dépendance à quelques experts vieillissants, intégrations fragiles, impossibilité d’absorber une nouvelle réglementation. La fin de support ne déclenche pas une panne du jour au lendemain, elle transforme chaque mois qui passe en dette supplémentaire.

Migrer vers quoi ? Dynamics 365 Finance & Operations

Le successeur de Dynamics AX est Microsoft Dynamics 365 Finance & Operations, c’est-à-dire les applications Dynamics 365 Finance et Dynamics 365 Supply Chain Management. C’est la même filiation fonctionnelle qu’AX, portée sur une plateforme cloud moderne.

Le changement est réel. On passe d’un système installé sur site, figé sur une version, à un ERP cloud en mise à jour continue (le modèle One Version), avec une interface modernisée, des capacités multi-sociétés, multi-pays et multilingues, et l’accès à tout l’écosystème Microsoft : Power Platform, Power BI, et les fonctionnalités d’IA et de Copilot.

Une précision utile pour les grandes entreprises : le successeur d’AX est bien Finance & Operations, pas Business Central. Ce dernier est l’ERP Microsoft destiné aux PME ; il ne couvre pas le même niveau de complexité. Une organisation qui exploitait AX pour des processus avancés se dirige vers Finance & Operations.

Au-delà du risque : ce que la migration apporte vraiment

Migrer n’est pas qu’une mise en conformité : c’est un saut de capacités. Le passage au cloud et au modèle One Version met fin aux grandes montées de version douloureuses, les mises à jour deviennent continues et maîtrisées et le système ne se retrouve plus jamais coincé sur une édition obsolète.

S’ouvre aussi tout l’écosystème Microsoft. Power BI et l’analytique incorporée donnent une vision en temps réel, Power Platform permet d’automatiser et d’étendre sans développement lourd et les capacités d’IA et de Copilot inaccessibles sur AX deviennent envisageables à condition d’avoir des données fiables.

La migration est enfin l’occasion de solder la dette technique accumulée : des spécifiques qui ne servent plus, des contournements oubliés, des intégrations fragiles. Repartir sur une base propre ou remettre à plat le paramétrage c’est retrouver un ERP plus simple à maintenir et moins dépendant de quelques experts.

Dernier point souvent décisif : la capacité à absorber les nouvelles obligations. Un AX figé peine à suivre les évolutions réglementaires, là où Dynamics 365 intègre nativement des dispositifs comme la facturation électronique ou les états réglementaires. Rester sur l’ancien système c’est se condamner à bricoler chaque nouvelle contrainte.

Mise à niveau ou réimplémentation : le choix structurant

C’est la décision la plus importante du projet et elle conditionne tout le reste, deux chemins existent :

La mise à niveau consiste à faire remonter votre code existant et l’intégralité de votre historique de données vers Dynamics 365 à l’aide des outils fournis par Microsoft. Elle préserve l’antériorité et les développements spécifiques. Attention toutefois, cette voie n’est prise en charge que depuis AX 2012 R2 ou R3, si vous êtes sur AX 2009 ou une version antérieure il n’existe pas de saut direct, car il faut d’abord passer par AX 2012 R3, soit un parcours en deux temps. Certaines fonctionnalités dépréciées (sociétés virtuelles, partitions de données) empêchent par ailleurs la mise à niveau.
La réimplémentation consiste à repartir d’une base propre : on reconfigure la solution sur Dynamics 365, on ne reprend que les données utiles et on en profite pour revoir les processus. Cette voie est souvent la bonne quand le paramétrage d’AX a beaucoup vieilli ou s’est complexifié au fil des années, car une analyse d’écarts (fit-gap) révèle régulièrement que de nombreux développements spécifiques d’hier sont désormais couverts en standard par Dynamics 365.

Il n’y a pas de réponse universelle. Un AX récent (R3), peu personnalisé et globalement satisfaisant penche vers la mise à niveau ; un AX ancien, lourdement spécifique ou mal adapté penche vers la réimplémentation qui devient alors une occasion d’assainir. Ce diagnostic initial est le moment le plus rentable du projet : se tromper de voie coûte cher.

Le processus officiel : analyser, exécuter, valider

Microsoft structure la mise à niveau en trois phases, et il y a une bonne nouvelle pour les décideurs, car l’essentiel de la phase d’analyse peut être réalisé avant même d’acheter Dynamics 365 ce qui permet de décider en connaissance de cause.

La phase Analyser : elle sert à mesurer le travail et le risque. Le rapport d’analyse de mise à niveau est exécuté sur votre base AX 2012 et produit quatre éclairages clés : les fonctionnalités dépréciées que Dynamics 365 ne reprend pas (avec des alternatives suggérées), les nettoyages de données possibles, des optimisations de base de données et les réglages applicatifs à corriger. Un détail budgétaire à connaître : la taille de la base influe à la fois sur le coût d’abonnement et sur la durée de la migration donc nettoyer et archiver en amont fait baisser la facture et accélère le projet. En parallèle, l’outil de mise à niveau du code (Code upgrade tool) convertit votre code et liste les conflits à résoudre ce qui donne une estimation d’effort fiable. Un environnement de démonstration permet en outre une première analyse d’écarts (fit-gap). De cette phase sort un plan de projet chiffré : c’est là qu’on obtient un vrai repère de temps et de coût, avant de s’engager.
La phase Exécuter met le plan en œuvre, c’est à dire une mise à niveau du code, puis des données (d’abord en environnement de développement pour déboguer et ensuite en sandbox), configuration des écarts. Une règle s’impose alors : geler les évolutions sur AX 2012 (hors urgences) pour ne pas créer d’écart entre les deux systèmes pendant le chantier.
La phase Valider sécurise la bascule : campagnes de tests fonctionnels, tests de non-régression (l’outil RSAT en automatise une partie) et répétitions de bascule (mock cutover), pour ne rien découvrir le jour J.

Microsoft est explicite : les mises à niveau depuis AX 2012 sont complexes et les outils fournis doivent être vus comme « un cadre, pas une solution clé en main ». Pour aider, Microsoft propose le programme AIM (Accelerate, Innovate, Move) qui donne aux clients on-premises éligibles un accompagnement dédié vers le cloud : conseillers de migration, évaluations de valeur métier et technique, offres d’investissement et outils.

Les pièges d’une migration AX vers D365

L’expérience des projets repris montre que les échecs viennent rarement de l’outil et presque toujours de la méthode. Quelques pièges reviennent :

Sous-estimer la migration de données : Reprendre des années d’historique depuis un AX vieillissant, souvent peu propre, est le chantier le plus risqué. C’est un sujet de qualité et de gouvernance des données à part entière.
Conserver des spécifiques inutiles : Migrer mécaniquement d’anciens développements que le standard couvre désormais alourdit le projet et la maintenance future. Sans fit-gap rigoureux, on reproduit le passé au lieu de s’en libérer.
Bâcler les tests : Sans tests de non-régression sérieux ni répétition de bascule, les problèmes se découvrent en production et au pire moment.
Oublier les détails qui font perdre des données : Les pièces jointes (stockées sous AX dans des emplacements variés) ne sont reprises que si elles sont préparées avant la migration, sinon elles disparaissent à la bascule. Ce sont ces détails techniques invisibles dans un comité de pilotage qui font dérailler un projet.
Traiter la migration comme un projet purement technique : Un nouvel ERP change les usages. Sans conduite du changement ni formation l’adoption s’effondre et les bénéfices attendus ne se matérialisent pas.
Naviguer sans pilotage : Un projet de cette ampleur sans pilotage de projet solide dérive en délais et en budget.

C’est précisément sur ce terrain, celui des projets complexes et des situations à risque que se joue la réussite. C’est aussi le cœur du métier d’un partenaire rompu à la reprise de projets complexes.

Comment réussir sa migration

Une migration AX vers Dynamics 365 bien menée suit une logique claire. Commencez par un diagnostic : version d’AX, niveau de personnalisation, état des données, fonctionnalités dépréciées éventuelles. C’est lui qui éclaire le choix entre mise à niveau et réimplémentation, si vous menez une analyse d’écarts honnête pour ne reprendre que ce qui crée de la valeur et abandonner les spécifiques devenus inutiles. Traitez la migration des données comme un projet en soi, en fiabilisant les référentiels en amont. Testez rigoureusement avec des tests de non-régression et des répétitions de bascule. Et investissez dans la conduite du changement, car un ERP n’apporte ses bénéfices que s’il est adopté.

Enfin, entourez-vous d’un partenaire qui a déjà mené ce type de migration. La différence entre une migration sereine et un projet qui dérape ne tient pas à l’outil Microsoft, identique pour tous, mais à l’expérience de ceux qui le manient.

Enfin, la bascule n’est pas la fin du chantier : un Dynamics 365 se maintient et évolue en continu. C’est l’objet du modèle AMS, qui prend le relais du projet une fois les équipes de déploiement parties.

Ce que change le passage à l’abonnement

Le sujet est rarement abordé dans les comparatifs techniques, et il pèse pourtant sur la décision autant que le choix de la trajectoire.

Dynamics AX s’achetait : une licence perpétuelle, immobilisée au bilan, assortie d’une maintenance annuelle. Dynamics 365 se souscrit : un abonnement par utilisateur, traité en charge d’exploitation. Le basculement n’est pas seulement comptable, il change la façon dont la dépense se pilote.

La facture suit désormais les usages. Chaque compte actif compte. Les utilisateurs partis mais jamais désactivés, les comptes de service créés pour un besoin ponctuel, les profils surdimensionnés parce que « c’était plus simple » : tout cela devenait invisible sous licence perpétuelle. En abonnement, l’hygiène des comptes devient un poste de dépense à part entière, et une revue régulière des accès se rentabilise d’elle-même.

Les types d’utilisateurs ne se valent pas. Un collaborateur qui saisit des écritures et un responsable qui consulte un tableau de bord n’appellent pas le même niveau d’accès. Cartographier qui fait réellement quoi avant la bascule évite d’attribuer par défaut le profil le plus large à tout le monde — l’erreur la plus fréquente et la plus durable.

Le volume de données a un coût. La taille de la base influe sur l’abonnement comme sur la durée du projet. C’est l’un des rares chantiers où le nettoyage préalable produit un gain immédiat et mesurable, ce qui nous amène au sujet suivant.

Que devient l’historique AX : reprise, archivage et obligations légales

C’est la question qui revient toujours en comité de pilotage, et celle dont la réponse par défaut — « on reprend tout » — coûte le plus cher.

Trois trajectoires possibles

Tout reprendre. Rassurant, et parfois justifié quand l’antériorité sert quotidiennement. C’est aussi le chemin le plus long, le plus risqué et celui qui transporte dans le nouveau système des données dont plus personne ne garantit la qualité.

Reprendre les soldes et quelques exercices. Le compromis le plus fréquent : les balances d’ouverture, les tiers actifs, les en-cours, et un historique limité aux exercices réellement consultés. Le reste est archivé ailleurs.

Repartir propre et archiver. L’ERP ne conserve que ce qui sert à l’exploitation courante ; l’antériorité vit dans un entrepôt de données ou un archivage dédié, consultable mais hors du système transactionnel.

Le point que l’on découvre trop tard

Éteindre Dynamics AX ne fait pas disparaître les obligations qui pèsent sur les données qu’il contenait. Pendant toute la durée légale de conservation, l’entreprise doit rester capable de justifier ses écritures et de produire, sur demande de l’administration, le fichier des écritures comptables des exercices concernés. La piste d’audit doit rester reconstituable.

Or ce fichier se produit depuis le système qui a porté les écritures. Un AX éteint, dont les environnements ont été rendus et dont plus personne ne détient les compétences, place l’entreprise dans une situation inconfortable le jour où la demande arrive.

La parade est simple, à condition d’y penser avant la bascule : extraire les fichiers d’écritures comptables de tous les exercices encore couverts par l’obligation, les archiver dans un format pérenne avec leur documentation, et vérifier qu’ils sont exploitables — pas seulement qu’ils existent. Prévoir, le cas échéant, un environnement de consultation maintenu le temps nécessaire.

Ce contrôle prend quelques jours quand AX fonctionne encore. Il devient un chantier de reconstitution une fois le système éteint.

Conclusion

Rester sur Dynamics AX n’est plus une stratégie : c’est un report de décision qui coûte de plus en plus cher que ce soit en sécurité, en conformité et en agilité. La migration vers Dynamics 365 Finance & Operations est l’occasion de sortir d’un système figé pour retrouver un ERP qui évolue avec l’entreprise. Le vrai enjeu n’est pas technique, il est méthodologique : choisir la bonne voie entre mise à niveau et réimplémentation, traiter la donnée et les tests avec sérieux et accompagner les équipes. C’est cette rigueur, plus que l’outil, qui sépare une migration réussie d’une migration subie.

Spécialisé exclusivement sur Dynamics 365 Finance & Operations, et rompu à la reprise de projets complexes, FiveForty accompagne les entreprises qui quittent Dynamics AX, du diagnostic initial à la mise en service, avec clarté et maîtrise des risques.

Encore sous Dynamics AX et la migration vous inquiète ? Recevez notre grille de décision « mise à niveau ou réimplémentation ? », puis, chaque vendredi, Le Vendredi ERP, notre newsletter sur les coulisses des projets ERP. Recevoir la grille + m’abonner

FAQ

Dynamics AX est-il encore supporté par Microsoft ?

Non. La dernière version, AX 2012 R3, n’est plus supportée depuis le 10 janvier 2023 et les versions antérieures (AX 2009, 2012 RTM et R2) le sont depuis plus tôt encore. Cela signifie l’absence de mises à jour de sécurité et un risque croissant de sécurité et de conformité.

Quelle est la différence entre une mise à niveau et une réimplémentation ?

La mise à niveau remonte votre code et l’intégralité de votre historique de données vers Dynamics 365 à l’aide des outils Microsoft. La réimplémentation repart d’une base propre : on reconfigure la solution, on ne reprend que les données utiles et on révise les processus. Le bon choix dépend de votre version d’AX, du niveau de personnalisation et de l’état de vos données.

Peut-on migrer directement depuis Dynamics AX 2009 ?

Non, il n’existe pas de saut direct. La mise à niveau n’est prise en charge que depuis AX 2012 R2 ou R3. Depuis AX 2009 ou une version antérieure, il faut d’abord passer par AX 2012 R3, soit un parcours en deux étapes (ou opter pour une réimplémentation).

Combien de temps dure une migration AX vers Dynamics 365 ?

Cela dépend fortement de la version de départ, du volume et de la qualité des données, et du niveau de personnalisation. Microsoft rappelle que ces migrations sont complexes : elles se comptent généralement en mois et se planifient soigneusement, phase par phase, plutôt que dans l’urgence.
Peut-on éteindre Dynamics AX juste après la bascule ?

Pas immédiatement. Pendant la durée légale de conservation, l’entreprise doit rester en mesure de justifier ses écritures et de produire le fichier des écritures comptables des exercices concernés. Ces fichiers se produisent depuis le système qui les a portés : il faut donc les extraire, les archiver dans un format pérenne et vérifier qu’ils sont exploitables avant de rendre les environnements AX.

Faut-il reprendre tout l’historique dans Dynamics 365 ?

Rarement. Trois trajectoires existent : tout reprendre, reprendre les soldes et quelques exercices, ou repartir propre en archivant l’antériorité hors de l’ERP. Le volume de données influe à la fois sur le coût d’abonnement et sur la durée du projet, ce qui rend le nettoyage préalable directement rentable.

Le modèle de licence change-t-il entre AX et Dynamics 365 ?

Oui, et cela modifie la façon de piloter la dépense. AX s’achetait sous forme de licence perpétuelle immobilisée ; Dynamics 365 se souscrit par abonnement, traité en charge. La facture suit alors les usages : comptes inactifs jamais désactivés et profils surdimensionnés deviennent un coût visible. Une cartographie des accès avant la bascule évite d’attribuer par défaut le profil le plus large à tous.