Si vous faites encore tourner Dynamics NAV en 2026, vous savez déjà que la question n’est plus « si », mais « quand » et « comment ». Le support principal est terminé. Les correctifs, les mises à jour réglementaires et les nouvelles intégrations ne viennent plus jusqu’à vous. Chaque mois qui passe creuse l’écart entre votre installation actuelle et un ERP moderne — et rend le pont plus cher à construire.
La bonne nouvelle : migrer vers Microsoft Dynamics 365 Business Central reste l’une des voies les plus propres. Vous gardez vos données, vos processus et la mémoire opérationnelle de vos équipes — tout en passant enfin sur une plateforme mise à jour deux fois par an au lieu de tous les cinq ans.
La mauvaise nouvelle : nous avons vu trop de migrations se transformer en cauchemar de 18 mois parce que le projet était cadré comme une « mise à niveau technique » au lieu d’une transformation métier. Cette checklist est celle que nous aimerions voir sur le bureau de chaque DSI avant qu’il ne signe le moindre devis.
Pourquoi migrer maintenant (et pas l’année prochaine)
Trois forces convergent en 2026 :
D’abord, Microsoft a clairement clos le chapitre NAV. Les fenêtres de support étendu pour NAV 2018 et les versions antérieures sont échues ou en passe de l’être, ce qui veut dire : plus de correctifs de sécurité, plus de mises à jour fiscales, et aucune voie d’intégration native avec la stack cloud Microsoft moderne (Power Platform, Copilot, Fabric).
Ensuite, vos concurrents sont déjà passés. Business Central équipe désormais des dizaines de milliers de PME et ETI dans le monde. Les entreprises qui ont migré en 2023-2024 récoltent aujourd’hui les dividendes de productivité : workflows automatisés, tableaux de bord temps réel, copilotes IA qui rédigent des commandes à partir d’e-mails. Si vous exportez encore vers Excel pour sortir un compte de résultat, vous perdez en réactivité.
Enfin, la fenêtre de migration se referme plus vite qu’on ne le croit. Les partenaires BC qualifiés sont réservés plusieurs mois à l’avance. Attendre encore un an, ce n’est pas seulement un an de stagnation — c’est une file d’attente plus longue et des taux qui montent.
Les 7 phases d’une migration NAV → BC réussie
Une migration propre n’est pas un saut unique. C’est une séquence de sept phases, chacune avec ses propres critères de réussite. En sauter une, c’est le payer au go-live.
Phase 1 — Découverte et audit (2 à 4 semaines)
Avant que quiconque ne touche au code, il faut un inventaire clair : version actuelle de NAV, liste des objets personnalisés (objets de base modifiés et add-ons), intégrations avec les systèmes tiers, volumétrie par table, et cartographie des processus métier qui tournent réellement sur NAV aujourd’hui versus ceux qui ont dérivé vers Excel.
Livrable : un rapport d’audit écrit et une liste de décisions « conserver / redésigner / supprimer » pour chaque personnalisation.
Phase 2 — Architecture cible (2 semaines)
Choisir le modèle de déploiement (Online vs On-premises), les licences (Essentials vs Premium, utilisateurs nommés) et la localisation. Mapper chaque objet personnalisé NAV vers son équivalent BC : fonctionnalité standard, extension AppSource, ou extension AL sur mesure. C’est ici qu’on tue la dette technique — la plupart des personnalisations NAV de 2010 sont aujourd’hui standard dans BC.
Livrable : un document d’architecture cible et un chiffrage de licences.
Phase 3 — Nettoyage des données (4 à 8 semaines, en parallèle)
C’est la phase que tout le monde sous-estime. Doublons fournisseurs, clients avec trois versions du même nom, articles aux références obsolètes, documents ouverts depuis 2014 — tout doit être nettoyé dans NAV avant la migration, pas après.
Livrable : un gel des données de référence avec un rapport qualité (% de complétude sur les champs clés, détection de doublons, transactions orphelines).
Phase 4 — Conversion du code (6 à 12 semaines)
Le code C/AL de NAV ne tourne pas tel quel dans Business Central. Il doit être converti en extensions AL. Un bon partenaire utilise les outils officiels Microsoft comme point de départ, puis refactore tout ce qui était un « hack » en extension propre qui survit aux mises à jour BC suivantes.
Livrable : extensions AL déployées dans un environnement sandbox, avec un plan de tests de non-régression.
Phase 5 — Migration des données et run parallèle (4 à 6 semaines)
Les données de référence migrent en premier, puis les transactions ouvertes, puis l’historique clôturé (ou un sous-ensemble). Le système tourne en parallèle avec NAV pendant au moins un cycle complet de clôture, pour que la finance puisse comparer les chiffres.
Livrable : bilans réconciliés à la date de cutover, signés par le DAF.
Phase 6 — Formation et conduite du changement (3 à 6 semaines, en chevauchement)
L’interface de BC est différente de celle de NAV. Les power users ont besoin d’1 à 2 jours de formation pratique. Les utilisateurs finaux ont besoin de sessions ciblées sur leurs workflows spécifiques. Ne jamais sauter cette phase — c’est la différence entre adoption et explosion du help desk en semaine un.
Livrable : super-users formés dans chaque service, fiches réflexes écrites, base de connaissances.
Phase 7 — Go-live et stabilisation (2 à 4 semaines)
Geler NAV. Bascule durant un week-end à faible activité. Le partenaire est sur site (ou d’astreinte) les deux premières semaines. Tracer chaque incident, même mineur — les motifs apparaissent vite.
Livrable : un rapport de stabilisation à 30 jours avec la liste des incidents résolus et le backlog restant.
Les 5 pièges qui font dérailler une migration NAV → BC
Piège 1 — Reprendre toutes les personnalisations telles quelles
La plus grande erreur : migrer vos personnalisations de 2012 « as-is ». La plupart sont aujourd’hui des fonctionnalités standard de BC (projets, dimensions, attributs articles, pièces jointes). Les forcer en extensions personnalisées, c’est payer pour ce qui est gratuit et casser à chaque mise à jour BC. Auditer d’abord. Couper sans pitié.
Piège 2 — Sous-estimer la qualité des données
Les ordures dans NAV deviennent des ordures dans BC, en plus rapide et plus visible. Prévoir 20 à 30 % du budget projet pour le travail sur les données. Si votre partenaire ne parle pas de data cleansing en semaine un, ce n’est pas le bon partenaire.
Piège 3 — La traiter comme un projet IT
Une migration est un projet métier avec un volet IT. Si la finance, le commerce et les opérations ne sont pas dans le comité de pilotage, votre go-live révélera des décalages entre les processus configurés et la réalité du terrain.
Piège 4 — Sauter le run parallèle
« On va basculer le week-end, ça ira », c’est la méthode garantie pour avoir un DAF qui ne peut pas clôturer son mois. Toujours faire tourner au moins une clôture complète en parallèle.
Piège 5 — Choisir au prix seul
Le devis le moins cher est presque toujours le plus cher à l’arrivée. Cherchez des partenaires qui challengent vos hypothèses, posent des questions inconfortables et vous montrent des références au profil et à la taille similaires.
Coût et calendrier réalistes en 2026
Pour une entreprise de taille intermédiaire (50 à 250 utilisateurs, une ou deux entités légales, personnalisation modérée), comptez :
- Délai : 6 à 12 mois de bout en bout, selon le volume de données et la profondeur de personnalisation.
- Coût d’implémentation : 80 000 à 350 000 euros, hors licences.
- Licences annuelles : 70 à 100 euros par utilisateur et par mois pour Essentials, 100 à 130 pour Premium.
- Effort interne : prévoir 0,5 à 1 ETP côté client pendant toute la durée du projet.
Si un partenaire vous chiffre 30 000 euros pour une migration de 100 utilisateurs, fuyez. Soit il ne comprend pas le périmètre, soit il prévoit de facturer le reste en avenants.
Comment choisir le bon partenaire Business Central
Douze questions à poser à tout partenaire avant de signer :
- Combien de migrations NAV → BC avez-vous livrées ces 24 derniers mois ?
- Puis-je parler à deux références au profil similaire au mien ?
- Qui exactement va travailler sur mon projet, et quelle est leur séniorité ?
- Quelle est votre approche pour traiter les personnalisations existantes ?
- Comment gérez-vous le nettoyage des données ?
- À quoi ressemble un plan de projet type pour une entreprise de ma taille ?
- Comment facturez-vous : forfait, régie, ou hybride ?
- Qu’est-ce qui est inclus dans le prix, et qu’est-ce qui déclenche un avenant ?
- Comment gérez-vous les mises à jour semestrielles de BC après go-live ?
- Que se passe-t-il si on découvre des changements de périmètre en cours de projet ?
- Saurez-vous nous dire non quand nos demandes n’ont pas de sens ?
- Montrez-moi une extension AL que vous avez écrite — je veux voir la qualité du code.
La douzième question est celle que la plupart des prospects oublient. La qualité du code est la différence entre une extension qui survit cinq ans et une qui casse à la prochaine release BC.
L’approche Asio Services : ERP propre, sans raccourcis
Nous pensons que la plupart des problèmes ERP sont des problèmes de cause racine, pas des problèmes de symptômes. Un bug dans un rapport personnalisé ne porte presque jamais sur le rapport — il révèle un processus qui n’a jamais été correctement défini. Une routine de validation lente n’est presque jamais un problème de performance — c’est une personnalisation qui aurait dû être standard.
C’est pour ça que nous commençons chaque migration par une phase de découverte qui regarde les processus avant le code. Nous vous dirons quand une personnalisation ne vaut pas la peine d’être conservée. Nous vous dirons quand vos données actuelles sont trop sales pour être migrées. Nous dirons non quand c’est la bonne réponse.
Si c’est le partenaire que vous cherchez, on serait ravis d’échanger.
→ Réservez un appel découverte gratuit avec Asio Services. Nous analysons votre installation NAV actuelle et vous disons, en français clair, à quoi ressemblerait votre migration.
