Mettre à niveau les personnalisations NAV vers Business Central : le standard d'abord, les extensions ensuite

La plupart des entreprises encore sur Dynamics NAV ont des années de personnalisations dedans : des champs ajoutés, des routines de report modifiées, des rapports sur mesure, des intégrations que plus personne ne connaît au complet. Passer à Business Central force une question que NAV ne posait jamais : qu'est-ce qu'on fait avec chacune?

Dans NAV, on personnalisait d'habitude en changeant directement le code de l'application de base (C/AL, dans les objets de base). Business Central fonctionne autrement : vos changements vivent dans des extensions, écrites en AL, qui s'ajoutent par-dessus l'application de base au lieu de la modifier. Dans Business Central en ligne, modifier l'application de base n'est tout simplement pas possible.

Une mise à niveau, ce n'est donc pas juste déménager les données dans une nouvelle version. C'est revoir chaque personnalisation. Voici comment je m'y prends.

1. Faire la liste

Avant tout code, listez chaque personnalisation : ce qu'elle fait, qui s'en sert, et si quelqu'un remarquerait qu'elle a disparu. Vous serez surpris du nombre qui existent pour un processus que l'entreprise a abandonné il y a des années.

2. Le standard d'abord

Pour chaque personnalisation, la première question est : Business Central le fait-il maintenant en standard?

Business Central a gagné beaucoup de fonctions depuis les versions de NAV d'où partent la plupart des entreprises. Une personnalisation écrite il y a des années pour combler un trou est peut-être couverte aujourd'hui par une fonction standard. Quand c'est le cas, je choisis toujours le standard :

• moins de travail maintenant : rien à réécrire ;
• moins d'entretien plus tard : Microsoft la met à jour, la teste et la garde fonctionnelle d'une version à l'autre ;
• moins de surprises : tous les partenaires et utilisateurs de Business Central connaissent le comportement standard.

Parfois, la fonction standard marche un peu différemment de l'ancienne personnalisation. Il vaut habituellement mieux adapter le processus au standard que de reconstruire l'ancienne façon.

3. Réécrire le reste en extensions AL

Ce que Business Central standard ne couvre pas est réécrit en extension AL. Le grand changement, c'est de passer de modifier le code à l'étendre :

• Les champs sur les tables standard deviennent des extensions de table.
• Les changements d'écran deviennent des extensions de page.
• Les changements de logique deviennent des abonnés aux événements : au lieu de modifier une routine de report, on s'abonne aux événements qu'elle lance avant et après ses étapes importantes.
• Les nouvelles fonctions ont leurs propres tables, pages, codeunits et rapports.

Il existe des outils qui convertissent le vieux C/AL en syntaxe AL (le convertisseur Txt2Al de Microsoft, par exemple), et ils aident pour la partie mécanique. Mais du code converti qui modifiait des objets de base doit quand même être repensé autour des événements, et ça, c'est du vrai travail. Si l'événement dont vous avez besoin n'existe pas, Microsoft accepte les demandes de nouveaux événements ; en attendant, il y a d'habitude une autre porte d'entrée.

4. Déménager les données

Les personnalisations viennent avec des données : les valeurs de ces champs ajoutés, les enregistrements des tables sur mesure. Elles doivent atterrir dans les tables de la nouvelle extension. Microsoft fournit des outils de mise à niveau et un chemin de migration infonuagique vers Business Central en ligne ; la bonne route dépend de la version d'où vous partez et du choix en ligne ou sur place. Vérifiez la documentation actuelle de Microsoft pour votre cas avant de planifier cette étape.

5. Tester, puis tester encore

C'est là que le temps passe. Les tests ont été, de loin, la partie la plus difficile de ces projets.

Chaque personnalisation réécrite, et chacune remplacée par une fonction standard, doit être vérifiée face à la vraie façon de travailler des gens : les vrais documents qu'ils reportent, les vrais rapports qu'ils impriment, les cas limites qu'une seule personne en comptabilité connaît. Quelques trucs aident :

• Testez avec de vraies données, copiées de la production, pas avec une compagnie de démo propre.
• Faites tester par les gens qui font le travail. Ils connaissent les cas limites que vous ne connaissez pas.
• Écrivez ce qui est « correct » avant de tester : les totaux qu'un rapport doit donner, les écritures qu'un report doit créer.
• Automatisez ce que vous pouvez. Business Central a un cadre de tests pour l'AL, et quelques tests automatisés sur les routines critiques se paient d'eux-mêmes à la prochaine mise à niveau.

6. Tout sauvegarder, et commencer petit

S'il y a un conseil que je donnerais à une entreprise sur le point de le faire : sauvegardez tout, et commencez petit.

• Gardez des sauvegardes complètes de la base NAV et de chaque étape en chemin, pour toujours pouvoir revenir en arrière.
• Ne déménagez pas tout d'un coup. Commencez par une compagnie, un module ou un groupe d'utilisateurs. Apprenez-en, corrigez ce qui brise, puis élargissez.
• Prévoyez garder l'ancien système accessible, en lecture seule, un bout de temps après le changement. Quelqu'un va avoir besoin d'y chercher quelque chose.

Ce qu'on y gagne

Fait de cette façon, la mise à niveau vous laisse avec moins de personnalisations qu'au départ, chacune écrite en extension qui survit aux mises à jour régulières de Business Central. C'est ça, le vrai gain : pas la nouvelle version, mais ne plus jamais avoir à traverser une mise à niveau aussi pénible.

Une mise à niveau de NAV à planifier? Parlons-en.