Fin du support de Dynamics NAV 2018 au 11 janvier 2028 : que faire d'ici là

Le 11 janvier 2028, Microsoft met fin au support étendu de Dynamics NAV 2018, la dernière version de NAV qu'il a publiée. Pour NAV 2017, c'est un an plus tôt, le 11 janvier 2027. Aucune de ces deux dates n'éteint quoi que ce soit. Microsoft n'a pas dit que NAV cesserait de fonctionner, et une licence perpétuelle continue de tourner. Ce qui s'arrête, ce sont les mises à jour de sécurité et le support payant.

Les mises à jour fiscales et légales se sont arrêtées plus tôt. Elles relèvent du support standard, qui a pris fin pour NAV 2018 le 10 janvier 2023. La fin de vie de NAV 2018 n'est donc pas une falaise en 2028. Les mises à jour légales ont cessé il y a presque quatre ans, les correctifs de sécurité cessent dans 14 mois, et le régime des licences change en 2031.

Ce guide s'adresse aux responsables financiers et informatiques des industriels, distributeurs et sociétés de services de taille intermédiaire des pays germanophones, des pays nordiques, du Benelux et du Royaume-Uni, qui font tourner une version de NAV comprise entre 2009 et 2018 avec des années de développements spécifiques, souvent réalisés par un partenaire qui a disparu depuis.

Ce qui prend fin, et quand

NAV 2018 relève de la politique de cycle de vie fixe de Microsoft, et ses dates figurent sur la page de cycle de vie de NAV 2018.

Le support étendu, la phase dans laquelle se trouve NAV 2018 depuis janvier 2023, comprend les mises à jour de sécurité et le support payant. Après le 11 janvier 2028, les mises à jour de sécurité s'arrêtent. La politique n'autorise un support payant au-delà de cette date que dans le cadre du programme de mises à jour de sécurité étendues (ESU), et Microsoft ne propose pas de mises à jour de sécurité étendues pour NAV.

Les mises à jour fiscales et réglementaires exigent un Enhancement Plan actif et relèvent du support standard. La liste des mises à jour cumulatives de NAV 2018 publiée par Microsoft s'arrête à la Cumulative Update 60, de janvier 2023. Depuis, aucune version locale de NAV 2018 n'a reçu de nouvelles fonctionnalités réglementaires de Microsoft : le support étendu de NAV 2018 ne les inclut pas.

Dans son billet de juillet 2026 sur les options de migration depuis NAV, Microsoft détaille les changements de licences du 30 avril 2031 et invite les clients NAV à « commencer dès maintenant à évaluer leur stratégie ERP à long terme ».

La plateforme sous-jacente

La configuration système requise de NAV 2018 s'arrête à SQL Server 2019 et Windows Server 2022. SQL Server 2014 et 2016 sont déjà sortis du support étendu, et Windows Server 2016 suit le 12 janvier 2027. Sur SQL Server 2019 et Windows Server 2022, la base de données reste prise en charge jusqu'au 8 janvier 2030 et le système d'exploitation jusqu'au 14 octobre 2031. Pas l'ERP qui tourne dessus.

Les évolutions légales que NAV ne recevra pas

La dernière mise à jour réglementaire de Microsoft pour NAV 2018 est sortie en janvier 2023, avant qu'aucune de ces règles n'entre en vigueur.

• Allemagne. Pour les ventes nationales entre entreprises, la facture électronique (E-Rechnung) est la règle depuis le 1er janvier 2025, et toute entreprise doit pouvoir en recevoir une (une boîte e-mail suffit), selon le ministère fédéral des Finances. Les autres factures restent autorisées jusqu'au 31 décembre 2026, ou jusqu'à fin 2027 pour les émetteurs dont le chiffre d'affaires de l'année précédente n'a pas dépassé 800 000 €. XRechnung et ZUGFeRD à partir de la version 2.0.1 sont acceptés, sauf les profils MINIMUM et BASIC-WL.
• Belgique. Depuis le 1er janvier 2026, toute entreprise belge assujettie à la TVA doit utiliser des factures électroniques structurées, selon le portail fédéral de la facturation électronique. La documentation Business Central de Microsoft pour la Belgique désigne le réseau Peppol comme canal.
• Pologne. Le KSeF est devenu obligatoire le 1er février 2026 pour les entreprises dont les ventes 2024 dépassaient 200 millions de zlotys, et le 1er avril 2026 pour les autres, avec une exception jusqu'au 31 décembre 2026 lorsque le montant mensuel des factures est faible. La Pologne ne figure pas parmi les versions locales de NAV 2018 publiées par Microsoft : un NAV polonais n'a donc jamais reçu sa localisation par les mises à jour NAV 2018 de Microsoft.

