Migration ERP : séparer progressivement les flux connectés

Séparez les différents flux de données avant de changer leur destination lors d’une migration ERP. Une application qui connaît partout les champs internes de l’ancien ERP est plus difficile à migrer de manière ciblée. Un point de passage clair peut limiter cette dépendance.

Choisir un chemin délimité

Dans une entreprise fictive, un portail crée des commandes dans l’ancien ERP puis reçoit leur état. Ce chemin précis est choisi pour la première étape de migration. Les autres connexions restent dans leur état convenu. Recensez aussi les retours et les traitements différés ; une commande déjà envoyée peut encore produire une réponse de l’ancien système après la bascule.

Microsoft décrit le remplacement progressif par un intermédiaire dans le modèle Strangler Fig. Ce choix d’architecture demande un effort. Il convient particulièrement lorsque l’ancien et le nouveau chemin peuvent coexister un certain temps.

Préserver le sens métier au point de passage

Dans l’exemple, le portail transmet une requête de création de commande avec son propre identifiant d’opération. Un adaptateur la traduit au format de l’ERP prévu. L’identifiant interne de la commande ERP est associé à l’opération du portail.

Ce tableau est notre propre répartition d’exemple. Deux ERP ne doivent pas exécuter indépendamment la même requête comme une nouvelle commande. Une comparaison technique en parallèle nécessite un chemin sécurisé séparément, sans double effet en production.

Vérifier la traduction et la correspondance des données

Une Anti-Corruption Layer traduit entre des modèles de systèmes différents. Elle peut se situer dans une application. Dans notre exemple, les identifiants d’article et de client ainsi que le sens des quantités doivent convenir au nouvel ERP. Un nom de champ identique ne suffit pas à le prouver.

Avant la bascule, vérifiez une nouvelle commande et une notification tardive concernant une ancienne commande. Contrôlez que les deux atteignent la bonne opération du portail. La reprise des données existantes doit tenir compte des mêmes correspondances.

Prévoir le retour et ses conséquences sur les données

Définissez quand les nouvelles requêtes peuvent reprendre l’ancien chemin. Traitez séparément les commandes déjà créées dans le nouvel ERP. Rebasculer l’intermédiaire ne les transfère ni ne les supprime automatiquement. Vérifiez aussi qui surveille et entretient l’intermédiaire ; il ne doit pas devenir un goulot d’étranglement inaperçu.

L’ancienne connexion n’est retirée qu’une fois les retours encore attendus et les dépendances restantes clarifiés. Sa fin dépend ainsi des opérations concernées, et pas seulement de la date de la première nouvelle requête réussie.

Sources

• Microsoft Learn: Strangler Fig pattern

• Microsoft Learn: Anti-Corruption Layer pattern