Pour qui
L’offre s’adresse aux équipes qui exploitent déjà WSO2 API Manager et préparent une montée de version ou un changement de topologie. L’exemple le plus courant est le passage d’une version antérieure vers la branche 4.x décrite dans la documentation 4.3. Un autre exemple est le déplacement du runtime vers des conteneurs ou vers Kubernetes, sans changer le produit.
Elle convient moins à une équipe qui n’a pas encore choisi sa passerelle. Dans ce cas, le comparatif et l’audit API viennent avant une migration. Nos consultants sont certifiés WSO2 API Manager Practitioner V4 (2023), WSO2 API Manager Developer V3 (2021), MuleSoft Developer V4 (2022), Workato Automation Pro I, II, III (2025, valides jusqu’en 2027) et ITIL V4 (2020). Voir À propos.
Livrables
La cartographie décrit la version source, les extensions, les API publiées, les applications abonnées, les magasins de clés et les bases. Elle distingue ce qui est documenté de ce qui est seulement présent dans la configuration.
La liste d’écarts sépare ce qui se transporte, ce qui doit être reconfiguré, et ce qui n’a pas d’équivalent direct. Les historiques d’analytique, les comptes du portail et les secrets n’entrent pas dans un import de contrat. Le dire tôt évite une bascule qui semble complète et ne l’est pas.
La cible est décrite telle qu’elle a été retenue : machines, conteneurs, ou Kubernetes. Kubernetes n’est pas imposé. Lorsqu’il est retenu, l’article WSO2 API Manager sur Kubernetes rappelle le schéma de la documentation éditeur : ingress, passerelle, plans séparés, bases externalisées. Ce schéma est une référence de lecture, pas un engagement de tenue de charge.
Un parcours de vérification est convenu : obtention d’un jeton, appel, application d’un quota, présence d’une trace. Il dit si ce chemin répond. Il ne couvre pas le reste du parc par extrapolation.
Démarche
- Inventaire. Version, extensions, contrats, clés, bases, environnements. Le chiffrage de la suite est indicatif sur devis à partir de cet inventaire. Aucune durée type n’est publiée.
- Cible et écarts. Version visée, topologie, et ce que les applications consommatrices devront changer, y compris une URL de jeton ou un secret.
- Répétition. Le même parcours est joué sur un environnement qui n’est pas la production. Les bases de cet environnement ne sont pas celles de la production.
- Bascule accompagnée. Le créneau est celui que vous fixez. L’offre ne promet pas une interruption nulle, ni une reprise intégrale des historiques.
Ce que la migration ne fait pas
Elle ne choisit pas l’outil à votre place et ne déclare pas une version « terminée » au-delà du parcours convenu. Le cadre d’hébergement est celui des pages plateformes API et cloud et DevSecOps.
Questions fréquentes
Toute version source se migre-t-elle en une seule étape ?
On ne l’affirme pas. L’inventaire de la version en place dit si une étape intermédiaire est nécessaire avant la branche visée, par exemple une 4.x documentée par l’éditeur.
Kubernetes est-il obligatoire ?
Non. Kubernetes est une cible possible, pas un passage obligé. La page de déploiement et la documentation éditeur décrivent ce schéma ; le choix de topologie se fait au cadrage.
Les jetons et les abonnements sont-ils repris tels quels ?
Pas nécessairement. Une application consommatrice peut devoir changer une URL de jeton ou un secret. Cet écart est écrit avant la bascule.
Comment sont fixés le prix et la durée ?
Le chiffrage est indicatif sur devis, après l’inventaire. Aucune durée type ni aucun forfait ne sont publiés ici.
Pour cadrer le périmètre, écrivez à contact@technocify.fr ou utilisez le formulaire de contact. Le chiffrage est indicatif sur devis.