Migration Dynamics NAV vers Business Central

Les deux chemins de migration que Microsoft propose, et ce que chacun garde

Microsoft documente deux façons de passer de Dynamics NAV à Business Central en ligne. Les deux commencent par la même étape : monter NAV en Business Central version 14 on-premise. Il n’existe pas de saut direct de NAV vers le cloud.

Migration complète. Toutes vos données et vos personnalisations suivent. Le prix : chaque personnalisation C/AL doit être convertie en extensions AL, et le système doit monter au-delà de la version 14, vers une version on-premise actuelle, avant que la migration cloud ne tourne.

Réimplémentation. Vous vous arrêtez en version 14 et utilisez l’outil de réimplémentation Business Central 14 de Microsoft. Pas de conversion en extensions. Il reprend les données de base, les commandes ouvertes, les soldes d’ouverture et le paramétrage, plus un sous-ensemble défini de l’historique validé, comme les écritures comptables et les factures vente validées. Vos anciennes personnalisations et leurs données restent derrière.

Deux choses à savoir avant de miser sur ce second chemin. En septembre 2026, Microsoft présente l’outil de réimplémentation comme une fonctionnalité en préversion, pas destinée à la production. Et ses propres pages le décrivent à la fois comme ne reprenant aucune transaction historique et comme reprenant ce sous-ensemble d’écritures validées. Vérifiez sur vos propres données ce qu’il reprend vraiment avant de promettre un nouveau départ à qui que ce soit.

Le bon chemin n’est pas une question technique. Tout dépend de si les règles encodées dans votre code custom sont encore celles de votre métier. Si oui, une réimplémentation les jette. Si non, une migration complète paie pour les transporter.

La route de montée de version depuis votre NAV

Votre version de départ fixe la route. Chaque étape est une vraie montée de version, jouée et vérifiée à part. Voici la route documentée par Microsoft en septembre 2026 :

En réimplémentation, la route s’arrête à la version 14 et l’outil de réimplémentation prend le relais. Microsoft ne documente aucune route pour une version antérieure à NAV 2009 SP1.

Trois vérifications avant la première étape. La base SQL Server doit tourner en niveau de compatibilité 130 ou plus. La localisation de votre pays doit exister sous forme d’app dans Business Central en ligne, et tout code fiscal ou de reporting local doit être réécrit pour fonctionner avec elle. Et Microsoft demande au moins une répétition complète sur sandbox avant la bascule en production. Sautez-la, et votre week-end de bascule devient la répétition.

Ce que l’outil de migration cloud reprend, et ce qu’il ne peut pas reprendre

Une fois sur une version on-premise prise en charge, le passage en ligne se fait par la migration cloud de Microsoft. Vous connectez la base on-premise au tenant en ligne et installez l’Integration Runtime. Azure Data Factory réplique alors les données, d’abord en totalité, puis par deltas. La mise à niveau des données tourne en dernier. Ensuite vous terminez la migration, et l’environnement en ligne devient le système de production.

L’outil déplace des données. Il ne décide rien. Les données des tables porteuses de personnalisations de code ne suivent que si ces personnalisations existent en extensions AL installées à la fois côté on-premise et côté en ligne. Un champ custom jamais transformé en extension est un champ dont les données restent derrière.

Et le cloud refuse ce que l’on-premise tolérait. Le plus gros sujet est l’interop .NET, très utilisée dans les NAV de cette génération. Le convertisseur vous rendra de l’AL qui compile et qui ne pourra pourtant jamais être publié en SaaS. Vous le découvrez au déploiement, sauf si quelqu’un le vérifie pendant l’audit.

La plupart des migrations NAV échouent sur une décision que personne n’a prise

L’échec est rarement technique. Quinze ans après la mise en route d’un Dynamics NAV, plus personne ne sait pourquoi la moitié du paramétrage existe. Un champ a été ajouté pour un client parti en 2014. Une routine de validation a été tordue autour d’une règle qui a changé depuis deux réorganisations. Un état existe parce qu’un contrôleur de gestion l’a demandé une fois.

Personne n’a décidé de garder tout ça. Ça a survécu parce que supprimer paraissait plus risqué que déplacer. Le projet de migration hérite donc de toutes les décisions non prises d’un coup, et le logiciel encode fidèlement la décision manquante, à l’échelle.

C’est pour ça qu’on commence par un audit et pas par un mapping de données, la même approche par la cause racine que sur toute question ERP de groupe. Tant qu’on ne sait pas quelles règles font encore tourner l’entreprise, chaque choix technique qui suit est une supposition déguisée en planning.

Vos données et votre logique sont deux projets différents

On les traite comme un seul, et c’est là que les budgets meurent. L’historique est un problème de conservation : il doit rester exact, auditable et accessible. La logique est un problème de conception : elle doit mériter d’être reconstruite.

En migration complète, on peut conserver votre historique. On recommandera rarement de migrer 100% de votre logique. Ce sont deux décisions sans rapport, et les confondre est ce qui transforme une migration en transfert de dette sur quinze ans.

