Microsoft fournit txt2al et le Code Conversion Tool pour transformer votre code C/AL en code AL. C’est utile, mais c’est seulement le point de départ. Voici ce qu’il reste à faire à la main, sur la base de plusieurs migrations NAV 2016/2018 vers Business Central.

1. Les modifications du standard ne passent pas

Tout MODIFY sur un objet standard est rejeté par AL. Il faut systématiquement :

• soit basculer la logique dans un event subscriber,
• soit recréer l’objet en table extension / page extension,
• soit assumer qu’on rend la fonctionnalité au standard.

C’est l’occasion de faire le tri : combien de ces modifications étaient encore vraiment utilisées ?

2. Les rapports RDLC ont mal vieilli

Les layouts RDLC convertis automatiquement fonctionnent rarement du premier coup. Notre conseil : profitez-en pour basculer vers des layouts Word ou Excel quand le rapport s’y prête. Plus simple à maintenir par les utilisateurs métier.

3. La numérotation des objets

Les plages 50000-99999 (clients) et 50000-99999 (Microsoft partner) ont disparu en SaaS. Vous devez réserver une plage AppSource (à 5 chiffres, demandée à Microsoft) ou utiliser la plage 50000-99999 des per-tenant extensions (PTE).

À planifier avant d’écrire la première ligne.

4. Les temporary records utilisés comme buffers

Un pattern très courant en C/AL — passer une Record TEMP à une fonction — fonctionne toujours en AL, mais devient suspect : on préférera souvent un list ou un dictionary, plus performants et plus lisibles.

5. La gestion des erreurs

ERROR(...) sans contexte n’est plus tolérable. AL fournit le pattern ErrorInfo qui permet d’attacher des actions correctrices à l’erreur (par exemple : “Ouvrir la fiche client”, “Recalculer les stocks”). Vos utilisateurs vous remercieront.

6. Les tests automatisés

C’est probablement le plus gros saut culturel. AL apporte un vrai framework de tests ([Test], [HandlerFunctions], Library Codeunits). Profiter de la migration pour écrire les tests avant de refactorer un module est l’un des meilleurs investissements possibles.

En résumé

Une conversion C/AL → AL réussie demande, à la louche :

• 30 % du temps pour la conversion automatique et les ajustements purement syntaxiques,
• 40 % pour ré-architecturer ce qui ne passe pas (modifications standard, buffers, intégrations),
• 30 % pour les tests, la documentation et la formation des équipes.

Si on vous vend un projet qui ne consacre que 10 % au dernier point, méfiez-vous.

Vous préparez une migration ? Nous proposons des audits de code C/AL en deux semaines, livrant un rapport détaillé et un budget de conversion. Contactez-nous.