Mehdi Assabbane
← Tous les articles

Migrer webMethods 10.x vers 11 ou 12 : la méthode en six étapes

Mehdi Assabbane ·

Introduction

Une migration webMethods a mauvaise réputation : des dizaines de packages Integration Server, des flux que plus personne n'ose toucher, des partenaires externes à prévenir, et une plateforme qui ne doit jamais s'arrêter. Pourtant, avec la fin progressive du support des versions 10.x, la question n'est plus de savoir s'il faut migrer, mais comment le faire sans incident.

Ce guide propose une méthode en six étapes, issue des bonnes pratiques de migration de plateformes d'intégration. Il ne remplace pas la documentation de migration d'IBM, qui reste la référence pour les procédures propres à chaque produit et version : il vous aide à organiser le projet.

Pour les dates de fin de support des versions 10.x, voir notre article sur la fin du support de webMethods 10.5.

Étape 1 : choisir la stratégie de migration

Deux approches existent :

Mise à jour sur place Migration en parallèle
Principe Mettre à jour l'installation existante Installer la nouvelle version à côté, migrer, basculer
Retour arrière Difficile (restauration complète) Simple : on rebascule sur l'ancien environnement
Coût Faible en infrastructure Nécessite des serveurs supplémentaires pendant la transition
Recommandée pour Petits environnements non critiques Production, flux critiques

Pour une plateforme de production, la migration en parallèle est presque toujours le bon choix : elle permet de tester en conditions réelles et de revenir en arrière en quelques minutes.

Étape 2 : faire l'inventaire complet

C'est l'étape la plus importante, et la plus souvent bâclée. Pour chaque environnement (développement, recette, production), relevez :

Produits et versions

  • Integration Server, Universal Messaging, Broker éventuel, Trading Networks, API Gateway, My webMethods Server, adaptateurs (JDBC, SAP, JMS…), Terracotta.
  • Niveau de correctifs installés, via l'outil de mise à jour de webMethods (Update Manager).

Contenu applicatif

  • Liste des packages Integration Server, en distinguant packages produits, packages personnalisés et packages tiers.
  • Services Java personnalisés et bibliothèques JAR ajoutées : ce sont les éléments les plus sensibles à un changement de version de Java.
  • Planifications (scheduler), déclencheurs (triggers), écouteurs (listeners), ports.

Connexions et dépendances

  • Connexions JDBC, JMS, SAP, FTP/SFTP, HTTP : cibles, comptes, certificats.
  • Keystores et truststores, avec les dates d'expiration des certificats.
  • Systèmes partenaires : qui appelle la plateforme, et qui elle appelle.

Socle technique

  • Système d'exploitation, version de Java, base de données, répartiteurs de charge, pare-feux.

Le résultat doit tenir dans un document partagé. Il servira de référence pour toute la suite du projet.

Étape 3 : vérifier la compatibilité de la cible

Avec l'inventaire en main, vérifiez dans la documentation d'IBM pour la version cible (11.1 ou 12.1) :

  • les systèmes d'exploitation et bases de données supportés ;
  • la version de Java embarquée ou exigée ;
  • la disponibilité et la version des adaptateurs que vous utilisez ;
  • les fonctionnalités dépréciées ou supprimées entre votre version et la cible ;
  • la procédure de migration des données propres à chaque produit (bases de données des composants, configuration).

Toute incompatibilité découverte ici coûte dix fois moins cher que si elle est découverte en recette.

Étape 4 : préparer l'environnement cible

  • Installer la nouvelle version sur des serveurs dédiés, avec le même découpage que l'existant (ou en profitant de la migration pour le simplifier).
  • Automatiser l'installation et la configuration autant que possible : scripts d'installation, gestion des variables d'environnement, déploiement des packages par un outil (webMethods Deployer, pipelines CI/CD). Une installation reproductible est indispensable pour monter recette et production à l'identique.
  • Versionner les packages personnalisés dans un gestionnaire de sources (Git) si ce n'est pas déjà fait.
  • Préparer la supervision : journaux, métriques et alertes doivent être en place avant la bascule, pas après.

Étape 5 : migrer et tester

Migrer le contenu

Déployez les packages personnalisés sur la nouvelle plateforme, recréez les connexions, importez les certificats et la configuration. Recompilez et testez les services Java personnalisés avec la nouvelle version de Java.

Tester sérieusement

  • Tests de non-régression automatisés sur les flux critiques : mêmes entrées, mêmes sorties attendues sur l'ancienne et la nouvelle plateforme.
  • Tests de charge sur les flux les plus volumineux, pour comparer les temps de réponse.
  • Tests de bout en bout avec les partenaires, en recette, sur les flux les plus sensibles.
  • Tests de reprise : redémarrage des serveurs, perte d'une connexion à la base, file de messages saturée.

Étape 6 : basculer

  • Planifier la fenêtre avec les métiers et les partenaires, en évitant les périodes de clôture.
  • Geler les évolutions sur l'ancienne plateforme quelques jours avant.
  • Vider les files et traiter les documents en cours avant de couper les flux entrants.
  • Basculer les points d'entrée (DNS, répartiteur de charge, configuration des partenaires).
  • Surveiller de près les premières heures : erreurs, temps de réponse, volumes traités.
  • Conserver l'ancienne plateforme arrêtée mais intacte pendant quelques semaines, comme solution de retour arrière.

Les pièges les plus fréquents

  • Un inventaire incomplet : le flux mensuel oublié qui échoue à la première clôture.
  • Les certificats : un truststore non migré, et les appels HTTPS vers un partenaire tombent.
  • Le code Java personnalisé : une bibliothèque incompatible avec la nouvelle version de Java.
  • Les comptes et mots de passe des connexions, souvent absents de toute documentation.
  • L'absence de tests automatisés, qui rend chaque vérification manuelle et donc partielle.

Checklist de migration

  • Stratégie choisie (en parallèle recommandée pour la production).
  • Inventaire complet : produits, correctifs, packages, Java, connexions, certificats, partenaires.
  • Compatibilité de la cible vérifiée dans la documentation IBM.
  • Environnement cible installé de façon reproductible.
  • Packages versionnés et déployés par un outil.
  • Supervision en place avant la bascule.
  • Tests de non-régression, de charge et de bout en bout réalisés.
  • Fenêtre de bascule validée avec les métiers et les partenaires.
  • Plan de retour arrière documenté et testé.

FAQ

Faut-il passer par 11.1 pour aller en 12.1 ? Ce n'est pas une obligation de principe. Le chemin exact dépend des produits utilisés : vérifiez la documentation de migration d'IBM pour chacun d'eux.

Peut-on profiter de la migration pour passer aux conteneurs ? C'est possible, et souvent pertinent, mais cela ajoute un second chantier. Si l'équipe découvre les conteneurs en même temps, il est plus sûr de migrer d'abord à l'identique, puis de moderniser.

Combien de temps faut-il prévoir ? Comptez quelques semaines pour une petite plateforme bien documentée, plusieurs mois pour un environnement de plusieurs centaines de flux. L'inventaire permet de chiffrer précisément.

Qui doit être impliqué ? L'équipe d'intégration, bien sûr, mais aussi les équipes système et réseau, les responsables des applications connectées et, pour les flux externes, les partenaires.

Conclusion

Une migration webMethods réussie se joue avant la bascule : dans l'inventaire, les tests automatisés et la capacité à revenir en arrière.

  1. Commencez par l'inventaire, même si la migration n'est prévue que l'an prochain.
  2. Migrez en parallèle pour la production.
  3. Automatisez installation, déploiement et tests : vous en profiterez bien au-delà de la migration.

Sources officielles