Fin du support de NAV 2017 le 11 janvier 2027 : les étapes techniques vers Business Central

Dynamics NAV 2017 suit la politique de cycle de vie fixe de Microsoft, et son support prolongé prend fin le 11 janvier 2027 (la page Lifecycle de Microsoft fixe la coupure au 12 janvier, 6 h 59, heure du Pacifique). Ensuite : plus de mises à jour de sécurité, plus de support de Microsoft. NAV 2018, la dernière version de NAV, suit un an plus tard, en janvier 2028.

Si vous avez des clients sur NAV 2017, voici à quoi ressemble le chemin vers Business Central, et où se trouve vraiment le travail.

Le chemin passe par la version 14

On ne saute pas directement de NAV 2017 (version 10) au Business Central d'aujourd'hui. Les chemins de mise à niveau documentés par Microsoft passent par Business Central 2019 release wave 1 (version 14), la dernière version qui roule encore du C/AL :

1. Mettre NAV 2017 à niveau vers la version 14. Les objets C/AL personnalisés suivent ; c'est le dernier arrêt où ils fonctionnent tels quels.
2. Transformer les personnalisations en extensions AL, ou les remplacer par des fonctions standard. Les données qui vivent dans des champs ajoutés aux tables de base doivent se retrouver dans les tables de l'extension pendant la mise à niveau.
3. Monter jusqu'à la version visée. Sur place (on-premises), le chemin passe maintenant par 2024 release wave 2 (version 25) avant les versions actuelles. Pour Business Central en ligne, on part d'une version sur place supportée avec l'outil de migration infonuagique, et seules les données des tables standard ou d'extensions suivent : les données des tables modifiées par du code personnalisé, non.

Les étapes exactes changent à chaque version : vérifiez les chemins de mise à niveau et la matrice de compatibilité de Microsoft pour votre version cible avant de planifier.

Où est le travail

Les étapes mécaniques (les mises à niveau de base de données, Txt2Al qui transforme le C/AL en syntaxe AL) sont documentées et assez prévisibles. Le temps passe à trois endroits.

Les personnalisations. Chacune reçoit la même question : Business Central le fait-il maintenant en standard? Si oui, on prend le standard. Sinon, on la reconstruit en extension, branchée sur des événements plutôt que sur du code de base modifié. J'en parle dans un article précédent sur les personnalisations NAV.

Les rapports et les documents. Les rapports personnalisés sont convertis avec le reste du code C/AL, et leurs mises en page RDLC peuvent souvent être réutilisées. Mais une copie modifiée d'un rapport standard (la facture, presque toujours) gagne à être refaite en extension de rapport sur le rapport standard d'aujourd'hui, pour continuer de recevoir les correctifs de Microsoft. À savoir sur les versions actuelles : depuis 2026 release wave 1, les mises en page de rapport ont un statut, et une mise en page importée commence en brouillon et ne s'imprime pas tant qu'elle n'est pas approuvée.

Les intégrations. Les intégrations NAV 2017, ce sont souvent des fichiers déposés dans un dossier, des services web SOAP, des files d'attente de travaux sur le NAV Application Server, et parfois du SQL direct. En ligne, le SQL direct n'existe plus, et le reste gagne à être refait sur les API. Pour ce qui roule en dehors de Business Central, les Azure Functions sont un bon endroit.

Le fonctionnel et le développement se séparent bien

Ces projets demandent deux expertises. Le côté fonctionnel revoit les processus (réception, production, entrepôt, facturation), anime les ateliers fit-gap face au Business Central standard et forme les utilisateurs. Le côté développement construit ce que le fit-gap trouve manquant : extensions, rapports et documents, intégrations, migration des données, et les tests.

Si vous êtes consultant fonctionnel, ou partenaire à court de capacité en AL, le côté développement, c'est ce que je prends : estimer les écarts, les construire en extensions qui survivent aux mises à jour, et les tester avec les vrais documents du client.

D'ici le 11 janvier

Pour les clients qui resteront sur NAV 2017 encore quelques mois :

• garder le serveur NAV hors d'Internet ; l'accès à distance passe par un VPN ;
• tester les sauvegardes en restaurant vraiment une copie ;
• limiter l'accès aux personnes qui en ont besoin ;
• geler les changements Windows et SQL Server à moins d'avoir testé NAV avant.

L'échéance ne veut pas dire que chaque client doit être migré d'ici le 11 janvier. Elle veut dire que chaque client devrait avoir un plan d'ici là.

Des clients encore sur NAV 2017? Parlons-en.