Migrer de Dynamics NAV vers Business Central : ce qu’il advient de l’intégration

August 21, 2026 · Beate Thomsen · Intégration de données

Passer de Dynamics NAV à Business Central ne signifie pas automatiquement reconstruire votre intégration, et ce qui se passe dépend de la façon dont elle a été construite. Selon la configuration, l’intégration devra peut-être être reconstruite, reconfigurée ou adaptée. Cet article présente un guide de migration en six étapes pour vous aider à passer à Business Central sans mettre votre activité en danger.

Passer à un nouvel ERP peut ressembler à un projet d’envergure, surtout lorsque votre CRM et vos autres systèmes dépendent de votre intégration Dynamics NAV existante. Mais ce passage ne signifie pas forcément repartir de zéro.

Lors de notre récent webinaire, Beate H. Thomsen et Andreea Arseni ont examiné ce qu’il advient de votre intégration lors du passage de Dynamics NAV à Business Central, ce qui change entre on-premise et cloud, et comment aborder la migration de manière maîtrisée.

Au sommaire de cet article :

• Que devient votre intégration lors du passage à Business Central ?
• Qu’est-ce qui change avec le passage à Business Central Cloud ?
• Comment garder le contrôle de votre migration ?
• Télécharger le guide de mise à niveau en 6 étapes
  

 

 

 

Que devient votre intégration lors du passage à Business Central ?

Passer de Dynamics NAV à Business Central ne signifie pas automatiquement reconstruire votre intégration.

Tout dépend de la façon dont l’intégration a été construite et dont elle se connecte à Dynamics NAV. Trois scénarios sont possibles : reconstruire, reconfigurer ou adapter.

Reconstruire

Si votre intégration est liée à une version précise de Dynamics NAV, lit directement les tables NAV ou embarque les mappings de champs et les règles métier dans le connecteur, certaines de ses parties devront peut-être être reconstruites.

Une question utile à se poser : où vos mappings de champs et vos règles métier sont-ils documentés ?

Si la réponse est simplement « c’est dans le code », vous vous dirigez peut-être vers une reconstruction.

Reconfigurer

Si vos mappings et votre logique métier sont gérés séparément de l’ERP, par exemple dans une plateforme d’intégration, il suffira peut-être de reconfigurer l’intégration existante.

Cela peut impliquer de rediriger la connexion, de configurer l’authentification et de remapper les champs qui ont changé.

Dans ce cas, la migration s’apparente bien plus à un travail de configuration qu’à une reconstruction complète.

Adapter

Certaines intégrations utilisent du code personnalisé qui s’appuie sur les services web NAV. Dans ces cas, la connexion peut être conservée, mais le code lié à une version d’API ou à un schéma NAV spécifique devra peut-être être adapté.

Cela va au-delà d’un simple changement de configuration, mais cela ne signifie pas forcément reconstruire toute l’intégration.

L’essentiel à retenir : ce qu’il advient de votre intégration dépend de la façon dont elle a été construite, et non simplement de l’âge de votre système NAV.

Qu’est-ce qui change avec le passage à Business Central Cloud ?

La conception de l’intégration ne change pas forcément, mais la manière de vous connecter à Business Central, si.

Davantage d’éléments peuvent être conservés que vous ne le pensez. Le périmètre de votre intégration, les flux de données, les règles de correspondance, la déduplication, la logique de transformation, la gestion des conflits et la fréquence de synchronisation ne changent pas automatiquement du fait de votre passage à Business Central.

Les principales différences entre Dynamics NAV, Business Central on-premise et Business Central Cloud portent sur :

• La méthode d’accès
• L’authentification
• L’emplacement du moteur d’intégration
• Les champs personnalisés
• Le volume et le débit
• Les environnements de test

Par exemple, passer à Business Central Cloud peut impliquer de mettre à jour l’authentification, d’exposer les champs personnalisés via le nouvel environnement et de tenir compte de la limitation des requêtes (throttling) et du traitement par lots.

