Migrer de Dynamics AX vers Dynamics 365 : Le Guide

Si votre entreprise tourne encore sur Microsoft Dynamics AX, la migration vers Dynamics 365 est acquise dans son principe ; restent le moment et la méthode. 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, plus aucune mise à jour de sécurité ne paraît, et le système s’éloigne chaque mois un peu plus des besoins de l’entreprise comme des exigences de conformité.

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

Le premier moteur de la décision reste le risque, bien avant l’envie de nouveauté. 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) avaient quitté le support avant elle.

Un ERP sans support pose d’abord un problème de sécurité : aucune mise à jour ne corrige plus les vulnérabilités, ce qui expose l’entreprise et complique les audits, les certifications et parfois la couverture d’assurance. Il pose ensuite un problème d’obsolescence : AX n’évolue plus, et l’écart se creuse avec les attentes métier et les obligations réglementaires nouvelles.

Tant que « tout fonctionne », l’inertie domine. Le coût d’un système figé reste pourtant bien réel : contournements, dépendance à quelques experts, intégrations fragiles, impossibilité d’absorber une nouvelle réglementation. La fin de support agit lentement, et chaque mois qui passe ajoute à la dette.

Nous le constatons régulièrement : tout le monde connaît les dates, et beaucoup d’entreprises repoussent pourtant le sujet d’un exercice à l’autre. Elles finissent par migrer au pire moment, dans l’urgence, quand une obligation nouvelle ou le départ d’un expert les y contraint.

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. On y retrouve la filiation fonctionnelle d’AX, portée sur une plateforme cloud.

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) : Microsoft publie quatre mises à jour de service par an, dont au moins deux doivent être installées. S’y ajoutent une interface modernisée, des capacités multi-sociétés, multi-pays et multilingues, et l’accès à l’écosystème Microsoft : Power Platform, Power BI, Copilot et les agents.

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

La migration apporte aussi un saut de capacités. Le modèle One Version met fin aux grandes montées de version douloureuses : les mises à jour deviennent régulières et maîtrisées, et le système ne se retrouve plus coincé sur une édition obsolète.

L’écosystème Microsoft s’ouvre également. 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 inaccessibles sur AX deviennent envisageables, à condition d’avoir des données fiables, comme l’explique notre article sur Copilot dans Dynamics 365.

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. Remettre le paramétrage à plat donne 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 des dispositifs comme la facturation électronique ou les états réglementaires produits avec l’Electronic Reporting. Rester sur l’ancien système oblige à bricoler chaque nouvelle contrainte.

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

1. La mise à niveau fait 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. Cette voie n’est prise en charge que depuis AX 2012 R2 ou R3, à jour de la dernière mise à jour cumulative disponible. Depuis AX 2009 ou une version antérieure, il n’existe pas de saut direct : 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.
2. La réimplémentation repart 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.

Aucune réponse ne vaut pour tous. 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, car se tromper de voie coûte cher. Notre article sur le cadrage d’un projet D365 F&O détaille comment le mener.

Microsoft structure la mise à niveau en trois phases, et 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.

Analyser : mesurer le travail et le risque

Le rapport d’analyse de mise à niveau, exécuté sur votre base AX 2012, éclaire quatre sujets : 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, les optimisations de base de données et les réglages applicatifs à corriger. Côté AX, une liste de contrôle de préparation, livrée avec la mise à jour cumulative 13 d’AX 2012 R3, prépare notamment la correspondance entre les utilisateurs AX et leurs comptes Microsoft Entra ID.

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 allège 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. De cette phase sort un plan de projet chiffré, avant tout engagement.

Exécuter : code, données et écarts

La phase Exécuter met le plan en œuvre : mise à niveau du code, puis des données, d’abord en environnement de développement pour déboguer, ensuite en environnement de test, puis configuration des écarts. Microsoft propose une mise à niveau des données en libre-service sur les environnements de test, jamais directement sur la production. Une règle s’impose pendant cette phase : geler les évolutions sur AX 2012 (hors urgences) pour ne pas créer d’écart entre les deux systèmes.

Valider : sécuriser la bascule

La phase Valider enchaîne les campagnes de tests fonctionnels, les tests de non-régression et les répétitions de bascule (mock cutover), pour ne rien découvrir le jour J. Pour l’automatisation des tests, une échéance est à anticiper : Microsoft a annoncé que l’outil RSAT, longtemps utilisé pour automatiser les tests de non-régression, ne sera plus pris en charge après le 15 mai 2027. Un projet qui démarre aujourd’hui doit donc choisir sa stratégie de tests automatisés en tenant compte de cette date.

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 accompagner ces clients, Microsoft a lancé en 2023 le programme AIM (Accelerate, Innovate, Move), qui offre aux clients sur site éligibles des évaluations, des conseillers de migration et des offres d’investissement ; ses conditions se vérifient au moment du projet.

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 analyse d’écarts rigoureuse, 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, 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. Ces détails techniques, invisibles en comité de pilotage, suffisent à faire 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. Notre article pourquoi les projets ERP échouent détaille les causes les plus fréquentes.

La réussite se joue sur ce terrain, celui des projets complexes et des situations à risque, qui est le cœur du métier d’un partenaire rompu à la reprise de projets complexes. Si votre migration montre déjà des signes de dérive, notre article sur les signaux qui doivent alerter aide à les reconnaître.

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. Il éclaire le choix entre mise à niveau et réimplémentation, à condition de mener une analyse d’écarts honnête pour ne reprendre que ce qui crée de la valeur. Traitez ensuite 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. Investissez enfin dans la conduite du changement, car un ERP n’apporte ses bénéfices que s’il est adopté.

Entourez-vous d’un partenaire qui a déjà mené ce type de migration. L’outil Microsoft est identique pour tous ; l’expérience de ceux qui le manient fait la différence entre une migration sereine et un projet qui dérape. Notre guide pour choisir son intégrateur Dynamics 365 détaille les questions à poser.

Après la bascule, un Dynamics 365 se maintient et évolue en continu, au rythme des mises à jour de Microsoft. C’est l’objet du modèle AMS, qui prend le relais du projet une fois les équipes de déploiement parties.

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. Au-delà de la comptabilité, le basculement 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 restait 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.

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 et le plus risqué, 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 hors du système transactionnel.

Le point que l’on découvre trop tard

Éteindre Dynamics AX laisse intactes 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 (FEC) 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 réellement exploitables. 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.

Rester sur Dynamics AX revient à reporter une décision qui coûte chaque année un peu plus cher, en sécurité comme en conformité. La migration vers Dynamics 365 Finance & Operations permet de sortir d’un système figé pour retrouver un ERP qui évolue avec l’entreprise. Son succès tient surtout à la méthode : choisir la bonne voie entre mise à niveau et réimplémentation, puis traiter avec sérieux la donnée et les tests, sans oublier les équipes. Cette rigueur 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.

Mise à niveau ou réimplémentation ?

Recevez notre guide de décision pour quitter Dynamics AX. Et chaque vendredi, Le Vendredi ERP raconte les coulisses des projets ERP.

Recevoir le guide