Reprise de données Business Central : ce qui traverse depuis NAV, et ce qui ne devrait pas
Dans une migration NAV vers Business Central, la donnée ne traverse que vers des tables qui existent des deux côtés, avec la même forme. Microsoft l’écrit sans détour : les données des tables qui portent du code spécifique ne peuvent pas être reprises tant que ce spécifique n’est pas porté par des extensions installées à la fois côté on-premises et côté online. La reprise de données et le projet de code sont donc deux projets, et le second décide de ce que le premier a le droit de déplacer.
Conséquence budgétaire, souvent ignorée : on ne peut pas chiffrer la reprise tant qu’on ne sait pas quels développements survivent sous forme d’extensions, et la reprise ne s’arrête pas le jour du démarrage.
Que déplacent réellement les outils Microsoft depuis NAV ?
Il n’existe pas de saut direct de NAV vers Business Central online. Les deux chemins documentés commencent pareil : mettre NAV à niveau vers Business Central version 14 on-premises.
La migration complète. On convertit chaque développement C/AL en extension AL, on monte l’on-premises au moins en version 25, puis on lance la migration cloud. Tout ce qui a une table correspondante online peut passer, historique compris.
La réimplémentation. On utilise l’outil de réimplémentation Business Central 14, actuellement en préversion, qui dispense de la conversion en extensions et de la montée de version au-delà de la 14. Il reprend les données de base, les documents ouverts, les soldes d’ouverture, le paramétrage et un sous-ensemble défini de l’historique validé. Les développements hérités et leurs données restent derrière, sauf si l’on étend l’outil pour des tables spécifiques précises.
Quel que soit le chemin, le moteur de migration cloud travaille table par table et suit le succès ou l’échec de chacune. Une table échoue si elle est introuvable online ou si son schéma ne correspond pas ; l’erreur est consignée et la migration passe à la table suivante. Une migration qui se termine n’est pas une migration où tout est arrivé.
Certaines choses ne traversent jamais, par conception : la plupart des tables système, les utilisateurs et les autorisations. La sécurité se reconstruit dans le cloud, elle ne s’hérite pas. Les liens et notes d’enregistrement attendent dans une table tampon : l’action Migrate Record Links and Notes les transfère, avant le mappage des utilisateurs.
Pourquoi la donnée ne peut-elle pas atterrir avant le code ?
Parce que les points d’atterrissage sont du code. Chaque table spécifique et chaque champ ajouté à une table standard dans NAV devient, dans Business Central, un objet d’extension. Si cet objet n’est pas installé online, la donnée n’a nulle part où aller.
Voici à quoi ressemble cette surface sur une vraie base de code NAV que nous avons migrée vers Business Central SaaS et que nous maintenons toujours, pour l’ensemble des apps de la solution (1 037 fichiers .al versionnés) :
- 164 tables spécifiques, portant 2 787 champs ;
- 74 extensions de table, qui ajoutent 1 545 champs à des tables existantes ;
- une même table standard étendue par onze extensions de table distinctes.
Ces quelque 4 300 champs sont la surface que la solution déclare aujourd’hui, pas un comptage de l’existant NAV : des champs et des tables ont été ajoutés après le démarrage, et quelques objets ne servent qu’à la mise à niveau elle-même. Mais chacun de ceux qui existaient déjà dans NAV est un endroit où la donnée NAV atterrit ou se perd, et aucun n’existe dans Business Central tant que quelqu’un n’a pas converti, compilé et installé l’extension qui le déclare. D’où la deuxième étape du guide Microsoft sur les développements, juste après l’inventaire : séparer ceux qui portent de la donnée (tables spécifiques, champs ajoutés) de ceux qui ne portent que du comportement (mises en page, logique d’état). Le premier groupe conditionne la reprise. Le second, non.
Ce qui a changé en passant cette base de code de Dynamics NAV à Business Central, de la syntaxe C/AL aux dépendances .NET, est une histoire à part. Pour la donnée, la question est plus simple : chaque champ qui contient quelque chose d’utile est-il couvert par une extension installée, avec la même forme des deux côtés ?
Quels réglages d’extension décident de la réplication des données ?
Deux conditions, toutes deux documentées. L’extension doit être installée dans l’environnement online, et sa propriété ReplicateData doit valoir true. C’est la valeur par défaut : la plupart des extensions installées répliquent donc sans que personne l’ait décidé.
Les pièges sont dans les décalages. Une extension installée online mais pas on-premises déclenche des avertissements, et ses tables liées ne migrent pas. Une extension qui étend une table de base peut faire apparaître cette table vide online ; Microsoft prévoit pour ce cas l’action Repair Companion Table Records sur la page Cloud Migration Management, et recommande de comparer on-premises le nombre d’enregistrements entre la table de base et son extension.
Rien de tout cela ne se voit dans un plan de projet découpé en phases. Cela se voit dans une liste de tables avec une colonne de statut, exactement ce qu’affiche la page Cloud Migration Management. Après chaque migration à blanc, il faut lire cette liste table par table, pas le statut global.
Qu’est-ce qui ne devrait pas traverser du tout ?
Les consignes de préparation de Microsoft invitent à profiter de la migration pour réduire la dette technique : archiver l’historique obsolète, réduire les tables de transactions et de journaux surdimensionnées, vérifier que les changements de schéma sont voulus. Le moteur déplacera volontiers tout ce qu’on lui désigne, dans la limite du stockage (80 Go par défaut par tenant, plus une dotation par utilisateur licencié et la capacité supplémentaire achetée).
La bonne question se pose table par table, pas base par base : quelqu’un lira-t-il cette donnée dans le nouveau système, et le nouveau système en a-t-il besoin pour calculer quelque chose ? Une table de journal spécifique qui servait une interface que l’on arrête répond non deux fois. Son extension n’a pas besoin d’exister online, et sa donnée n’a pas besoin de traverser. La convertir quand même, c’est convertir, tester et maintenir un objet pour une donnée que personne n’ouvrira.
La réimplémentation fait ce choix à votre place, et sans nuance : elle apporte l’essentiel et laisse le reste. La migration complète vous laisse le choix, ce qui n’est mieux que si quelqu’un le fait vraiment.
Combien de sociétés, et dans quel ordre ?
Pour un groupe multi-entités, la dimension société compte autant que la dimension table. La migration cloud est optimisée pour des lots de 10 sociétés au plus ; au-delà de 250 sociétés, Microsoft recommande de prévoir des lots plus petits. Les tables communes à la base sont toujours migrées, quelles que soient les sociétés sélectionnées.
La règle qui compte le plus pour un groupe : migrer toutes les sociétés avant le démarrage. Microsoft prévient que déplacer des sociétés dans un tenant déjà en production peut entraîner des pertes de données dans les sociétés déjà démarrées. Un plan qui fait basculer les filiales une par une, après le démarrage de la première, se bat contre l’outil.
Les migrations peuvent se rejouer. La première déplace tout et prend le plus de temps ; les suivantes ne déplacent que ce qui a changé. Si les équipes continuent de travailler dans l’on-premises, il faut au moins une migration supplémentaire avant de saisir dans Business Central online.
La reprise s’arrête-t-elle au démarrage ?
Non, et c’est la partie que presque personne ne budgète. Sur la même base de code, les dossiers de mise à niveau de la solution contiennent douze codeunits dont le seul rôle est de remodeler des données déjà présentes dans Business Central. Certaines passent par le moteur de mise à niveau à l’installation d’une nouvelle version ; d’autres tournent en file d’attente des travaux, lancées une fois qu’une autre table dont elles dépendent est en place. Trois schémas couvrent l’essentiel.
Remplir un champ qui n’existait pas. Un nouveau champ est ajouté à des lignes qui existent déjà. La migration rejoue la même recherche que le code en production utilise désormais, mais seulement pour les enregistrements postérieurs à une date de coupure, et seulement pour le périmètre d’activité concerné. Tout l’historique n’est pas remodelé. C’est une décision, prise dans le code.
Corriger ce que l’ancienne logique a stocké. Une date a été enregistrée comme date de comptabilisation là où la date du document était attendue. Dans le code en production, la correction tient en une modification ; les lignes existantes, elles, portent toujours la mauvaise valeur. La migration recalcule chacune à partir du document validé et ignore celles qui sont déjà justes.
Changer la clé d’une table. Une ancienne table est remplacée par une nouvelle, avec une clé primaire différente, résolue au travers d’une autre table. La migration ne peut tourner qu’une fois cette autre table synchronisée : elle passe donc par une écriture de file d’attente avec un paramètre, pas par le code de mise à niveau. Elle est idempotente : les enregistrements déjà migrés sont ignorés, on peut la relancer sans risque.
La façon dont nous empêchons ces migrations de ne pas tourner en silence est décrite dans notre discipline de mise à jour des extensions AL Business Central. Ici, deux détails comptent pour qui chiffre une reprise.
Comment éviter de perdre des enregistrements sans bruit ?
La migration de changement de clé fait ce que le moteur de migration cloud ne fait pas pour vous à l’échelle de l’enregistrement : elle refuse de se terminer en silence. Chaque enregistrement est migré dans une fonction try. Les échecs sont collectés, les 100 premiers sont listés, les autres comptés, et l’exécution se termine par une seule erreur qui les nomme. Un enregistrement impossible à rapprocher devient une ligne dans un rapport, pas un trou que quelqu’un découvre à la clôture du mois.
Les boucles sur les grosses tables valident par lots, en général tous les 1 000 enregistrements, pour qu’une transaction unique ne verrouille pas toute la table. Même là, il faut lire le code et pas le commentaire : dans l’une des migrations, le commentaire annonce 1 000 et le code valide tous les 10.
Le second détail est plus modeste, et plus fréquent. En mars 2026, une routine générique qui convertit du texte entrant en valeurs de champs typées levait une erreur d’exécution dès que le texte source dépassait la longueur du champ cible. La correction tient en une ligne : couper la valeur à la longueur du champ. L’import continue de tourner. Il coupe aussi de la donnée. Chaque migration comporte des dizaines de ces choix entre échouer et tronquer, et chacun devrait être fait exprès, par quelqu’un qui sait de quel champ il s’agit.
Comment chiffrer le volet données ?
Comme un projet à part entière, dimensionné à partir de la liste des champs, pas du nombre de tables ni de la taille de la base. Notre approche de la migration Dynamics NAV vers Business Central part de la liste des développements qui portent de la donnée, parce que cette liste fixe l’ordre de tout le reste : ce qui est converti en premier, ce qui est testé en premier avec de vraies données, et ce qu’on peut tout simplement laisser derrière.
Si vous instruisez un budget de migration et que la ligne « reprise de données » est un chiffre unique sans liste de tables derrière, le formulaire clarté est le chemin le plus court pour nous poser la question.
FAQ
Peut-on migrer directement de Dynamics NAV vers Business Central online ?
Non. Les deux chemins documentés commencent par une mise à niveau de NAV vers Business Central version 14 on-premises. Ensuite, soit on mène une migration complète après être monté au moins en version 25, soit on utilise l’outil de réimplémentation Business Central 14.
Les utilisateurs et les autorisations sont-ils repris ?
Non. La migration cloud ne reprend ni la plupart des tables système, ni les utilisateurs, ni les autorisations. La sécurité est à reparamétrer online. Les liens et notes attendent dans une table tampon : l’action Migrate Record Links and Notes les transfère, avant le mappage des utilisateurs.
Que devient un champ spécifique si son extension n’est pas installée online ?
Sa donnée ne migre pas. Les données d’extension ne sont répliquées que si l’extension est installée dans l’environnement online et que sa propriété ReplicateData vaut true ; une table dont le schéma ne correspond pas échoue, et la migration continue.
Quand l’outil de réimplémentation Business Central 14 est-il le meilleur choix ?
Quand convertir les développements en extensions n’est pas réaliste et que l’on accepte un outil actuellement en préversion qui repart avec les données de base, les documents ouverts, les soldes d’ouverture, le paramétrage et un sous-ensemble défini de l’historique validé. Les développements hérités et leurs données ne sont pas repris, sauf à étendre l’outil.