Votre entreprise utilise Dynamics NAV depuis plusieurs années. L’ERP fonctionne encore, vos équipes le connaissent parfaitement et de nombreux processus ont été construits autour de lui.
À première vue, la migration vers Microsoft Dynamics 365 Business Central semble donc relativement simple : reprendre les données, adapter les développements existants, former les utilisateurs puis basculer vers le cloud.
Dans la réalité, les projets qui dérapent ne rencontrent pas nécessairement un problème avec Business Central.
Ils rencontrent surtout un problème de préparation.
Une personnalisation importante est découverte trop tard. Une interface critique n’a pas été documentée. Des données obsolètes sont transférées sans nettoyage. Les utilisateurs sont formés quelques jours avant le démarrage. Le projet commence alors à accumuler des retards, des développements supplémentaires et des coûts qui n’avaient pas été anticipés.
Migrer de Dynamics NAV vers Business Central ne consiste donc pas à déplacer un ancien ERP vers une nouvelle infrastructure. Il s’agit de décider ce que l’entreprise souhaite conserver, simplifier, transformer ou abandonner.
C’est cette série de décisions, bien plus que la migration technique, qui détermine la réussite du projet.
Pourquoi les entreprises envisagent-elles de quitter Dynamics NAV ?
Dynamics NAV a accompagné la croissance de nombreuses PME et ETI. Au fil des années, la solution a souvent été enrichie par des développements spécifiques, des interfaces et des procédures adaptées aux besoins de chaque entreprise.
Cette capacité de personnalisation a longtemps constitué une force. Mais elle peut aussi devenir une source de complexité.
Les mises à niveau sont plus difficiles à réaliser. Les intégrations avec les nouveaux outils demandent davantage de maintenance. Certaines opérations reposent toujours sur des fichiers Excel ou des ressaisies manuelles. Les équipes disposent de données, mais pas toujours d’une vision unifiée de l’activité.
Business Central permet de moderniser cet environnement en donnant accès au cloud Microsoft, aux mises à jour régulières, à Power BI, à Power Platform, à Microsoft 365 et aux nouvelles fonctionnalités assistées par l’intelligence artificielle.
Toutefois, ces bénéfices ne sont pas automatiques.
Une entreprise qui reproduit exactement dans l’erp Business Central tout ce qu’elle avait construit dans NAV risque simplement de déplacer sa complexité dans le cloud.
La première question à poser n’est donc pas : « Comment reprendre notre environnement actuel ? »
La bonne question est plutôt : « De quel environnement avons-nous réellement besoin pour les prochaines années ? »
Première erreur : lancer le projet sans auditer l’existant
Un projet de migration commence parfois par le choix des licences, la création du nouvel environnement ou l’estimation du volume de données à transférer.
À ce stade, l’équipe projet ne connaît pourtant pas encore précisément tout ce qui dépend de NAV.
Au fil du temps, l’ERP a pu être connecté à un CRM, un site e-commerce, une solution bancaire, un logiciel logistique, un outil de production ou des applications internes. Certains échanges sont automatisés. D’autres reposent sur des fichiers déposés manuellement. Quelques traitements sont parfois connus d’un seul collaborateur.
Si cet écosystème n’est pas cartographié avant le démarrage, les dépendances apparaissent progressivement pendant le projet. Chaque découverte entraîne alors une nouvelle analyse, un développement supplémentaire et potentiellement un report du calendrier.
L’audit initial doit donc couvrir bien plus que la version de NAV.
Il doit identifier les processus métier, les personnalisations, les interfaces, les volumes de données, les profils utilisateurs, les règles de sécurité et les irritants opérationnels.
Chez Dynamics Connect, cette phase de diagnostic sert à distinguer trois catégories d’éléments : ce qui doit impérativement être conservé, ce qui peut être remplacé par le standard de Business Central et ce qui n’a plus de raison d’exister.
Cet arbitrage évite de reconstruire automatiquement plusieurs années de complexité.
Deuxième erreur : vouloir reprendre toutes les personnalisations
Une entreprise qui utilise Dynamics NAV depuis longtemps dispose souvent de nombreux développements spécifiques.
Certains répondent encore à des besoins stratégiques. D’autres ont été créés pour contourner une ancienne limite de NAV, alors que Business Central propose désormais une fonctionnalité standard équivalente. Certains ne sont presque plus utilisés, mais restent présents dans l’environnement.
Les transférer sans analyse peut considérablement augmenter la durée et le coût du projet.
La difficulté est également technique. Les développements historiques réalisés en C/AL ne sont pas simplement copiés dans Business Central Online. Ils doivent être repensés ou convertis en extensions AL.
Microsoft précise que les données provenant de tables contenant des personnalisations de code ne peuvent pas être reprises correctement tant que ces personnalisations n’ont pas été traitées dans le nouvel environnement.
La bonne méthode consiste donc à analyser chaque personnalisation en posant quatre questions :
● répond-elle toujours à un besoin métier actuel ?
● une fonction standard de Business Central peut-elle la remplacer ?
● peut-elle être reconstruite plus efficacement avec une extension ou Power Platform ?
● sa valeur justifie-t-elle son coût futur de maintenance ?
Ce travail permet de réduire la dette technique et de construire un environnement plus simple à faire évoluer.
Troisième erreur : choisir trop rapidement entre migration et réimplémentation
Toutes les entreprises ne doivent pas suivre la même trajectoire.
Une migration complète cherche à reprendre les données, l’historique et les personnalisations nécessaires. Elle peut être adaptée lorsque les processus sont bien structurés, que les données sont fiables et que la majorité des développements reste pertinente.
La réimplémentation poursuit un objectif différent. Elle consiste à repartir sur un environnement Business Central rationalisé et à reprendre uniquement les éléments nécessaires : données de référence, paramètres, soldes d’ouverture et historique sélectionné.
Cette seconde approche peut être plus pertinente lorsque l’environnement NAV est devenu très spécifique, lorsque les données sont insuffisamment fiables ou lorsque l’entreprise souhaite revoir profondément son organisation.
La version de NAV influence également le parcours technique.
Selon Microsoft, les anciennes versions ne migrent pas directement vers Business Central Online. Elles doivent passer par des versions intermédiaires prises en charge. Une entreprise sous NAV 2009 ne suivra donc pas le même chemin qu’une organisation utilisant NAV 2018.
Choisir une trajectoire avant d’avoir étudié la version, les personnalisations et la qualité des données revient à construire un calendrier sur des hypothèses fragiles.
Chez Dynamics Connect, le choix entre migration complète et réimplémentation est réalisé après le diagnostic. Il repose sur le niveau de complexité de l’environnement, la valeur de l’historique, les contraintes réglementaires et les objectifs métier de l’entreprise.
Quatrième erreur : confondre reprise des données et qualité des données
La peur de perdre l’historique pousse souvent les entreprises à vouloir tout transférer.
Pourtant, une base NAV ancienne peut contenir des clients en doublon, des fournisseurs inactifs, des références obsolètes, des écritures difficilement exploitables ou des nomenclatures devenues incohérentes.
Business Central ne corrigera pas automatiquement ces problèmes.
Si toutes les données sont reprises sans nettoyage, le nouvel ERP démarre avec les mêmes incohérences que l’ancien. Les tableaux de bord deviennent moins fiables, les recherches restent complexes et les utilisateurs continuent à contourner le système.
La préparation des données doit donc répondre à trois objectifs.
Il faut d’abord déterminer les informations réellement nécessaires au fonctionnement futur de l’entreprise. Il faut ensuite définir les règles de nettoyage et de transformation. Enfin, il faut organiser la validation métier après chaque reprise test.
Cette dernière étape est essentielle. La présence d’une donnée dans Business Central ne garantit pas qu’elle soit correcte, complète ou utilisable dans les opérations quotidiennes.
Cinquième erreur : découvrir les interfaces pendant la migration
Un ERP fonctionne rarement seul.
Il reçoit et transmet des informations à plusieurs applications. Pourtant, les interfaces sont parfois considérées comme un sujet secondaire, traité après la migration des données.
C’est une erreur.
Une interface avec la banque, le site e-commerce ou le logiciel d’entrepôt peut être techniquement discrète, mais essentielle au fonctionnement de l’entreprise. Si elle n’est pas disponible au démarrage, les équipes doivent revenir à des traitements manuels.
Chaque flux doit être analysé avant la conception de l’environnement cible : origine de la donnée, destination, fréquence, niveau de criticité, mécanisme de contrôle et procédure en cas d’échec.
Ce travail permet aussi de remettre en question les anciennes intégrations.
Certaines peuvent être remplacées par les API de Business Central. D’autres peuvent être automatisées avec Power Automate. Les besoins plus complexes peuvent être traités à travers Azure ou des extensions compatibles avec l’écosystème Microsoft.
La migration devient alors une occasion de fiabiliser les échanges, et non seulement de les reproduire.
Sixième erreur : tester l’outil plutôt que les processus
Une recette technique peut confirmer que Business Central fonctionne correctement : l’environnement est accessible, les données sont présentes et les interfaces communiquent.
Cela ne signifie pas encore que l’entreprise est prête à démarrer.
La véritable question est de savoir si les utilisateurs peuvent accomplir leurs opérations critiques dans le nouvel environnement.
Un commercial peut-il créer et suivre une commande complète ? Le service achats peut-il gérer un approvisionnement ? L’entrepôt peut-il réceptionner et expédier des marchandises ? La direction financière peut-elle clôturer une période et produire les contrôles attendus ?
La recette doit donc être construite autour de scénarios métier de bout en bout.
Ces tests doivent être réalisés avec les futurs utilisateurs, dans des conditions aussi proches que possible de la réalité. Ils permettent de vérifier simultanément les données, les droits, les extensions, les interfaces et la cohérence du processus.
Une anomalie découverte à ce stade peut encore être corrigée sans perturber l’activité. La même anomalie identifiée après la mise en production peut bloquer plusieurs équipes.
Septième erreur : traiter la formation comme la dernière étape
Les utilisateurs ne découvrent pas seulement une nouvelle interface.
Ils doivent parfois adopter de nouveaux processus, abandonner certaines habitudes et comprendre pourquoi des règles ont changé.
Une formation organisée quelques jours avant la bascule leur apprend à cliquer dans l’outil. Elle ne garantit pas qu’ils maîtriseront leur nouveau mode de fonctionnement.
La conduite du changement doit commencer pendant le projet.
Les utilisateurs référents doivent participer aux ateliers, valider les parcours et contribuer aux tests. Leur implication permet de détecter plus tôt les écarts entre le modèle conçu et les réalités du terrain.
La formation peut ensuite être adaptée à chaque rôle : finance, ventes, achats, logistique, direction ou administration.
Après la mise en production, un support renforcé reste nécessaire pour répondre aux questions, corriger les premières anomalies et éviter le retour aux fichiers parallèles.
Le succès d’une migration ne se mesure pas uniquement au respect de la date de bascule. Il se mesure aussi à l’adoption réelle de Business Central par les équipes.
La méthode Dynamics Connect : sécuriser les décisions avant de sécuriser la technique
Dynamics Connect accompagne les entreprises depuis l’audit de leur environnement NAV jusqu’à la stabilisation de Business Central.
Notre approche commence par la compréhension de l’existant : processus, données, développements, interfaces et contraintes opérationnelles. Cette analyse permet ensuite de définir une architecture cible et une trajectoire réaliste.
Les fonctions standards de Business Central sont privilégiées chaque fois qu’elles répondent au besoin. Les développements spécifiques sont conservés lorsqu’ils apportent une véritable valeur métier. Les intégrations sont repensées dans l’écosystème Microsoft afin de faciliter leur maintenance et leur évolution.
La migration est ensuite validée progressivement à travers des environnements de test, des reprises pilotes et des scénarios de recette métier. La mise en production n’intervient qu’après validation des critères fonctionnels et techniques définis avec le client.
Enfin, l’accompagnement ne s’arrête pas à la bascule. La phase de stabilisation permet de suivre les usages, de corriger les écarts et de prioriser les améliorations futures.
Cette méthode réduit les décisions prises dans l’urgence et donne à l’entreprise une vision plus claire du périmètre, du budget et des risques.
Pourquoi confier votre migration à Dynamics Connect ?
Dynamics Connect est un pure player Microsoft spécialisé dans les projets Dynamics 365 et Power Platform.
Nos équipes interviennent sur Business Central, Dynamics 365 Sales, Field Service, Supply Chain et les technologies complémentaires de l’écosystème Microsoft.
Dynamics Connect dispose également du statut Microsoft Solutions Partner Business Applications. Cette reconnaissance valide notamment les compétences certifiées, la capacité de delivery, la performance et l’accompagnement client.
Cette expertise nous permet d’aborder une migration NAV sous plusieurs angles : architecture, finance, opérations, données, automatisation, intégrations et adoption des utilisateurs.
Notre objectif n’est pas de reconstruire votre ancien ERP dans le cloud.
Il est de transformer votre environnement NAV en une plateforme Business Central plus simple, plus connectée et capable d’évoluer avec votre activité.
Comment savoir si votre entreprise est prête à migrer ?
Avant de lancer le projet, vous devez être capable de répondre clairement aux questions suivantes :
● quelle version de NAV utilisez-vous actuellement ?
● quels développements spécifiques sont encore indispensables ?
● quelles applications échangent des données avec NAV ?
● quel historique devez-vous conserver dans le nouvel ERP ?
● quelles données nécessitent un nettoyage ?
● quels processus souhaitez-vous améliorer ?
● quels utilisateurs doivent participer à la recette ?
● quelles contraintes pourraient influencer la date de bascule ?
Si plusieurs réponses restent incertaines, la priorité n’est pas encore de fixer une date de démarrage.
Elle est de réaliser un diagnostic.
Une migration réussie ne commence pas par le transfert des données
Elle commence par une compréhension précise de l’environnement existant et par des décisions claires sur l’environnement futur.
Les projets qui dérapent cherchent souvent à aller trop vite vers la solution technique. Les projets maîtrisés prennent d’abord le temps d’identifier les dépendances, de rationaliser les personnalisations, de nettoyer les données et d’impliquer les utilisateurs.
Vous envisagez de migrer de Dynamics NAV vers Business Central ?
Dynamics Connect peut réaliser un audit fonctionnel et technique de votre environnement pour identifier la trajectoire adaptée, les risques à anticiper et le périmètre réel de votre projet.
Demandez votre audit de migration vers Business Central.
📱 09 80 80 25 41