En résumé :

Le cloud change la manière dont vous vous connectez, pas ce que vous connectez.

Comment garder le contrôle de votre migration ?

Une fois que vous savez ce que votre intégration doit devenir, le défi suivant consiste à passer au nouveau système sans tout miser sur un seul grand week-end de bascule.

L’approche en six étapes présentée lors du webinaire est la suivante :

1. Cartographier et définir le périmètre

Décidez de ce qui migre, de ce qui reste dans l’ancien système en tant qu’historique, et convenez de la date butoir.

2. Nettoyer à la source

Dédupliquez et corrigez vos données dans l’ancien système avant de les migrer.

3. Faire un essai à blanc sur un sous-ensemble

Testez une partie représentative de la migration et détectez les problèmes tant qu’ils sont encore plus faciles à corriger.

4. Faire tourner l’ancien et le nouveau système en parallèle

Gardez les deux systèmes actifs et à jour grâce à une synchronisation bidirectionnelle. Résultat : aucun gel des données, aucun travail perdu.

5. Valider et rapprocher

Convenez de vos critères d’acceptation avant de commencer et utilisez-les pour vérifier les résultats.

6. Basculer selon vos conditions

Désactivez l’ancien système une fois que le nouveau a fait ses preuves, plutôt que simplement parce qu’une date a été fixée des mois auparavant.

L’objectif est simple : trouver les problèmes pendant l’essai à blanc, pas le week-end du go-live.

Téléchargez le guide de mise à niveau en 6 étapes & les ressources du webinaire

Vous souhaitez l’approche complète, avec une liste de contrôle pour chaque étape ?

Le guide de mise à niveau en 6 étapes couvre tout, de la cartographie et du nettoyage de vos données jusqu’à la bascule selon vos conditions, en passant par l’exploitation des deux systèmes en parallèle et la validation des résultats.

Téléchargez les supports du webinaire pour retrouver tous les enseignements au même endroit.

Si vous préparez une migration de Dynamics NAV vers Business Central et souhaitez discuter de votre intégration, contactez-nous pour une évaluation →

Questions fréquentes

Que deviennent nos intégrations existantes lorsque nous passons de NAV à Business Central ?

Tout dépend de ce à quoi l’intégration est liée. Si elle est liée à une version, à un schéma SQL ou à un endpoint précis, il faut la reconstruire. Si elle est liée à une définition de connexion dont les mappings vous appartiennent, il suffit de la reconfigurer : vous la pointez vers le nouveau système et les mappings sont conservés. La propre checklist de migration vers le cloud de Microsoft place la reconnexion des intégrations à l’étape 7 sur 8, ce qui montre comment le secteur la considère aujourd’hui. NAV 2016 et les versions ultérieures utilisent le même type de connexion Rapidi que Business Central, si bien que pour les clients Rapidi, il s’agit d’une reconnexion et non d’une reconstruction.

Que deviennent les champs personnalisés que nous avons ajoutés à NAV il y a des années ?

C’est la question qui décide si votre intégration survivra, et elle est généralement posée trop tard. Il existe trois cas, et vous devez savoir dans lequel se trouve chaque champ avant que le budget ne soit fixé : le champ existe déjà en standard dans Business Central, le champ est repris dans le cadre d’une extension, ou le champ n’existe pas et quelqu’un doit décider s’il doit exister. Auditez vos champs personnalisés avant de définir le périmètre du projet, pas en cours de route.

Pouvons-nous faire tourner NAV et Business Central en parallèle pendant la transition ?