La localisation allemande de Business Central indique comme disponible la facturation XRechnung, ZUGFeRD et Peppol, et la localisation belge la facturation via un point d'accès Peppol. Pour les autres pays, vérifiez avec votre conseiller fiscal les règles en vigueur et confrontez-les à ce que votre NAV sait envoyer et recevoir.

Votre version et votre chemin de mise à niveau

La page des chemins de mise à niveau de Microsoft fixe le chemin depuis NAV 2015, 2016, 2017 ou 2018 en trois étapes : Business Central Spring 2019 (version 14), puis Business Central 2024 release wave 2 (version 25), puis la version actuelle, Business Central 2026 release wave 2 (version 29). Une phrase de cette page décide de l'essentiel du budget : « Ce chemin exige que vous convertissiez votre application de C/AL en AL. »

Depuis NAV 2009, le chemin qui passe par NAV 2013 passe aussi par NAV 2018. Quel que soit le nom que votre équipe donne au système, une migration de Navision vers Business Central depuis ces versions est une chaîne de mises à niveau.

La version 14 est la dernière à prendre en charge C/AL, et Txt2Al, l'outil qui convertit les objets C/AL en AL, n'est livré qu'avec elle. La version 14 elle-même est sortie du support en octobre 2025, et les nouveaux clients ne peuvent pas l'utiliser en production : une étape intermédiaire, pas un endroit où s'arrêter. Avec la version 15, AL a remplacé C/AL et Business Central ne repose plus que sur des extensions. La version 25 est une étape obligatoire, car depuis la version 26 une mise à niveau directe de la version 14 vers la dernière version n'est pas prise en charge.

Tous les chemins, y compris ceux qui aboutissent dans le cloud, passent par Business Central 14 sur site.

Où se trouve réellement le travail

L'effort croît avec ce qui a été construit dans le système, et les spécifiques NAV étaient généralement développés directement dans les objets de Microsoft.

Les développements spécifiques

Dans NAV, un partenaire réalisait les spécifiques en modifiant le code C/AL de Microsoft : un champ ajouté à la table client, quelques lignes dans la routine de validation. Business Central attend que l'application de base reste telle que livrée, avec vos modifications à côté, dans des extensions qui réagissent à des événements.

Txt2Al convertit la syntaxe, pas la conception. Microsoft décrit la création de ces extensions comme « la première étape, et la plus grande » de la mise à niveau. Son guide de migration des spécifiques NAV décrit le traitement : les tables spécifiques deviennent des tables AL, les champs spécifiques ajoutés aux tables standard deviennent des extensions de table (table extensions) dont les données sont transférées, les modifications dans les codeunits de Microsoft deviennent des abonnés aux événements (event subscribers), et les XMLports et les requêtes sont reconstruits. Les personnalisations faites dans le client Windows sont perdues.

Sur site, Microsoft autorise encore une application de base modifiée dans le code, même s'il recommande vivement les extensions. Son guide des licences sur site (édition de juin 2023) indique que les clients qui viennent de NAV avec des spécifiques non compatibles « universal code » (code universel) doivent acquérir en plus la licence d'un module universal code. En ligne, tout doit être une extension.

Comptez les objets standard modifiés, les tables et les champs spécifiques, et ceux que quelqu'un utilise encore.

Les états