Sur ce chemin, les écritures validées, les postes ouverts, les axes analytiques et les soldes arrivent intacts, avec une réconciliation présentable à un commissaire aux comptes. Les personnalisations, elles, sont jugées une par une, sur la seule question de savoir si la règle métier derrière est encore vraie.

Ce qui arrive à quinze ans de personnalisations

Chacune est classée dans une des trois issues. Elle est devenue standard dans Business Central, elle disparaît. Elle encode une règle qui fait encore tourner le métier, elle est reconstruite proprement en extension. Ou personne ne sait nommer la règle qu’elle sert, et elle meurt, avec une trace écrite de ce qui est mort et pourquoi.

Nous ne sommes pas anti-personnalisation. Nous sommes contre la personnalisation négligente, celle qui est cosmétique, celle qui masque un process absent, celle qui casse à chaque mise à jour. Nous savons quand il faut construire mille objets et quand il faut n’en construire aucun. La plupart des migrations se trompent sur les deux, dans le même projet.

La mesure d’une bonne reconstruction n’est pas la quantité de code évitée. C’est de savoir si ce code passe la mise à jour du mois suivant sans que personne n’y touche.

Ce qu’une migration NAV nous a appris, de la conversion au SaaS

Une migration que nous avons menée est passée du C/AL converti à Business Central SaaS en production en huit mois. La conversion elle-même a tenu en une journée. S’approprier ce qu’elle produisait a pris bien plus longtemps : des numéros d’objets au lieu de noms, des blocs with qui cachent à quel enregistrement appartient un champ, des variables mortes que personne n’avait jamais été obligé de regarder.

L’ordre que nous referions. Une app de tests dédiée trois semaines après la conversion, avant tout nettoyage, pour que chaque changement ensuite soit prouvable. Cinq mois en on-premise sur la version courante d’abord, volontairement, pour que « le code se comporte-t-il comme NAV » et « le code est-il admis dans le cloud » aient des réponses séparées. La seconde question a coûté à elle seule quatre jours et trois changements de cible de l’app avant que le code .NET soit remplacé par de l’AL écrit pour l’occasion.

Et la décision qui surprend : le code converti est resté une seule app pendant dix-huit mois avant d’être découpé. Les coutures visibles dans un monolithe converti sont les limites de l’ancien système, pas celles du métier. Les vraies sont apparues en exploitation. Ce code fait aujourd’hui treize apps, et les montées de version majeures arrivent sans projet.

L’histoire complète, commit par commit : huit mois de NAV à Business Central SaaS, et trois ans pour pouvoir y toucher sans peur.

Business Central se met à jour deux fois par an, et il ne demande pas la permission

C’est ce à quoi NAV n’a préparé personne. En on-premise, vous montiez de version quand vous le décidiez, ce qui pour beaucoup de groupes voulait dire presque jamais. Business Central en ligne livre deux vagues majeures par an et des mises à jour mensuelles, au calendrier de Microsoft.

Une migration qui dépose un bloc de code fortement couplé dans ce rythme n’a pas terminé, elle a programmé sa propre crise. Le modèle d’extension existe précisément pour l’éviter, mais seulement si le code le respecte : aucune dépendance à des internes que Microsoft peut changer, des abonnements à événements plutôt que des modifications, et une base de tests qui vous dit qu’une mise à jour a cassé quelque chose avant que vos utilisateurs ne le découvrent.

Une grosse application métier peut dépasser le millier d’objets AL et absorber malgré tout chaque mise à jour mensuelle sans impact. Ce résultat est une décision de conception prise pendant la migration, pas un effort de maintenance ajouté après coup.

Les groupes multi-entités ont un problème plus dur, et il n’est pas technique

D’une filiale à l’autre, le même mot ne désigne pas la même chose. Deux entités parlent de livraison et visent deux moments différents. Trois plans comptables ont divergé parce que chacun était maintenu localement et que personne n’a arbitré.

Une migration met cet arbitrage au grand jour, en général tard, en général sous forme de ticket technique, en général tranché par qui se trouve dans la salle. C’est la manière la plus coûteuse de prendre une décision de groupe.

Nous faisons remonter ces conflits pendant l’audit, nous les nommons comme des décisions qui appartiennent au comité de direction et pas à un consultant, et nous les faisons trancher avant que quoi que ce soit ne soit paramétré. La consolidation, les flux intercos et le reporting groupe cessent d’être un sujet de phase deux et deviennent une contrainte que la conception respecte déjà.

Combien de temps, et ce qui pilote vraiment le coût

La variable n’est presque jamais le volume de données. C’est le nombre de décisions non prises et le nombre d’objets custom qui ont encore une raison défendable d’exister.

Un NAV mono-entité propre avec peu de personnalisation est un projet court. Un groupe multi-entités avec quinze ans de logique accumulée, plusieurs plans comptables et aucune documentation de process à jour est un programme de transformation, et le chiffrer comme une reprise de données est exactement la façon dont il finit en sauvetage Business Central.

L’audit sert à vous dire dans lequel des deux vous êtes, avant d’engager un budget. Il produit un verdict écrit sur ce qui bouge, ce qui meurt et pourquoi, et une feuille de route avec des phases entre lesquelles vous pouvez réellement vous arrêter.