Oui, et c’est la manière la plus sereine de procéder, mais pas avec l’outil de migration vers le cloud de Microsoft. Cet outil effectue une réplication unidirectionnelle vers le nouvel environnement, et la documentation de Microsoft elle-même avertit qu’à chaque exécution de la migration, les modifications apportées dans la société cible en ligne sont écrasées. Il déplace les données ; il ne permet pas aux deux systèmes d’être actifs. Fonctionner véritablement en parallèle suppose une synchronisation bidirectionnelle entre les deux systèmes, avec une date butoir convenue, une phase de validation et une bascule à la date de votre choix.

Pouvons-nous passer directement de Dynamics NAV à Business Central online ?

Non. Le parcours prévu par Microsoft pour NAV 2015 à 2018 comporte trois étapes : Business Central version 14 on-premise, puis Business Central on-premise version 25 ou ultérieure, puis Business Central online. Depuis NAV 2013, il en faut quatre, et depuis NAV 2009, cinq. Dynamics GP et SL migrent directement à partir des versions 2015, mais pas NAV. Chaque étape est un point où une intégration liée à une version, à un endpoint ou à un schéma doit à nouveau être traitée.

Nos personnalisations ont été développées en C/AL. Que deviennent-elles ?

Tout ce qui comporte des personnalisations de code doit être converti en extensions AL avant de pouvoir passer en ligne. Microsoft indique explicitement que les données des tables comportant des personnalisations de code ne peuvent pas être reprises depuis Dynamics NAV, à moins que ces personnalisations ne soient prises en charge par des extensions installées à la fois on-premise et en ligne. L’alternative est l’outil de réimplémentation de Business Central 14, qui ne migre que les données de base, les soldes d’ouverture et le paramétrage, et ne reprend ni l’historique des transactions ni les anciennes personnalisations. Si vos personnalisations sont déjà des extensions, les mises à niveau relèvent de la routine. La dette concerne spécifiquement le code antérieur aux extensions.

Nous utilisons la synchronisation standard entre Business Central et Dynamics 365 Sales. Continue-t-elle simplement de fonctionner ?

Non. Microsoft fait de la reconfiguration de la connexion Dynamics 365 Sales une étape à part entière après la migration vers le cloud : vous devez configurer à nouveau la connexion. La reconnexion cache en outre un piège. La page de Microsoft consacrée à l’action Use Default Synchronization Setup indique que tous les mappings personnalisés seront écrasés ; si vous avez adapté la synchronisation standard, même légèrement, une simple reconnexion de routine peut donc effacer ces adaptations. Documentez vos mappings avant que quiconque n’y touche.

Y a-t-il des limites d’API que nous atteindrons une fois dans le cloud ?

Oui, et elles sont publiées. Par utilisateur, sur une fenêtre glissante de cinq minutes, 6 000 requêtes OData ou SOAP. Par environnement, 600 requêtes par minute en production et 300 en sandbox, cinq requêtes simultanées, cent connexions, quatre-vingt-quinze en file d’attente et un délai d’expiration de huit minutes par opération. Au-delà de la limite, vous recevez une réponse 429 avec un en-tête Retry-After. Le détail que la plupart des gens négligent, c’est que Microsoft avertit qu’une intégration exécutée sous un seul utilisateur ou un seul principal de service atteindra assez vite la limite par utilisateur, et la réponse documentée consiste à répartir la charge sur plusieurs principaux de service. En pratique, il s’agit d’un détail de conception plutôt que d’une crise.

Le support de NAV 2017 prend fin en janvier 2027. Est-il déjà trop tard pour bien planifier ?

Non, mais le délai est court, et cela doit changer la forme du plan plutôt que son ambition. Le support de NAV 2016 a expiré le 14 avril 2026, celui de NAV 2017 prend fin le 11 janvier 2027 et celui de NAV 2018 le 11 janvier 2028. Face à un délai court, les équipes expérimentées ne compressent pas l’ensemble du projet, elles raccourcissent le premier go-live : la finance plus un domaine opérationnel, en production en moins d’un trimestre, et le reste sous forme de feuille de route datée. C’est le maintien des intégrations existantes pendant toute la transition qui rend ce découpage possible.