Chaque état C/AL est reconstruit en AL, sous forme de nouvel état ou d'extension d'état. Les mises en page survivent : RDL et Word sont tous deux pris en charge, et Microsoft recommande Word pour les états de documents, car RDL peut être plus lent. Listez les états spécifiques et retirez ceux que personne n'exécute.

Les add-ins .NET

L'interopérabilité .NET n'existe que sur site. En ligne, Microsoft oriente plutôt vers les control add-ins, Azure Functions ou des API externes. Sur site, les add-ins compilés avec .NET Framework ont cessé de fonctionner avec la version 22 et doivent passer à .NET Standard. Listez chaque composant, ce qu'il fait, et si son fournisseur existe encore.

Intégrations et services web

À partir de la version 29, une page de Microsoft ne peut plus être publiée comme point de terminaison SOAP ; à partir de la version 30, elle ne peut plus l'être comme point de terminaison OData non plus. La solution de Microsoft pour SOAP est une copie de la page dans votre propre extension. En ligne, les intégrations s'authentifient uniquement par OAuth2. Une boutique en ligne, une liaison EDI ou un système d'entrepôt qui appelle des pages NAV standard en SOAP ne survivra donc pas tel quel à la migration. Construisez l'inventaire à partir du système lui-même (services web publiés, tâches planifiées, fichiers lus et écrits), avec un responsable et une décision pour chaque élément.

Le client Windows

Le client Windows de NAV a été supprimé dans la version 15. Les utilisateurs passent au navigateur, aux applications mobiles ou à une application de bureau. L'impression par programme a disparu avec lui : tout ce que NAV imprime sans qu'un utilisateur clique sur Imprimer doit donc passer par une autre voie. Prévoyez aussi la formation : chaque écran change.

Les données

Les données des tables modifiées dans le code ne peuvent atteindre Business Central en ligne que si des extensions les prennent en charge des deux côtés. Microsoft demande au moins une migration à blanc complète dans un environnement sandbox avant la bascule. Prévoyez-en plusieurs. Écrivez la migration et ses contrôles sous forme de code que vous pouvez relancer sur une copie fraîche de la production, en comparant à chaque fois les soldes et les postes ouverts. La finance valide quand les chiffres concordent, pas quand le traitement se termine.

En ligne ou sur site

Tranchez cette question avant que quiconque convertisse du code : c'est elle qui décide de ce qui survit. Microsoft tient la liste des fonctionnalités non disponibles sur site.

En ligne. L'outil de migration vers le cloud de Microsoft fonctionne à partir de la version 25 sur site ou d'une version ultérieure, sur SQL Server 2016 ou ultérieur. Une mise à niveau complète de NAV vers Business Central dans le cloud, c'est donc NAV, puis la version 14 et la version 25 sur site, puis la migration. L'alternative, l'outil de réimplémentation Business Central 14, ne transfère vers le cloud que les données de référence, les soldes d'ouverture et le paramétrage de la version 14. Il est en préversion, et Microsoft indique que les fonctionnalités en préversion « ne sont pas destinées à une utilisation en production ».

Bridge to Cloud 3. L'annonce de Microsoft aux partenaires fixe la période d'inscription du 1er janvier 2026 au 31 décembre 2027 : 30 % de remise sur le prix catalogue commercial, pour une durée fixe de trois ans non renouvelable, via un Cloud Solution Provider. L'offre s'applique aux licences sur site achetées avant le 1er septembre 2024 avec un Enhancement Plan actif, et uniquement à un produit en ligne dont vous n'avez jamais eu la licence. Le site partenaires de Microsoft mentionne aussi un bon de migration (voucher) Business Central, dont les conditions ne sont pas publiques.

