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.
On peut conserver 100% de 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.
Concrètement, 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.
Une migration qu’on a menée montre tout l’arc, du début à la fin : 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.
