Migrer d’un outil de supervision vers un autre est une opération à risque particulier : pendant la transition, c’est précisément le moment où une panne non détectée coûte le plus cher, puisque personne ne surveille correctement l’infrastructure avec l’un ou l’autre outil. Une migration bien menée évite ce trou de visibilité par construction, pas par chance.
Étape 1 : cartographier avant de toucher à quoi que ce soit
Avant d’installer Zabbix, dresser l’inventaire complet de ce que l’outil actuel surveille réellement — équipements, seuils configurés, destinataires des alertes, intégrations tierces (tickets, Slack, SMS). C’est aussi le moment de faire le tri : certains checks existants sont probablement obsolètes, redondants, ou mal calibrés depuis longtemps. Migrer une supervision mal réglée telle quelle reproduit les mêmes défauts dans le nouvel outil.
Étape 2 : faire tourner les deux outils en parallèle
La méthode la plus sûre consiste à déployer Zabbix en parallèle de l’outil existant, sans rien désactiver, pendant une période de deux à quatre semaines. Les deux outils surveillent la même infrastructure simultanément. Cette période sert à valider que Zabbix détecte bien tout ce que l’ancien outil détectait — et rien de moins.
Étape 3 : migrer par groupe, pas d’un coup
Basculer l’intégralité de l’infrastructure en une seule fois maximise le risque en cas de problème de configuration non détecté pendant la phase de test. Migrer par groupe logique — un site, une famille d’équipements, une équipe utilisatrice — permet de valider chaque lot avant de passer au suivant, et de limiter l’impact si un ajustement est nécessaire en cours de route.
Étape 4 : comparer les alertes avant de couper l’ancien outil
Pendant la période de recouvrement, comparer systématiquement les alertes générées par les deux systèmes. Un écart (Zabbix silencieux sur un événement que l’ancien outil détecte, ou l’inverse) doit être compris et corrigé avant de désactiver quoi que ce soit — pas après.
Étape 5 : conserver l’historique, ou l’accepter comme perte
L’historique de métriques de l’ancien outil (PRTG, Nagios avec un addon comme PNP4Nagios) n’est généralement pas directement importable dans Zabbix — les formats de stockage sont incompatibles. Deux options réalistes : exporter les données critiques dans un format exploitable pour archivage externe, ou accepter que l’historique redémarre à zéro avec le nouvel outil. Cette décision doit être prise consciemment, pas découverte après coup.
Cas particulier : les scripts et checks personnalisés
Les checks Nagios personnalisés (plugins NRPE, scripts maison) demandent une réécriture pour Zabbix — soit en équivalents natifs, soit via l’exécution de scripts externes (UserParameters côté agent). C’est souvent la partie la plus sous-estimée en durée dans un projet de migration, en particulier pour des infrastructures avec beaucoup de checks sur mesure accumulés au fil des années.
Pour aller plus loin : Comparatif des outils de supervision · Comprendre l’architecture Zabbix
Une migration de supervision réussie ne se mesure pas au jour où l’ancien outil est éteint, mais aux semaines qui précèdent — celles où les deux outils tournent en parallèle sans qu’aucun écart ne subsiste.