Sur site. Chaque version est prise en charge pendant environ 18 mois (la version 29, sortie en octobre 2026, jusqu'en avril 2028) : rester dans le support suppose donc une mise à niveau à ce rythme, avec vos extensions retestées à chaque fois. Depuis avril 2025, les nouveaux clients sur site ne peuvent acheter que des abonnements. Pour les clients NAV qui transfèrent leurs licences perpétuelles, un community manager de Microsoft a écrit en février 2025 que les politiques de transition restaient inchangées. Nous n'avons trouvé aucune date de fin fixée par Microsoft pour ce droit : obtenez donc vos conditions par écrit.

Un cadre de décision

Quatre voies sont réalistes.

Mettre à niveau sur site vers la version actuelle. Version 14, puis 25, puis la version actuelle, sur vos propres serveurs. Cela convient à une entreprise qui a des add-ins .NET ou des intégrations qu'elle ne peut pas encore remplacer. Vous acceptez une mise à niveau environ tous les 18 mois, et un module de licence si du code reste dans l'application de base.

Mettre à niveau, puis passer en ligne. Le même chemin jusqu'à la version 25, puis l'outil de migration vers le cloud. Chaque spécifique devient une extension et chaque add-in .NET est remplacé : c'est ici que le travail de conversion est le plus lourd. Si vous êtes éligible à Bridge to Cloud 3, son échéance du 31 décembre 2027 tombe en plein projet.

Repartir de zéro dans Business Central en ligne. Reprenez les données de référence, les soldes d'ouverture et le paramétrage, gardez l'ancien système pour consultation, et ne reconstruisez que les spécifiques dont vous avez encore besoin. L'outil de Microsoft pour cela est en préversion et part de la version 14. Une entreprise qui choisit un autre ERP fait face à peu près au même travail sur les données et les intégrations.

Rester sur NAV pour une durée définie. Il continue de tourner. À partir du 11 janvier 2028, il ne reçoit plus de correctifs de sécurité, et chaque nouveau format de facture électronique est un développement à votre charge. Cela ne tient qu'avec une personne nommément désignée qui en assure la maintenance, un système tenu à l'écart de l'Internet public, et une date de fin.

Les prochains mois, quelle que soit la voie choisie

Il reste 14 mois avant la fin du support de NAV 2018. Si votre exercice se clôt en décembre, une bascule début janvier tombe en pleine clôture annuelle : l'objectif réaliste est donc un démarrage à l'automne 2027. Sur NAV 2017, l'échéance est dans deux mois : vous tournerez sans support pendant une partie du projet, alors faites en sorte que cette partie soit courte.

D'ici fin mars 2027 :

1. Confirmez votre point de départ : version de NAV, versions de SQL Server et de Windows Server, et si votre Enhancement Plan est actif. Bridge to Cloud 3 et la transition des licences sur site en dépendent tous les deux.
2. Mettez le code en sécurité. Exportez les objets C/AL et placez-les sous gestion de versions, surtout si le partenaire qui les a écrits a disparu.
3. Comptez les spécifiques, et lesquels sont utilisés. Un décompte, pas une impression.
4. Construisez l'inventaire des intégrations : chaque service web, échange de fichiers et add-in .NET, avec un responsable et une décision.
5. Vérifiez vos obligations de facturation électronique dans chaque pays depuis lequel vous facturez.
6. Choisissez entre en ligne et sur site avant que la conversion du code commence.
7. Réservez les capacités : le partenaire, vos propres équipes finance et informatique pour les tests, et une fenêtre de bascule.

En remontant depuis un démarrage à l'automne 2027 : migrations à blanc et tests utilisateurs en été, développement des extensions et reprise des intégrations au printemps, analyse et décisions cet hiver.

Où trouver de l'aide

Ce qui doit tenir pendant la migration, c'est l'activité : des factures au format que la loi exige désormais, et un entrepôt qui continue d'expédier. Nous travaillons aux côtés de votre partenaire Business Central, ou directement avec vous quand le partenaire qui a construit votre NAV a disparu, sur la conversion des spécifiques C/AL en extensions AL, la reconstruction des intégrations et des états, le code de migration des données et son rapprochement, et les applications autour de NAV qui doivent survivre à la migration. Ce travail est décrit sur notre page de modernisation d'ERP, et la maintenance de systèmes anciens couvre les systèmes qui restent en place jusqu'à votre migration. Si vous voulez que vos spécifiques et vos intégrations soient comptés avant de signer un projet de mise à niveau, écrivez à office@c9group.dev.